Languages that are difficult for LLM to read & write are also difficult for the general public. These languages have always had poor uptake and never reach critical mass, or are eventually replaced by better languages. Language designers would be smart to recognize this fact and favor making their languages more LLM friendly. This should also make them more human friendly.
Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left
61–70 of 154 posts
Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left
#62Languages that are difficult for LLM to read & write are also difficult for the general public. These languages have always had poor uptake and never reach critical mass, or are eventually replaced by better languages. Language designers would be smart to recognize this fact and favor making their languages more LLM friendly. This should also make them more human friendly.
Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left
#63Earlier quoted context omitted.
Right, but that smoothly(ish) resolves all at the same time. That might be sufficient, but it isn't actually replicating the thought process described above. That non-linear thinking is different than diffuse thinking. Resolving in a web around a foundation seems like it would be useful for coding (and other structured thinking, in general).
With enough resolution and appropriately chosen transformation steps, it is equivalent. E.g., the diffusion could focus on one region and then later focus on another, and it's allowed to undo the effort it did in one region. Nothing architecturally prohibits that solution style from emerging.
Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left
#64at first they were hilariously bad, then just bad, then kind of okay, and now anthropic's claude4opus reads and writes it just fine.
Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left
#65Humans can't either? I think if this convention had been more usable form of programming, we'd know by now
It might be a question of familiarity rather than objective usability. I'm writing this comment in Latin letters rather than Cyrillic or Hebrew because I find Latin letters much more usable than Cyrillic or Hebrew. But that's because I've been surrounded by Latin letters since I was born, and have only occasionally encountered Cyrillic or Hebrew. I think it's obvious that Cyrillic isn't any less usable than the Latin…
On the contrary, I find it much more usable for left-to-right readers, because it allows a "top-down" reading of the expressions, instead of a "bottom-up" reading.
When trying to understand an unfamiliar program, for debugging or maintenance, you normally do not want to waste time by reading completely all expressions, which provide irrelevant computation details.
You typically search where some variables are modified and how and why. For this it is frequently enough to look only at the last operations that have been performed before storing a modified value into a variable.
With the Iverson notation, the last operations are always conveniently grouped at the left side of a text line. Thus you read from left to right only as much as necessary to find what you need, then you can skip the rest of the line.
With the school notation, the required information is not grouped at one end of the line, so reading becomes slower.
The opposite of the Iverson notation, which was used in some stack-oriented languages, also groups the information, but in a way that is less usable for left-to-right users.
From natural languages, left-to-right readers expect that a sentence starts with its topic (at the left side), i.e. the most important part, e.g. the last assignment, like in the Iverson notation, instead of ending with its topic, like in the opposite notation.
> "a reader must maintain a stack of pending operators and values in their mind"
I believe that few readers, if any, do this.
The normal case when reading is that you do not want to reproduce in your mind what the computer does, but only to find the information flows between program variables. For this, it is enough to read partial expressions, as explained above.
In the very rare case when you wanted to make a mental calculation identical to that of the computer, you would normally read the expression from right to left.
When writing, the Iverson notation is usually more convenient than the school notation, while writing normally, from left to right. The reason is that for most computations the natural way to find the expression that must be computed is to go backwards, from the desired result towards the available data.
Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left
#66don't plan on it staying that way. I used to toss wads of my own forth-like language into LLMs to see what kinds of horrible failure modes the latest model would have in parsing and generating such code. at first they were hilariously bad, then just bad, then kind of okay, and now anthropic's claude4opus reads and writes it just fine.
Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left
#67Languages that are difficult for LLM to read & write are also difficult for the general public. These languages have always had poor uptake and never reach critical mass, or are eventually replaced by better languages. Language designers would be smart to recognize this fact and favor making their languages more LLM friendly. This should also make them more human friendly.
Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left
#68Earlier quoted context omitted.
What would you propose as an alternative to regexes that provides the same functionality without the unreadable syntax? I wrote something like that in C# once [0] but I'm not getting the impression that there's a lot of demand for that kind of thing. [0] https://github.com/Timwi/Generex
Parsing expression grammars (pegs) are usually IME more maintainable long term, partially just because of much more testable and composable they are
Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left
#69Languages that are difficult for LLM to read & write are also difficult for the general public. These languages have always had poor uptake and never reach critical mass, or are eventually replaced by better languages. Language designers would be smart to recognize this fact and favor making their languages more LLM friendly. This should also make them more human friendly.
I actually think Ruby on Rails is incredibly difficult for LLMs to write because of how many implicit "global state" things occur. I'm always surprised how productive people are with it, but people are productive with it for sure.
Most techies (generalizing here) start with a reasonably clear spec that needs to be implemented and they can focus on how to architect the code.
Research - whether science, finance or design - is much more iterative and freeform. Your objective is often very fuzzy. You might have a vague idea what you want, but having to think about code structure is annoying and orthogonal to your actual purpose.
This is why languages like Ruby work well for certain purposes. They allow the person to prototype extremely rapidly and iterate on the idea. It will eventually reach a breaking point where global state starts being an impediment, but an experienced dev will have started refactoring stuff earlier than that as various parts of the implementation becomes stable.
Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left
#70Earlier quoted context omitted.
>Seems like it could easily be training data set size as well. I'm convinced that's the case. On any major LLM I can carpet bomb Java/Python boilerplate without issue. For Rust, at least last time I checked, it comes up with non-existing traits, more frequent hallucinations and general struggle to use the context effectively. In agent mode it turns into a first fight with the compiler, often ending in credit destroyi…
I realized this too, and it led me to the conclusion that LLMs really can't program. I did some experiments to find what a programming language would look like, instead of e.g. python, if it were designed to be written and edited by an LLM. It turns out that it's extremely verbose, especially in variable names, function names, class names, etc. Actually, it turned out that classes were very redundant. But the real in…
There may be emergent abilities that arise in these models purely due to how much information they contain, but I'm unconvinced that their architecture allows them to crystallize actual understanding. E.g. I'm sceptical that there'd be an area in the LLM weights that encodes the logic behind arithmetic and gives rise to the model actually modelling arithmetic as opposed to just probabilistically saying that the text `1+1=` tended to be followed by the letter `2`.