When was it written? The date says 2010 but dijkstra died in 2002.
Dijkstra On the foolishness of "natural language programming"
31–40 of 281 posts
Re: Dijkstra On the foolishness of "natural language programming"
#32Who is laughing now?
It is clear NLU can't be done in the reign of PL itself, there is never going to be natural language grammar that is precise as PL.
But LLM is a different kind of beast entirely.
Re: Dijkstra On the foolishness of "natural language programming"
#33What needs to be done can and is almost always described in natural language.
Whether that is feasible is a different question (https://xkcd.com/1425/), but also can be described in natural language.
Here is something I tried with o3-mini:
> Create a program that takes an input image and can tell if there is a bird in it.
> ChatGPT said:
> Reasoned for 38 seconds
> Below is an example in Python that uses TensorFlow’s Keras API and a pre-trained ResNet50 model to classify an input image. The code loads an image, preprocesses it to the required size, obtains the top predictions, and then checks if any of the top labels appear to be a bird. You can expand the list of bird keywords as needed for your application.
> python code that works
If you take the critical view, you can always find a way to find an exception that will fail. I can see many happy cases which will just work most of the time, even with the currently available technology. Most of the programming work done today is putting libraries and api services together.
Re: Dijkstra On the foolishness of "natural language programming"
#34Reminds me of another recurring idea of replacing code with flowcharts. First I've seen that idea coming from some unknown Soviet professor from 80s, and then again and again from different people from different countries in different contexts. Every time it is sold as a total breakthrough in simplicity and also every time it proves to be a bloat of complexity and a productivity killer instead. Or weak typing. How ma…
This is recurring topic indeed. I remember it was hot topic at least two times, when ALM tools were introduced (e.g. Borland ALM suite - https://www.qast.com/eng/product/develop/borland/index.htm), next when BPML language become popular - processes were described by the "marketing" and the software was, you know, generated automatically.
All this went out of fashion, leaving some good stuff that was built at that time (remaining 95% was crap).
Today's "vibe coding" ends when Chat GPT and alikes want to call on some object a method that does not exist (but existed in 1000s of other objects LLM was trained with, so should work here). Again, we will be left with the good parts, the rest will be forgotten and we will move to next big thing.
Re: Dijkstra On the foolishness of "natural language programming"
#35Earlier quoted context omitted.
The original text was from 1978 according to other sources
Ah, thanks. Yes it couldn't have been 2010 because he died in 2002. But the date this was written is important, otherwise his references to "the last decade" don't mean anything!
Many would say that "the last decade" (with the surrounding context) is timeless, or at least that it is still relevant today.
Re: Dijkstra On the foolishness of "natural language programming"
#36Earlier quoted context omitted.
Most popular dependency management systems literally linking to a git sha commit (tag), see locks file that npm/rebar/other tool gives you. Just in a recursive way.
They do way more than that. For example they won't allow you to have Foo-1 that depends on Qux-1 and Bar-1 that depends on Qux-2 where Qux-1 and Qux-2 are incompatible and can't be mixed within the same static library or assembly. But may allow it if mixing static-private Qux inside dynamic Foo and Bar and the dependency manager is aware of that. A native submodule approach would fail at link time or runtime due to a…
They do way less then that. They just form a final list of locks and download that at the build time. Of course you have to also "recursively" go though all your dep tree and add submodules for each of subdependencies (recommend to add them in the main repo). Then you will have do waste infinite amount of time setting include dirs or something. If you have two libs that require a specific version of a shared lib, no dep manager would help you. Using submodules is questionable practice though. Useful for simple stuff, like 10 deps in total in the final project.
Re: Dijkstra On the foolishness of "natural language programming"
#37When was it written? The date says 2010 but dijkstra died in 2002.
It’s just a date of transcription. The letter was written in 1978.
Re: Dijkstra On the foolishness of "natural language programming"
#38People are sticking up for LLMs here and that's cool. I wonder, what if you did the opposite? Take a project of moderate complexity and convert it from code back to natural language using your favorite LLM. Does it provide you with a reasonable description of the behavior and requirements encoded in the source code without losing enough detail to recreate the program? Do you find the resulting natural language descri…
Sure but we build (leaky) abstractions, and this is even happens in legal texts. Asking an llm to build a graphical app in assembly from an ISA and a driver for the display would give you nothing. But with a mountain of abstractions then it can probably do it. This is not to defend an LLM more to say I think that by providing the right abstractions (reusable components) then I do think it will get you a lot closer.
Llm frameworks !!
Re: Dijkstra On the foolishness of "natural language programming"
#39He didn’t understand the concept of the vibe. Here’s the best theory article I’ve read https://www.glass-bead.org/article/a-theory-of-vibe/
The difference between the clarity of Dijkstra writing and the text at this link is astounding.
Re: Dijkstra On the foolishness of "natural language programming"
#40I somewhat disagree with this. In real life, say in some company, the inception of an idea for a new feature is made in the head of some business person. This person will not speak any formal language. So however you turn it, some translation from natural language to machine language will have to be done to implement the feature. Typically the first step, translation from natural to formal language, will be done by b…
Say, doesn't each business - each activity - have its own formal language?
Not as formalized as programming languages, but it's there.
Try to define any process, you end up with something trending towards formalized even if you don't realize it.