I use rain-sounds or white noise plus noise-cancelling headphones to drown out my neighbor's TV. It bugs me that I have to hear advertisements coming over the wall when I wake up. If I'm really pissed off I turn on some reggae music with good bass. It always calms me down.
This makes me think how AI turns SW development upside down. In traditonal development we write code which is the answer to our problems. With AI we write questions and get the answers. Neither is easy, finding the correct questions can be a lot fo work, whereas if you have some existing code you already have the answers, but you may not have the questions (= "specs") written down anywhere, at least not very well, typically.
At least in my experience the AI agents work best when you give them a description of a concrete code change like "Write a function which does this here" rather than vague product ideas like "The user wants this problem solved". But coming up with the prompts for an exact code change is often harder than writing the code.
> both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle and a huge dead end.
Actors can be made to do structured concurrency as long as you allow actors to wait for responses from other actors, and implement hierarchy so if an actor dies , its children do as well. And that’s how I use them! So I have to say the OP is just ignorant of how actors are used in practice.
> Actors can be made to do structured concurrency as long as you allow actors to wait for responses from other actors
At which point they're very much not actors any more. You've lost the deadlock avoidance, you can't do the `become`-based stuff that looks so great in small demos. At that point what are you gaining from using actors at all?
To adapt the analogy from the link in the root comment, this is akin to saying "`goto` can be made to do structured programming as long as you strictly ensure that the control flow graph is reducible". Which is to say, it is a true statement that manages to miss the point: the power of both structured programming and structured concurrency comes from defining new primitives that fundamentally do the right thing and don't even give you the option to do the wrong thing, thus producing a more reliable system. There's no "as long as you...", it just works.
Except Akka in Java and for the entirety of Erlang and its children Elixir and Gleam. You obviously can scale those to multiple systems, but they provide a lot of benefit in local single process scenarios too imo.
If I'm not mistaken ROOM (ObjecTime, Rational Rose RealTime) was also heavily based on it. I worked in a company that developed real time software for printing machines with it and liked it a lot.
I've worked on a number of systems that used Akka in a non-distributed way and it was always an overengineered approach that made the system more complex for no benefit.
Fair, I worked a lot on data pipelines and found the actor model worked well in that context. I particularly enjoyed it in the Elixir ecosystem where I was building on top of Broadway[0]
Probably has to do with not fighting the semantics of the language.
Really depends of the ergonomics of the language. In erlang/elixir/beam langs etc, its incredibly ergonomic to write code that runs on distributed systems.
you have to try really hard to do the inverse. Java's ergonomics, even with Akka, lends its self to certain design patterns that don't lend itself to writing code for distributed systems.
It is political. Designing everything around cars benefits the class of people called "Car Owners". Not so much people who don't have the money or desire to buy a car.
Although, congestion pricing is a good counter-example. On the surface it looks like it is designed to benefit users of public transportation. But turns out it also benefits car-owners, because it reduces traffic jams and lets you get to your destination with your own car faster.
No, it benefits car manufacturers and sellers, and mechanics and gas stations.
Network/snowball effects are not all good. If local businesses close because everybody drives to WalMart to save a buck, now other people around those local businesses also have to buy a car.
I remember a couple of decades ago when some bus companies in the UK were privatized, and they cut out the "unprofitable" feeder routes.
Guess what? More people in cars, and those people didn't just park and take the bus when they got to the main route, either.
But having a car is kind of bad. Maybe you remember when everyone smoked, and there was stuff for smokers everywhere. Sure that made it easier for smokers, but ultimately that wasn't good for them (nor anyone around them).
From the article: "Claude Code can rip out one service and replace it with another in minutes. ..."
Doesn't that assume there are many interchangable services available on the web which essentially do the same thing?
I can see this would be the case if there were many online services for say compiling C++ code. But for more human-centric services, are there many "replaceable services" out there? An API is not only its syntax, but also its semantics.
I recently had to fill out a PDF form to send it to the Social Security Admininistration. They didn't have the option of submitting it online so I had to print it out and take it to them.
I filled out the PDF using FireFox PDF-editor, at which point it occurred to me, this is not so different from using an application which has a form for me to enter data into it.
Maybe in a few years Government has a portal where I can submit any of their forms as PDF documents, and they would probably use AI to store the contents of the form into a database.
A PDF-form is kind of a Universal API, especially when AI can extract and validate the data from it. Of all the API-formats I've seen I think PDF-forms is the most human-friendly. Each "API" is defined by the form-identifier in the PDF-form. It is easy for humans to use, and pretty easy for office-clerks to create such forms, especially with the help of AI. I wonder will this, or something similar, catch on?
A pdf can be anything and everything. It's just a wrapper around text, images, html, you can even embed javascript. There's already pdf forms that are user-editable (without a pdf editor). Not all features are available on all pdf viewers though.
If we're at the point where they use ai to make form pdfs, might as well cut the middleman and ask the ai to generate a form on a website.
The thing I think is that PDFs can be understood by both humans and AI. And they work even if power goes down as long as we have enough paper printouts and pens to fill out the forms. They can be shared by sending them by physical mail, no web needed. But they can be of course "uploaded" as well.
"Abstracting" means extracting the commnon parts of multiple instances, and making everything else a parameter. The difficulty for software is that developers often start by writing the abstraction, rather than having multiple existing instances and then writing code that collects the common parts of those multiple instances into a single abstraction. I guess that is what "refactoring" is about.
In sciences and humanities abstraction is applied the proper way, studying the instances first then describing multitude of existing phenomena by giving names to their common repeating descriptions.
This matches my "ideal" way of writing software, which is something close to "reverse waterfall". Start with the non-negotiable truths at the lowest level, then work your way up towards the goal, which is sufficiently defined. As you go, the patterns became apparent, collapsing into nice abstractions.
The code always ends up nice and clean and modular. And, since I'm working towards the idea, I can say "here are the modular pieces I have to work with, dictated the fundamentals beneath, how do I use them to accomplish the task?". When working from the idea, I think it's easier to want to write something to achieve the immediate task, in a "not see the forest for the trees" kind of way (abstractions are about the goal, rather than the reality under). Of course, both directions are required, but I get the best "separation of concerns" going in reverse.
Maybe simply "Show news about this topic"?
reply