> In opposition to the foolish ignorabimus our slogan shall be Wir müssen wissen – wir werden wissen ("We must know – we will know").
For those who want to get to the translation quicker. IMO, its a bit unfair to hold the meaning of the title and the thesis of the whole blogpost as late as the 7th paragraph.
> We must take the same attitude in computing: use abstractions, refactor, refine scope, invent and adopt higher-level languages, until we can hold the code in our head.
I want to believe this is true. But as an counterexample, do we need to hold machine code or assembly, generated from our C or Golang programs, in our heads? Or rather the Golang code is a high-level abstraction which is good enough?
If that's the case, does it mean we should go even further and treat design docs as the code suitable to hold in head and treat Golang program as a derivative? Or maybe design docs are also too low-level and the general vibe "create me an app, make no mistakes" is actually enough?
What's the right abstraction level? How to find it?
> But as an counterexample, do we need to hold machine code or assembly, generated from our C or Golang programs, in our heads?
No, the source is enough, because the low-level assembly is translated from the high-level source descriptions (a sound programming language with a complete and consistent specification) via a deterministic algorithmic translation process (a compiler) to a low-level executable that can run on a machine. Today, compilers are complex, but still human understandable. The programs are equivalent, and we're getting better able to actually prove this.
This is why I bristle when people say "post your prompts". Your prompts are not a program and the magic box is not a compiler.
Too many people abandoning everything, either due to laziness, mental overload, or..."skill issues".
I still want to see code. I want write code, check code, optimize and refactor code. I don't want to spend a lot of time debugging, but maybe a little.
The clankers should be accelerating the parts of the process we are bad at, and that takes time we won't spend: long, time-consuming refactors, debugging deep issues, writing crap tons of tests, investigating performance issues, digesting other people's code.
AI should be more like a bicycle than a cruise ship. And I mean the "bicycle for the mind" that Jobs wanted.
exactly. it is upsetting that even people like linus torvalds argue that if you think that using LLMs for coding is bad, why are you using a compiler?
i use a compiler and not an LLM because the compiler is deterministic. i can trust that the same code input will always (for the same version of the compiler) produce the same machine code as output. the LLM will not.
I agree there is a spectrum, but we at least have to be honest with ourselves: are we really sure AI generated code is following the spec? On the other hand, with progress in proof automation, it is now feasible to formally verify AI generated code, and that allows us to specify program behavior formally, and a formal specification is again a program in itself.
I think with the AI it's not only question about following the spec, but about the completness of the spec. Before the AI, if specification wasn't complete, then program would lack of a feature, won't start correctly or crash. Nowadays, agents will happily fill any missing specification parts with random stuff, often looking reasonable at the first glance. This random content can be different with every iteration of the LLM work.
To find the right position in this spectrum, I think we need to find a level of specification that we care about.
I'm not sure the comparison with Hilbert's dictum holds up in our field. Yes, Godel made a mockery of it, and mathematics is now known to be limited by incompleteness, but only at the theoretical horizon. Working mathematicians will not run into it as a problem that blocks their work in other areas.
In computing, though, the halting problem hoses us every time we have to hit ctrl-c to break an accidental infinite loop. Our tools can't always flag those situations ahead of time, so we often have to find them the hard way.
It seems clear that in software development, the specification is the program. To the extent there's something that the spec doesn't cover, that's a bug in the spec, not in the AI that turns the spec into code. Just as you wouldn't blame a compiler for your infinite loop, we will eventually reach the point where blaming a clanker for generating imperfect high-level code sounds just as bogus.
"Build me a Super Mario Bros. clone, make no mistakes" is the new hello_world.c. For anything innovative -- anything with commercial value -- the spec will have to be a lot more elaborate. There are plenty of specs that are already too complex for any one person to hold in their head, except perhaps for a few godlike prodigies. Look at the MPEG-4 document collection, or for that matter our tax and legal systems. I think the lesson is that language alone can't save us from complexity, any more than a better set of axioms can save us from incompleteness.
This is a indeed an important reminder that there is still progress to be made in the realm of software development. By raising the bar of abstractions, perhaps by guiding agents toward them, we might be able to follow along better. It is too tempting to take allow the growing capabilities of ai to lower the standards on software developmenbt.
Unfortunately it's very easy (and tempting) to get lost in the sauce, we as a society gave up our heads to social media and look where it got us. I'm afraid we're going the same route with software development and computer science.
Social media poisoned society in a tricky way. Like some drug. Until now, people are addicted enough that even at HN, you cannot, have a deep and honest discussion about it. Discuss with chain smokers how healthy smoking is; it's going to be a very similar discussion.
And that doesn't even include the particular problems of "centralized" social media, where some oligarchs control which posts go up and which go down.
If you expect any particularly clever reaction from that society, for anything, you'll be quite disappointed. If you want that your friends constantly bug you with what they found on Instatoktube (a.k.a. 'indirect influencers') and not much more beyond that, this is absolutely what society can give you, though.
> In opposition to the foolish ignorabimus our slogan shall be Wir müssen wissen – wir werden wissen ("We must know – we will know").
For those who want to get to the translation quicker. IMO, its a bit unfair to hold the meaning of the title and the thesis of the whole blogpost as late as the 7th paragraph.
It's right under the title for me.
I added the quote after seeing the parent comment-thanks for the feedback.
I actually am studying German so I actually found it a cool application of my newfound German knowledge.
But then I thought about everyone else and offered the translation, then edited after I realized you covered it later.
It's an overall interesting blog post but just a minor quibble from me all else considered. Keep up the good writing.
> ignorabimus
https://www.latin-is-simple.com/en/vocabulary/search/?q=igno...
[dead]
> We must take the same attitude in computing: use abstractions, refactor, refine scope, invent and adopt higher-level languages, until we can hold the code in our head.
I want to believe this is true. But as an counterexample, do we need to hold machine code or assembly, generated from our C or Golang programs, in our heads? Or rather the Golang code is a high-level abstraction which is good enough?
If that's the case, does it mean we should go even further and treat design docs as the code suitable to hold in head and treat Golang program as a derivative? Or maybe design docs are also too low-level and the general vibe "create me an app, make no mistakes" is actually enough?
What's the right abstraction level? How to find it?
> But as an counterexample, do we need to hold machine code or assembly, generated from our C or Golang programs, in our heads?
No, the source is enough, because the low-level assembly is translated from the high-level source descriptions (a sound programming language with a complete and consistent specification) via a deterministic algorithmic translation process (a compiler) to a low-level executable that can run on a machine. Today, compilers are complex, but still human understandable. The programs are equivalent, and we're getting better able to actually prove this.
This is why I bristle when people say "post your prompts". Your prompts are not a program and the magic box is not a compiler.
Too many people abandoning everything, either due to laziness, mental overload, or..."skill issues".
I still want to see code. I want write code, check code, optimize and refactor code. I don't want to spend a lot of time debugging, but maybe a little.
The clankers should be accelerating the parts of the process we are bad at, and that takes time we won't spend: long, time-consuming refactors, debugging deep issues, writing crap tons of tests, investigating performance issues, digesting other people's code.
AI should be more like a bicycle than a cruise ship. And I mean the "bicycle for the mind" that Jobs wanted.
exactly. it is upsetting that even people like linus torvalds argue that if you think that using LLMs for coding is bad, why are you using a compiler?
i use a compiler and not an LLM because the compiler is deterministic. i can trust that the same code input will always (for the same version of the compiler) produce the same machine code as output. the LLM will not.
100% agreed on this, as Quentin Adam, the CEO of CleverCloud stated : "AI is inhuman so we must give it inhuman tasks".
Like creating correct software?
This is so sarcastic but not funny.
"Tragedy is when I cut my finger. Comedy is when you fall into an open sewer and die." -- Mel Brooks
I agree there is a spectrum, but we at least have to be honest with ourselves: are we really sure AI generated code is following the spec? On the other hand, with progress in proof automation, it is now feasible to formally verify AI generated code, and that allows us to specify program behavior formally, and a formal specification is again a program in itself.
I think with the AI it's not only question about following the spec, but about the completness of the spec. Before the AI, if specification wasn't complete, then program would lack of a feature, won't start correctly or crash. Nowadays, agents will happily fill any missing specification parts with random stuff, often looking reasonable at the first glance. This random content can be different with every iteration of the LLM work.
To find the right position in this spectrum, I think we need to find a level of specification that we care about.
I'm not sure the comparison with Hilbert's dictum holds up in our field. Yes, Godel made a mockery of it, and mathematics is now known to be limited by incompleteness, but only at the theoretical horizon. Working mathematicians will not run into it as a problem that blocks their work in other areas.
In computing, though, the halting problem hoses us every time we have to hit ctrl-c to break an accidental infinite loop. Our tools can't always flag those situations ahead of time, so we often have to find them the hard way.
It seems clear that in software development, the specification is the program. To the extent there's something that the spec doesn't cover, that's a bug in the spec, not in the AI that turns the spec into code. Just as you wouldn't blame a compiler for your infinite loop, we will eventually reach the point where blaming a clanker for generating imperfect high-level code sounds just as bogus.
"Build me a Super Mario Bros. clone, make no mistakes" is the new hello_world.c. For anything innovative -- anything with commercial value -- the spec will have to be a lot more elaborate. There are plenty of specs that are already too complex for any one person to hold in their head, except perhaps for a few godlike prodigies. Look at the MPEG-4 document collection, or for that matter our tax and legal systems. I think the lesson is that language alone can't save us from complexity, any more than a better set of axioms can save us from incompleteness.
[dead]
This is a indeed an important reminder that there is still progress to be made in the realm of software development. By raising the bar of abstractions, perhaps by guiding agents toward them, we might be able to follow along better. It is too tempting to take allow the growing capabilities of ai to lower the standards on software developmenbt.
Unfortunately it's very easy (and tempting) to get lost in the sauce, we as a society gave up our heads to social media and look where it got us. I'm afraid we're going the same route with software development and computer science.
Social media poisoned society in a tricky way. Like some drug. Until now, people are addicted enough that even at HN, you cannot, have a deep and honest discussion about it. Discuss with chain smokers how healthy smoking is; it's going to be a very similar discussion.
And that doesn't even include the particular problems of "centralized" social media, where some oligarchs control which posts go up and which go down.
If you expect any particularly clever reaction from that society, for anything, you'll be quite disappointed. If you want that your friends constantly bug you with what they found on Instatoktube (a.k.a. 'indirect influencers') and not much more beyond that, this is absolutely what society can give you, though.
"Muss man wissen!"
"hätte man wissen können..."