Don't act like RSS is done with. It's twenty plus years old, and still going strong. Nobody is stopping you from using it, whether you only read or also post.
Hyped up tech is like milk, it stinks after a couple of days. Open protocols are like fine wine, they age beautifully.
P.S. Your site is offline. If it wasn't and you even had one interesting article, I would have added your website to my list of feeds. I picked up hundreds of interesting websites/feeds through HN alone in the last years.
Less people are blogging these days but there's still a lot of interesting blogs out there. It's even more self-selected than before but I almost always find a RSS feed for a blog that I think is useful and interesting.
Agreed - computer music compared to live music is what, say, Adobe Illustrator is to drawing. Or a Wacom drawing table, but definitely not prompting AI to draw for you.
Whether drawing (writing etc.) through AI counts as drawing (as making art) is a debate we have to resolve in the upcoming future.
> So yes, let’s be bold and assume that AI codevelopers make programmers ten times as productive. (Your mileage may vary, depending on how eager your developers are to learn new skills.)
Has anyone ever seen this hypothetical 10x AI developer? Why do we always back into such hand-wavy arguments when talking about the efficiency of AI-supported software engineering?
Here's what I think the flaw is in all the AI hype's arguments, including the one in this article (I hope Tim O'Reilly can withstand this small amount of debate).
Currently, LLM AIs are stochastic parrots and they don't offer creating levels of abstractions, i.e. creatively and responsively packaging ideas into some higher level form that can be reused.
All the examples in the article did offer a higher level of abstraction: assembly, high-level programming languages, libraries & frameworks like React, database systems etc.
AIs don't offer abstractions. They are not creative, they don't have "better ideas" than what their training data contains. They don't take responsibility for their work.
Us engineers at our company have all tried and are using some AI tools but they don't nearly work as well as management would think so. They make us 10%, maybe in the best case 20% more efficient, but not 10x efficient or anything.
So many good memories from high school! Gaming in the computer lab was banned in theory and the teacher always tried to delete any games found on these machines. So we always kept about a dozen 'hidden' copies on each machine.
I think that unit tests are super valuable because when used properly, they serve as micro-specifications for each component involved.
These would be super hard to backfill later, because usually only the developer who implements them knows everything about the units (services, methods, classes etc.) in question.
With a strongly typed language, a suite of fast unit tests can already be in feature parity with a much slower integration test, because even if mocked out, they essentially test the whole call chain.
They can offer even more, because unit tests are supposed to test edge cases, all error cases, wrong/malformed/null inputs etc. By using integration tests only, as the call chain increases on the inside, it would take an exponentially higher amount of integration tests to cover all cases. (E.g. if a call chain contains 3 services, with 3 outcomes each, theoretically it could take up to 27 integration test cases to cover them all.)
Also, ballooning unit test sizes or resorting to unit testing private methods give the developer feedback that the service is probably not "single responsibility" enough, providing incentive to split and refactor it. This leads to a more maintainable service architecture, that integration tests don't help with.
(Of course, let's not forget that this kind of unit testing is probably only reasonable on the backend. On the frontend, component tests from a functional/user perspective probably bring better results - hence the popularity of frameworks like Storybook and Testing Library. I consider these as integration rather than unit tests.)
Yes, this is why we love functional programming! "What happened along the way" equals to the call stack, as long as there is no field mutation involved.
And, of course, async/non-blocking calls, as tracing a call along different threads or promises may not be available all the time.
"""The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."
Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened."""
Not sure what are you trying to say. My point was that a invoking a function that will act on arguments that have been defined away from the callsite is not a OO specific feature.
> And, of course, async/non-blocking calls, as tracing a call along different threads or promises may not be available all the time.
I think there is still hope on that front. Following structured concurrency patterns like the supervisor model should handle it. See the discussion about "Notes on structured concurrency, or: Go statement considered harmful" [1].
reply