The Abstraction Rises(cyber-omelette.com)
cyber-omelette.com
The Abstraction Rises
https://cyber-omelette.com/posts/the-abstraction-rises.html
34 comments
I think a reasonable and sensible goal is for us to not mix the accidental and the essential. If we let AI handle what's accidental (as in not central to the solution of the essential problem) developers can focus on the essential only. The current threat is that both types become intertwingled in a code-base, sometimes irreparably.
Fortran made that distinction clear. The compiler handled the accidental complexity of converting instructions to code, but never really obscured the boundary.
Take VB as an example from wayback. For the purposes of presenting a simple data-entry dialog, it removed the accidental complexity of dealing with Windows' message loop and resource files etc., which was painful. The essential complexity was in what the system did with the data. I suppose that the AI steering that needs to happen is to direct the essential down the essential path, and the accidental down the accidental path, and let a dev handle the former and the agent handle the latter (after all, it's accidental).
But, that'll take judgement - deciding in which camp each artifact exists and how it's managed. It might be a whole field of study, but it won't be new.
Fortran made that distinction clear. The compiler handled the accidental complexity of converting instructions to code, but never really obscured the boundary.
Take VB as an example from wayback. For the purposes of presenting a simple data-entry dialog, it removed the accidental complexity of dealing with Windows' message loop and resource files etc., which was painful. The essential complexity was in what the system did with the data. I suppose that the AI steering that needs to happen is to direct the essential down the essential path, and the accidental down the accidental path, and let a dev handle the former and the agent handle the latter (after all, it's accidental).
But, that'll take judgement - deciding in which camp each artifact exists and how it's managed. It might be a whole field of study, but it won't be new.
Converting instructions to code is essential complexity.
If you give up on doing the work necessary to understand what is and is not critically important, you are no longer competent or responsible.
At that point the roles have switched and you are the mindless drone, toiling to serve AI.
https://strangestloop.io/essays/things-that-arent-doing-the-...
If you give up on doing the work necessary to understand what is and is not critically important, you are no longer competent or responsible.
At that point the roles have switched and you are the mindless drone, toiling to serve AI.
https://strangestloop.io/essays/things-that-arent-doing-the-...
> Converting instructions to code is essential complexity
I don't agree with that. If I want to add two numbers I'd like to write `a = b + c`. I do not want to write the machine code that effects the same result on whatever computer architecture I'm targeting. Precisely _how_ one adds two numbers is accidental complexity. Whether they need to be added, and what numbers should be added, is essential complexity.
Fortran removed that accidental complexity and left the essential stuff in place. There were no fuzzy lines.
I don't agree with that. If I want to add two numbers I'd like to write `a = b + c`. I do not want to write the machine code that effects the same result on whatever computer architecture I'm targeting. Precisely _how_ one adds two numbers is accidental complexity. Whether they need to be added, and what numbers should be added, is essential complexity.
Fortran removed that accidental complexity and left the essential stuff in place. There were no fuzzy lines.
Without a method for how to do the work you won't be able to do the work. Is that not the definition of essential?
But the way you've stated it, as long as you're pointing your microscope at one thing, that thing is "essential" and every other thing in the world is "inessential".
But the way you've stated it, as long as you're pointing your microscope at one thing, that thing is "essential" and every other thing in the world is "inessential".
Yes, I think where we ought to point the microscope is important - that's the judgement. Let devs focus the microscope on the essential stuff, the business-existential stuff, and let the tools remove the burden of having to deal with anything that's not fundamental to the solution of the problem. The tools, now, are just not structured to make this problem easy. There's a lot of mixing of what's essential and accidental that becomes unmanageable quickly - spaghetti novo. It will be an interesting journey. It'll take humans and machines (directed by humans) to line up on an agreement on where the microscope should aim.
> like putting lipstick on a pig.
More like building a house in a bottomless swamp. The moment you finish it starts sinking, so you build a new floor, but it just makes it heavier, and speed up the sinking speed.
More like building a house in a bottomless swamp. The moment you finish it starts sinking, so you build a new floor, but it just makes it heavier, and speed up the sinking speed.
Is there an equivalent to filling up the swamp and reaching bedrock because my optimist brain is looking for it
Much of Amsterdam and Florence is built on logs. Basically, just drive a bunch of poles in the ground until they "fill up" the swamp enough to create a stable platform. The anoxic nature of the boggy water greatly slows the decomposition of the logs.
There's definitely a metaphor, here. You don't have to completely fill the swamp, just fill it enough, with enough stable pieces to create a platform you can build on.
There's definitely a metaphor, here. You don't have to completely fill the swamp, just fill it enough, with enough stable pieces to create a platform you can build on.
The value of AI output only decreases day to day as people do what there is to do with it. Soon if it can make something it will be making it for the 10th time instead of the 1st.
So yeah, we will hit rock bottom for sure. Eventually the value of anything that is genuinely new will rocket back up because we've spent so many years imitating imitations.
So yeah, we will hit rock bottom for sure. Eventually the value of anything that is genuinely new will rocket back up because we've spent so many years imitating imitations.
But you can orchestrate teams of builders to keep putting up new floors at ever increasing speeds!
We need a better term. There's nothing accidental about having to smack the parrot until it delivers an acceptable squawk.
Bro it's fine everyone's doing it get to the program. We all just need to use multiple agents with memory and skills and orchestrate them, connect them to ticketing systems with workload federation and let them create lambdas to push artifacts from a CI that has audit logs and snyk scanning, let them spin up a few kubernetes clusters per commit, then write the test suites with headless chrome and simulated agents that run A/B testing with multiple backups, regional HA, SSO, vertical and horizontal autoscaling, otel agents that rewrite what they collect based on other agentic processes that also run via lambdas that monitor datadog and splunk and sentry, automated PRs and red teaming. If you don't think about all of that even when you sleep do you even care about the customer?
[deleted]
To the point on Jevons Paradox, the number of people/developers joining GitHub had been accelerating as of the last Octoverse report. Related: "In 2023, GitHub crossed 100 million developers after nearly three years of growth from 50 million to 100 million. But the past year alone has rewritten that curve with our fastest absolute growth yet. Today, more than 180 million developers build on GitHub."
https://github.blog/news-insights/octoverse/octoverse-a-new-...
https://github.blog/news-insights/octoverse/octoverse-a-new-...
I've definitely noticed an uptick in output from "non-developers" specifically in game modding circles. It started when ChatGPT came out and people were copy-pasting code from it into files without knowing how to check if they actually were even in the proper file format for games to recognize, and but with tools like Claude the floor has risen to the point where most vibe-coded mods are at least loadable by games and most tooling people are writing will at least compile.
The thing that took me by surprise is that despite a huge amount of noise, there's a non-zero number of instances where the output has ended up being quite high quality. There's someone who by their own account had no development experience before AI tooling has started doing some incredible work on mod management on Linux, and from using some of the tools they've made so far, it's way higher quality than pretty much any other native Linux tooling for managing mods I've seen so far. I ended up chatting with them a bit after I got enough use out of what they made that it seemed worth subscribing to their Patreon, and they've spent a lot of time on improving their coding skills because they can tell how much it helps them even if they're utilizing the AI tooling for a lot of it. This specific developer is probably an outlier in terms of how well they're able to identify and focus on what ends up impacting the user experience (both in terms of features and willingness to spend quite a lot of effort tracking down and fixing even small bugs), but it seems like they might have never gone down this path in the first place without AI tooling.
I think the ratio of developers compared to "regular" users is still probably fairly small, so the number of people who have never had any reason to want or need a Github is still way higher than the number of people who already have accounts. I'm not trying to say that this won't cause some amount of friction in how development works or that there won't be a lot of slop out there that might make it hard to find the higher quality output, but I suspect that trying to fight against the trend is going to be a losing battle, and that "solving" it will end up requiring better ways to select which software that we want to use rather than limiting the amount of it that gets written and published. Writing software has continued to get more accessible over time; early computers weren't something you could have at home and work on stuff in your spare time on, and I'm sure that the the volume of low-quality software increased when that barrier was eliminated, but the volume of high quality software increased as well, and in the decades since then we've come up with all sorts of new ways to search for and distribute software that makes more of it available to everyone. At least right now, this is starting to look like a similar shift in how much more software is going to be produced, and although a lot of it might be bad, I'm not convinced that there won't also be some potential benefits to having a lot more people willing to try it out themselves. Trying to reap those benefits requires at least some amount of acceptance though, and I think the focus needs to be on the quality of the output independent of the process rather than on the process itself.
The bar for what we consider acceptable software shouldn't be lowered, but the litmus test that it needs to be written by a "real" developer is not necessarily going to be as accurate as those of us in the old guard would like. Yes, there will likely be problems down the line for someone who only wants to vibe and not understand what's actually going on with the code itself, but I've also worked with fantastic engineers who only have vague ideas about how a compiler works or what a CPU is actually is doing under the hood because it turns out that sometimes (not always!) that's not required knowledge to be able to write software that's actually useful. What they've all had in common is that they genuinely care about the quality of what they produce, so they focused on what the actual experience and then figured out what they needed to learn to improve that rather than starting from the bottom up.
The thing that took me by surprise is that despite a huge amount of noise, there's a non-zero number of instances where the output has ended up being quite high quality. There's someone who by their own account had no development experience before AI tooling has started doing some incredible work on mod management on Linux, and from using some of the tools they've made so far, it's way higher quality than pretty much any other native Linux tooling for managing mods I've seen so far. I ended up chatting with them a bit after I got enough use out of what they made that it seemed worth subscribing to their Patreon, and they've spent a lot of time on improving their coding skills because they can tell how much it helps them even if they're utilizing the AI tooling for a lot of it. This specific developer is probably an outlier in terms of how well they're able to identify and focus on what ends up impacting the user experience (both in terms of features and willingness to spend quite a lot of effort tracking down and fixing even small bugs), but it seems like they might have never gone down this path in the first place without AI tooling.
I think the ratio of developers compared to "regular" users is still probably fairly small, so the number of people who have never had any reason to want or need a Github is still way higher than the number of people who already have accounts. I'm not trying to say that this won't cause some amount of friction in how development works or that there won't be a lot of slop out there that might make it hard to find the higher quality output, but I suspect that trying to fight against the trend is going to be a losing battle, and that "solving" it will end up requiring better ways to select which software that we want to use rather than limiting the amount of it that gets written and published. Writing software has continued to get more accessible over time; early computers weren't something you could have at home and work on stuff in your spare time on, and I'm sure that the the volume of low-quality software increased when that barrier was eliminated, but the volume of high quality software increased as well, and in the decades since then we've come up with all sorts of new ways to search for and distribute software that makes more of it available to everyone. At least right now, this is starting to look like a similar shift in how much more software is going to be produced, and although a lot of it might be bad, I'm not convinced that there won't also be some potential benefits to having a lot more people willing to try it out themselves. Trying to reap those benefits requires at least some amount of acceptance though, and I think the focus needs to be on the quality of the output independent of the process rather than on the process itself.
The bar for what we consider acceptable software shouldn't be lowered, but the litmus test that it needs to be written by a "real" developer is not necessarily going to be as accurate as those of us in the old guard would like. Yes, there will likely be problems down the line for someone who only wants to vibe and not understand what's actually going on with the code itself, but I've also worked with fantastic engineers who only have vague ideas about how a compiler works or what a CPU is actually is doing under the hood because it turns out that sometimes (not always!) that's not required knowledge to be able to write software that's actually useful. What they've all had in common is that they genuinely care about the quality of what they produce, so they focused on what the actual experience and then figured out what they needed to learn to improve that rather than starting from the bottom up.
> LLMs ... completing tasks at the scale of full engineering teams.
Ah, a work of fiction.
Ah, a work of fiction.
StrongDM is doing it. In fact, their Attractor agentic loop, which generates, tests, and deploys code written as specs, has been released—as a spec, not code. Their installation instructions are pretty much "feed this into your LLM". They are building out not only complete applications, but test harnesses for those applications that clone popular web apps like Slack and JIRA, with no humans in the loop beyond writing the initial spec and giving final approval to deploy.
We're witnessing a "horses to automobile" moment in software development. Programming, as a professional discipline, is going to be over in a year or two on the outside. We're getting the "end of software engineering in six months" before we're getting a real "year of the Linux desktop". Or GTA VI.
We're witnessing a "horses to automobile" moment in software development. Programming, as a professional discipline, is going to be over in a year or two on the outside. We're getting the "end of software engineering in six months" before we're getting a real "year of the Linux desktop". Or GTA VI.
StrongDM is attempting that. The code they produced is not inspiring confidence on a relatively small scale [0], and based on what I saw with a cursory inspection I very much doubt I wouldn't find much deeper issues if I took the time to really dig into their code.
Don't get me wrong, "sort of works if you squint at it" is downright miraculous by the standards of five years ago, but current models and harnesses are not sufficient to replace developers at this scale.
[0] https://news.ycombinator.com/item?id=46927737
Don't get me wrong, "sort of works if you squint at it" is downright miraculous by the standards of five years ago, but current models and harnesses are not sufficient to replace developers at this scale.
[0] https://news.ycombinator.com/item?id=46927737
"Get a horse!"
This doesn't really address their counterarguments.
If the new-fangled "automobile" is too unreliable or slow to be useful, then yes, it might be best to stick with the horse for now.
And yes, automobiles were pretty bad for a while there. It was 22 years from the first automobile to the Model T, and even the Model T was prone to breaking down a lot.
If the new-fangled "automobile" is too unreliable or slow to be useful, then yes, it might be best to stick with the horse for now.
And yes, automobiles were pretty bad for a while there. It was 22 years from the first automobile to the Model T, and even the Model T was prone to breaking down a lot.
That's really cool, I can see the utility in it but why on this earth would anyone want this for anything other than doing internal integration tests.
I can see a company who spends upwards of $2000 a month on just slack, but can you justify building, deploying and maintaining your own personal slack clone even if you can get an AI to do all of that. What happens when, inevitably, there are issues that the AI gets stumped on? You will need some level of humans intervention or at least review the issue before letting the autonomous loop run. Even if you ignore all of that, if the loop doesn't catch the bug but a human does, they're still the ones left reporting it.
You're shifting this entire process of owning a product to an AI, which even in the best case leaves you paying a bill probably larger than a $2000/mo. You're 100% better off just deploying an OSS alternative, maybe sponsoring them for some feature requests than managing an AI loop to build, deploy and maintain.
Maybe at the scale of paying $20,000/mo or $50,000/mo you could start to justify it in some way but when you're able to pay that much for a productivity enhancement service what really are you going to do better than them. Their incentive is to earn and yours is to save, theirs is much stronger to deliver than yours. The argument that SaaS is dead is very poorly focused. I get your specific workplace pays for a service that they only use 2-3 features of, that's not the case for major SaaS products. Something like dynamics 365 takes month for process engineers to implement business processes, there is 0 coding involved just interviewing, documenting and configuring. The actual act of programming might take a single digit percentage of the total cost to deliver a complete deployment.
Ignoring all the business talk, I don't think anyone denies LLMs ability to bring huge productivity boost. I can wholeheartedly support the argument that companies no longer have an excuse to significantly over hire and micro delegate tasks over hundreds of engineers because it's more efficient to let fewer engineers have higher productivity.
I'm part of a small team that's embraced AI for code assistance right at ChatGPT 3.5. There are still cases where when AI doesn't have enough examples about a problem in it's training data, for no matter how long you let it ruminate, debug, harness etc. would it be able to solve those certain issues. If you had let it run for long enough it may have completely reimplemented the library back on it's own, failed then attempted to reimplement the entire saas product as a MVP replacement.
Even if we setup the AI could fully autonomously implement, test, debug and deploy features fully autonomously the case where there it runs into an issue, services fail to deploy, new business use cases to implement can possibly lead to huge costs/lost revenue which isn't worth not having software engineers for. If your company's business needs require 30 servers with 300-500 instances of different services deployed across them, and you keep software engineers for that worst case scenario you can't keep just 2-3 because a human can only push their cognitive load so far. The number of software engineers needed to maintain and manage will remain more or less the same, the only difference will be they'll have more time to contribute to more important parts of the business. Maybe even manage that Slack clone.
I can see a company who spends upwards of $2000 a month on just slack, but can you justify building, deploying and maintaining your own personal slack clone even if you can get an AI to do all of that. What happens when, inevitably, there are issues that the AI gets stumped on? You will need some level of humans intervention or at least review the issue before letting the autonomous loop run. Even if you ignore all of that, if the loop doesn't catch the bug but a human does, they're still the ones left reporting it.
You're shifting this entire process of owning a product to an AI, which even in the best case leaves you paying a bill probably larger than a $2000/mo. You're 100% better off just deploying an OSS alternative, maybe sponsoring them for some feature requests than managing an AI loop to build, deploy and maintain.
Maybe at the scale of paying $20,000/mo or $50,000/mo you could start to justify it in some way but when you're able to pay that much for a productivity enhancement service what really are you going to do better than them. Their incentive is to earn and yours is to save, theirs is much stronger to deliver than yours. The argument that SaaS is dead is very poorly focused. I get your specific workplace pays for a service that they only use 2-3 features of, that's not the case for major SaaS products. Something like dynamics 365 takes month for process engineers to implement business processes, there is 0 coding involved just interviewing, documenting and configuring. The actual act of programming might take a single digit percentage of the total cost to deliver a complete deployment.
Ignoring all the business talk, I don't think anyone denies LLMs ability to bring huge productivity boost. I can wholeheartedly support the argument that companies no longer have an excuse to significantly over hire and micro delegate tasks over hundreds of engineers because it's more efficient to let fewer engineers have higher productivity.
I'm part of a small team that's embraced AI for code assistance right at ChatGPT 3.5. There are still cases where when AI doesn't have enough examples about a problem in it's training data, for no matter how long you let it ruminate, debug, harness etc. would it be able to solve those certain issues. If you had let it run for long enough it may have completely reimplemented the library back on it's own, failed then attempted to reimplement the entire saas product as a MVP replacement.
Even if we setup the AI could fully autonomously implement, test, debug and deploy features fully autonomously the case where there it runs into an issue, services fail to deploy, new business use cases to implement can possibly lead to huge costs/lost revenue which isn't worth not having software engineers for. If your company's business needs require 30 servers with 300-500 instances of different services deployed across them, and you keep software engineers for that worst case scenario you can't keep just 2-3 because a human can only push their cognitive load so far. The number of software engineers needed to maintain and manage will remain more or less the same, the only difference will be they'll have more time to contribute to more important parts of the business. Maybe even manage that Slack clone.
Fortran is all about symbolic programming. There is no probability in the internal workings of Fortran compiler. Almost any person can learn rules and count on them.
LLMs are all about probabilistic programming. While they are harnessed by a lot of symbolic processing (tokens as simple example), the core is probabilistic. No hard rules can be learned.
And, for what it worth, "Real programmers don't use Pascal" [1] was not written about assembler programmers, it was written about Fortran programmers, a new Priesthood.
[1] https://web.archive.org/web/20120206010243/http://www.ee.rye...
Thus, what I expect is for new Priesthood to emerge - prompt writing specialists. And this is what we see, actually.
LLMs are all about probabilistic programming. While they are harnessed by a lot of symbolic processing (tokens as simple example), the core is probabilistic. No hard rules can be learned.
And, for what it worth, "Real programmers don't use Pascal" [1] was not written about assembler programmers, it was written about Fortran programmers, a new Priesthood.
[1] https://web.archive.org/web/20120206010243/http://www.ee.rye...
Thus, what I expect is for new Priesthood to emerge - prompt writing specialists. And this is what we see, actually.
Fortran is about numerical programming without having to deal with explicit addresses. Symbolic programming is something like lisp.
Llms do not manipulate symbols according to rules, they predict tokens, or arbitrary glyphs in human parlance, based on statistical rules.
Llms do not manipulate symbols according to rules, they predict tokens, or arbitrary glyphs in human parlance, based on statistical rules.
Fortran internally transforms expressions to assembly using symbolic computation. a+0->a, a+b->b+a.
LLMs are very much supported by symbolic computation. These "arbitrary glyphs" are computed by symbolic computation. The output of LLMs is constrained by program language grammar in code generation tasks. LLMs are often run with beam search, which is symbolic computation.
LLMs are very much supported by symbolic computation. These "arbitrary glyphs" are computed by symbolic computation. The output of LLMs is constrained by program language grammar in code generation tasks. LLMs are often run with beam search, which is symbolic computation.
LLM coding isn't a new level of abstraction. Abstractions are (semi-)reliable ways to manage complexity by creating building blocks that represent complex behavior, that are useful for reasoning about outcomes.
Because model output can vary widely from invocation to invocation, let alone model to model, prompts aren't reliable abstractions. You can't send someone all of the prompts for a vibecoded program and know they will get a binary with generally the same behavior. An effective programmer in the LLM age won't be saving mental energy by reasoning about the prompts, they will be fiddling with the prompts, crossing their fingers that it produces workable code, then going back to reasoning about the code to ensure it meets their specification.
What I think the discipline is going to find after the dust settles is that traditional computer code is the "easiest" way to reason about computer behavior. It requires some learning curve, yes, but it remains the highest level of real "abstraction", with LLMs being more of a slot machine for saving the typing or some boilerplate.
Because model output can vary widely from invocation to invocation, let alone model to model, prompts aren't reliable abstractions. You can't send someone all of the prompts for a vibecoded program and know they will get a binary with generally the same behavior. An effective programmer in the LLM age won't be saving mental energy by reasoning about the prompts, they will be fiddling with the prompts, crossing their fingers that it produces workable code, then going back to reasoning about the code to ensure it meets their specification.
What I think the discipline is going to find after the dust settles is that traditional computer code is the "easiest" way to reason about computer behavior. It requires some learning curve, yes, but it remains the highest level of real "abstraction", with LLMs being more of a slot machine for saving the typing or some boilerplate.
Not a fan of looking at history for cases that look like the could be a step change - a new paradigm. For that it seems safer to extrapolate out from recent experiences. Normally that’s a bad idea but if you’re in uncharted territory it’s the only reference point
> My concerns about obsolescence have shifted toward curiosity about what remains to be built. The accidental complexity of coding is plummeting, but the essential complexity remains. The abstraction is rising again, to tame problems we haven't yet named.
what if AI is better at tackling essential complexity too?
what if AI is better at tackling essential complexity too?
The essential complexity isn't solvable by computer systems. That was the point Fred Brooks was making.
You can reduce it by process re-engineering, by changing the requirements, by managing expectations. But not by programming.
If we get an LLM to manage the rest of the organisation, then conceivably we could get it to reduce the essential complexity of the programming task. But that's putting the cart before the horse - getting an LLM to rearrange the organisation processes so that it has less complexity to deal with when coding seems like a bad deal.
And complexity is one of the things we're still not seeing much improvement in LLMs managing. The common experience from people using LLM coding agents is that simple systems become easy, but complex systems will still cause problems with LLM usage. LLMs are not coping well with complexity. That may change, of course, but that's the situation now.
You can reduce it by process re-engineering, by changing the requirements, by managing expectations. But not by programming.
If we get an LLM to manage the rest of the organisation, then conceivably we could get it to reduce the essential complexity of the programming task. But that's putting the cart before the horse - getting an LLM to rearrange the organisation processes so that it has less complexity to deal with when coding seems like a bad deal.
And complexity is one of the things we're still not seeing much improvement in LLMs managing. The common experience from people using LLM coding agents is that simple systems become easy, but complex systems will still cause problems with LLM usage. LLMs are not coping well with complexity. That may change, of course, but that's the situation now.
I don't think the parent comment was saying it can be solved, only that the LLM paradigm is better at dealing with complexity. I agree that they are not great at it yet, but I've seen vast improvements in the past 3 months alone.
Going from programming language to LLM is not the same kind of abstraction as going from assembler to Fortran or Algol.
With programming languages, there is a transparent homomorphism between the code you write and what the machine actually executes. Programmers use this property of programming languages to execute considerable control over the computational process they're evolving while still potentially at a high level of abstraction. With LLMs, the mapping between your input and the executable output is opaque and nondeterministic. This drives people like me batty.
A while back I wrote a Lisp koan:
https://www.hackersdictionary.com/html/Some-AI-Koans.html
Mine goes like this:
"A student travelled to the East to hear Sussman's teachings. Sussman was expounding on low-level development in Lisp, when the student interrupted him. 'Master Sussman,' said he, 'is not Lisp a high-level language, indeed perhaps the highest-level of all programming languages?' Sussman replied, 'Once there was a man who was walking along the beach when he spotted an eagle. Brother eagle, said he, how impossibly distant is the sky! The eagle said nothing, and flew away.' Thus the student was enlightened."
The story is in some sense true: I did meet Gerald Sussman and was in some sense enlightened by him. Another hacker was talking about working in a "low-level language" like Lisp, and I corrected him telling him that Lisp was in fact very high level. He said "Uh... I need Jerry to explain this to you. Jerry? Can you come here a minute?" "Jerry" was Gerald Sussman, who proceeded to explain to me that Lisp was a virtual machine, one which he implemented in silico for his Ph.D. thesis:
https://dspace.mit.edu/handle/1721.1/5731
Thus I was enlightened. If Lisp is a virtual machine, so are all programming languages. And even a buck JavaScript kiddie fresh out of boot camp, working in React, is working in machine code for the JavaScript+browser+React VM. An abstraction is a point of view, and the programmer working in a "high level" programming language is really just working in the same medium as machine code: computation itself. But with a point of view that offers more convenience.
LLM work is different. LLMs are enormously complicated algorithms that give probabilistic interpretations of loose, informal human languages. So instructing a computer through the filter of an LLM is inherently probabilistic, not to mention damn near inscrutable.
This is why LLMs are being met with more resistance even than compilers were. They're not the same thing. Compilers scaled the work, which remained essentially the same. LLMs are changing it.
With programming languages, there is a transparent homomorphism between the code you write and what the machine actually executes. Programmers use this property of programming languages to execute considerable control over the computational process they're evolving while still potentially at a high level of abstraction. With LLMs, the mapping between your input and the executable output is opaque and nondeterministic. This drives people like me batty.
A while back I wrote a Lisp koan:
https://www.hackersdictionary.com/html/Some-AI-Koans.html
Mine goes like this:
"A student travelled to the East to hear Sussman's teachings. Sussman was expounding on low-level development in Lisp, when the student interrupted him. 'Master Sussman,' said he, 'is not Lisp a high-level language, indeed perhaps the highest-level of all programming languages?' Sussman replied, 'Once there was a man who was walking along the beach when he spotted an eagle. Brother eagle, said he, how impossibly distant is the sky! The eagle said nothing, and flew away.' Thus the student was enlightened."
The story is in some sense true: I did meet Gerald Sussman and was in some sense enlightened by him. Another hacker was talking about working in a "low-level language" like Lisp, and I corrected him telling him that Lisp was in fact very high level. He said "Uh... I need Jerry to explain this to you. Jerry? Can you come here a minute?" "Jerry" was Gerald Sussman, who proceeded to explain to me that Lisp was a virtual machine, one which he implemented in silico for his Ph.D. thesis:
https://dspace.mit.edu/handle/1721.1/5731
Thus I was enlightened. If Lisp is a virtual machine, so are all programming languages. And even a buck JavaScript kiddie fresh out of boot camp, working in React, is working in machine code for the JavaScript+browser+React VM. An abstraction is a point of view, and the programmer working in a "high level" programming language is really just working in the same medium as machine code: computation itself. But with a point of view that offers more convenience.
LLM work is different. LLMs are enormously complicated algorithms that give probabilistic interpretations of loose, informal human languages. So instructing a computer through the filter of an LLM is inherently probabilistic, not to mention damn near inscrutable.
This is why LLMs are being met with more resistance even than compilers were. They're not the same thing. Compilers scaled the work, which remained essentially the same. LLMs are changing it.
> With the price of computation so high, that inefficiency was like lighting money on fire. The small group of contributors capable of producing efficient and correct code considered themselves exceedingly clever, and scoffed at the idea that they could be replaced.
There will always be someone ready to drag down prices of computation low enough so that it is then democratized for all, some may disagree but that would eventually be local inference as computer hardware gets better with clever software algorithms.
In this AI story, you can take a guess who are the "The Priesthood" of the 2020s are.
> You still have to know what you want the computer to do, and that can be very hard. While not everyone wrote computer programs, the number of computers in the world exploded.
One can say, the number of AI agents will explode and surpass humans on the internet in the next few years, and reading the code and understanding what it does when generated from an AI will be even more important than writing it.
So you do not get horrific issues like this [0] since now the comments in the code are now consumed by the LLM and due to their inherent probabilistic and unpredictable nature, different LLMs produce different code and cannot guarrantee that it is correct other than a team of expert humans.
We'll see if you're ready to read (and fix) an abundance of lots of AI slop and messy architectures built by vibe-coders as maintainance costs and security risks skyrocket.
[0] https://sketch.dev/blog/our-first-outage-from-llm-written-co...
There will always be someone ready to drag down prices of computation low enough so that it is then democratized for all, some may disagree but that would eventually be local inference as computer hardware gets better with clever software algorithms.
In this AI story, you can take a guess who are the "The Priesthood" of the 2020s are.
> You still have to know what you want the computer to do, and that can be very hard. While not everyone wrote computer programs, the number of computers in the world exploded.
One can say, the number of AI agents will explode and surpass humans on the internet in the next few years, and reading the code and understanding what it does when generated from an AI will be even more important than writing it.
So you do not get horrific issues like this [0] since now the comments in the code are now consumed by the LLM and due to their inherent probabilistic and unpredictable nature, different LLMs produce different code and cannot guarrantee that it is correct other than a team of expert humans.
We'll see if you're ready to read (and fix) an abundance of lots of AI slop and messy architectures built by vibe-coders as maintainance costs and security risks skyrocket.
[0] https://sketch.dev/blog/our-first-outage-from-llm-written-co...
Nothing about cajoling a model to write what you want it to is essential complexity in software dev.
In addition when you do a lot of building with no theory you tend you make lots and lots of new non-essential complexity.
Devtools are no exception. There was already lots of nonessential complexity in them and in the model era is that gone? ...no don't worry it's all still there. We built all the shiny new layers right on top of all the old decaying layers, like putting lipstick on a pig.