Grace Hopper's Revenge(thefuriousopposites.com) |
Grace Hopper's Revenge(thefuriousopposites.com) |
It's tempting to argue that a more constrained language helps, but Rust (62.8%) vs Elixir (97.5%) is an interesting data point here. Both are highly constrained, but in different directions. Elixir's constraints narrow the solution space because you can't mutate, you can't use loops, and you must pattern match, so every constraint eliminates options and funnels you toward fewer valid solutions that the LLM has to search through. Rust adds another constraint that must independently be satisfied on top of solving the actual problem, where the borrow checker doesn't eliminate approaches but adds a second axis of correctness the LLM has to get right simultaneously.
Overall, it seems like languages with strong conventions and ecosystems that narrow the solution space beat languages where there's a thousand ways to do something. Elixir has one build tool, one formatter, one way to do things. C#, Kotlin, and Java have strong ceremony and convention that effectively narrow how you write a program. Meanwhile JS, Python, PHP, and Perl offer endless choices, fragmented ecosystems, and rapidly shifting idioms, and they cluster at the bottom of the table.
Racket is a similarly large PL, with many abstractions built on the metaprogramming primitives it offers. Without looking at the generated code, it's hard to say anything, but I suspect the high score despite that might be because of the Scheme core of Racket: `racket/base` is a much smaller language than `racket`, so if the LLMs keep to it, it might narrow the solution space enough to show different results.
In general, I think you're half-right: the "solution space" size is a factor, but so is its shape - ie. which features specifically are offered and how they interact. A more compact and cohesive language design should yield better results than just a reduced surface area. C is not a huge language, but the features it offers don't lend themselves to writing correct code much. Elixir is both relatively small and strongly steers a programmer towards safer idioms. Racket is big, but the advanced features are opt-in, while the baseline (immutable bindings, pure functions, expressive contracts) is similar to Elixir. Python is both huge and complex; "there's one obvious way to do it" has always been a bit of a joke. Rust is incredibly complex - the idea is that the tooling should allow you to handle that complexity easily, but that requires agents; one-shotting solutions there won't work as well.
Immutable by convention + Strong conventions: 91.3% - Elixir 97.5%, Kotlin 90.5%, Racket 88.9%, C# 88.4%
Immutable by convention + Fragmented: 78.4% - Scala 78.4% (n=1)
Mutable + Strong conventions: 77.5% - Ruby 81.0%, Swift 78.5%, Julia 78.5%, Dart 78.0%, Go 71.7%
Mutable + Fragmented: 67.9% - Java 80.9%, R 75.8%, C++ 75.8%, Shell 72.9%, Python 65.3%, Perl 64.5%, TS 61.3%, JS 60.9%, PHP 53.8%
(my grouping is somewhat subjective)
Anyway, I tend to think you are right, and the article is wrong in that sentence. (Or I misinterpreted something?)
I think both the quantity and quality of that has a big influence in the results.
I don’t know about the premises here. All of these articles are written to hammer two points.
- AI is the future/AI has been here since X months ago
- There are still people who don’t believe that—to me an unfathomable position as I have personally spent five gazillion tokens on
And the supposed topic of the article is incidental to that.
But if GenAI is the future I’ll take GenAI formal verification and code generation over mindless code generation, thank you very much.
2) The Tesla section is interesting. I'm not saying that you are wrong, just that their methods have not produced the promised results yet
3) Wireless humanoid robots is a bad platform because we don't have the hardware to support them. Both battery density and compute efficiency is too low currently to support freestanding robots. Rip Roomba - long live its legacy
The flaw in Tesla's engineering choice to rely on a camera based system for self driving is that it is extremely difficult to approximate human vision with cameras alone. The author also does not mention this and instead assumes that "camera == human eye" which is not true.
>3) Wireless humanoid robots is a bad platform because we don't have the hardware to support them. Both battery density and compute efficiency is too low currently to support freestanding robots. Rip Roomba - long live its legacy
Boston Dynamics already has Atlas, with a 4 hour battery life and the ability to self-swap. That is already better than a human since it can presumably work non-stop for its entire runtime. Plus battery technology and compute efficiency are both still improving.
Seems a huge assumption to me. From the data one could equally conclude that JavaScript and Python have lower code quality _because_ the quantity of training data, e.g. more code written by less experienced developers
Weren't we taught that recycling is good?
We're getting drowned by "good enough". Not "good" mind you, just "good enough".
Well, the AI can at least be constrained to "the code actually compiles, runs, and produces the correct output."
The number of internet answers that can't pass that bar is distressingly high.
In general I’m tired of the “humans need never, and should never look at the code” LLM triumphalism articles. Do these folks ever work with real systems, I wonder.
Cue in "non-determinism" retort.
Will people start .gitignore-ing their src directories and only save prompts?
Yeah compilers are deterministic and LLMs are not. The response to that?
The answer could very well be something like what’s in TFA namely formal verification. But an answer here is needed.
The rest is AI-fluff:
> This isn't about optimizing for humans. It's about infrastructure
> But the bottleneck was never creation. It was always verification.
> For software, the load-bearing interface isn't actually code. Code is implementation.
> It's not just the Elixir language design that's remarkable, it's the entire ecosystem.
> The 'hard' languages were never hard. They were just waiting for a mind that didn't need movies.
Are people starting to write and talk in this manner, I see so many YouTube videos where you can see a person reading an AI written text, its one thing if the AI wrote it, but another if the human wrote it in the style of an AI.
As someone pointed out to me the way an AI writes text can be changed, so it is less obvious, its just that people don't tend to realise that.
The video was a biography about some Olympian, and I could tell the prompt included some facts about her wanting to be a tap dancer as a kid, because the video kept going back to that fact constantly. Every few sentences it would reference “that kid who wanted to be a tap dancer”. By the 6th time it brought up she wanted to be a tap dancer I was ready to scream.
"X isn't A, it's (something opposite A)" I twitch involuntarily.
https://www.pimlicojournal.co.uk/p/mps-are-almost-certainly-...
http://literateprogramming.com/
Is LLM what will finally push LP into mainstream acceptance?
Maybe so, but I find the right tool, for the right job, is important. Trying to use a screwdriver for every task, is going to result in bruises and cuts (and gouges in the work).
I've used a pretty "chimeric" approach, for most of my career, and the LLM that I use, doesn't seem to have an issue with that. Many of its responses, seem to take a similar approach.
The article starts from a false premise: that AI assisted coding makes the code more understandable. This isn't the case. You either understand the code without AI or offload that reasoning onto the AI, at which point its not you that understands the code.
A person could argue AI writes original code more understandable at maintenance time than they could on their own. This is equally problematic for the same reason. If a person has a lesser understanding of the code at original authoring they will have a lesser understanding of the edge cases and challenges that went into the reasoning about that original code and its those thought challenges which inform the complexities of maintenance, not the simplicity of the base code.
As an analog its like being given a challenging game puzzle to solve. After realizing the game requires extended effort to reach the desired goal the person searches online for the puzzle solution. At the game's next level they encounter a more challenging puzzle, but they never solved the prior puzzle, and so cannot solve this puzzle. In effect all understanding is destroyed and they have become utterly reliant on spoon-fed solutions they cannot maintain themselves.
Is there a future in which functional languages finally see wide adoption due to this LLM suitability? I can’t say that I would object!
[1] Not because you can't solve it in C, but because you'll be fighting the language along the way.
I mean, we called them objects, but coupling related state (and functions) together seem an objectively (object-ively) way to group data, it's literally just dict-based organisation.
For example, "burn, then rape, pillage, and plunder" never works out quite right.
Any methodology or tool, really. Eventually, we're all just participating in cargo cults.
I mean, I guess I interpreted the chart in tfa to indicate that this doesn't always happen.
You can build a system with non-deterministic properties but you need some sort of deterministic foundation to build working, usable systems. Non determinism from top to bottom is building on quicksand in a swamp.
[1] https://www.oreilly.com/radar/can-language-models-replace-co...
And, arguably, the primary reason that perforce is still popular in some domains is that it works well with both large and opaque objects.
Once you've decided to version your src directory, whether a priori or because once bitten, twice shy, the next question is:
Is git the correct version control for this? Or are all the changes so large that git's advantages in merging and manually diffing things become irrelevant?
Yet somehow this didn't stopped a giant software industry existing.
I was asking you for a refutal, after all, not asking myself. Sarcastically pointing to compilers and meatbags in order to triumphantly conclude, aha so there’s a chance, isn’t quite it.