One obvious reason is Python's extreme readability, it has often been described as being as close to executable pseudo-code as one can get.
If you're using an LLM to write code I think the rules would be
1. Use a language you know really well so you can read it easily, and add to it as needed.
2. Use a language that has a large training set so the LLM can be most efficient.
3. Use a language that is easy to read.
If your language has a small training set or you don't intend to do much addition or you don't really know any language that well or are restricted from using choice 1 for some reason, 2 and 3 move up, and python has a large training set and it is easy to read.
Python is locally readable. Reasoning about larger systems in Python is where things get really hard, because you have to describe how many small individually readable things interact with each other in a very limited vocabulary.
For larger systems you create your own modules and abstractions, so comprehensibility at higher level does not depend so much on the language.
The tools the language gives you to create those abstractions make a lot of difference, however.
But every abstraction that an LLM has to write is a choice. Your way of writing Python may not match that choice. The next run of the agent might not choose the same way.
Because the language gives you many different tools, an LLM generated codebase can get inconsistent and overly complicated quickly. The flexibility of Python is a downside when you’re having an LLM generate the code. If you’re working in an existing codebase, it’s great - those choices were already made and it can match your style.
When an LLM has to derive its own style is when things can devolve into a jumbled mess.
To me applying LLMs to a python (or similarly dynamic) code base where it’s currently spaghetti and monkey patched, it can miss things just like I can.
But… I have to admit Opus 4.7 has been very pragmatic in detecting root causes and proposing sensible fixes to bugs in this situation (ie bugs encountered in production not compile time).
It’s also fine at matching current styles and conventions (which is great if they are good styles and conventions).
In terms of new code, rust would have been near impossible to write with such a high degree of non-local reasoning, so I’m assuming these bugs wouldn’t be present.
This is why good design documents will always be necessary.
When I work with AI I always have it keep an up-to-date architectural document committed to the repository.
Also, we need to be able to understand what is happening under the hood somewhat, so I very much agree the readability is crucial. And frankly, rust is not up there in the readability realm.
I think all the previous language designs still hold for their respective use case. AI written or otherwise. Why? Because performance acceptability is domain specific, and also the algorithms complexity generally determines overall performance.
For example, move the performance critical stuff into a Python C extension like Torch etc…
hmm, yeah given LLM's ability to churn out lots of code quickly and be overly verbose in that code that is a potential downside. That it could in a quick one time edit create so much intellectual overhead that Python might be the wrong language to understand what is going on.
What language do you feel is easier to reason about in the large?
Haskell would be my vote, and Rust too, actually, both because of their very strong type systems. The type system lets you very quickly figure out what something is before you figure out what something does, and it turns out that separating those two concerns as hard as those two languages do often results in doing the whole one-two punch faster.
Haskell does not qualify for a large training set, though. (Nor for readability in my opinion)
I think I have never seen haskell software made wih LLM's but well, aside from university, I have not seen Haskell code at all. (Also Haskell purists I would associate with people who avoid LLM's)
I would rather go with Rust given these choices.
But I have good results with typescript (or javascript for simpler things). Really large set of examples. Tools optimized for it, agents debugging in the browser works allmost out of the box. And well, a elaborate typesystem.
I used Claude to generate Haskell and it works really well. Claude struggles sometimes with respecting abstraction boundaries, but Haskell enforces parts of those boundaries in its type system better than a lot of other languages (if a module can’t do IO, for example).
Works well, in my experience. Sometimes the agent does weird stuff that you have to rewrite, but I get the sense that this happens in any language.
Maybe Haskell’s training set is not large enough, but it seems to work despite the smaller training set.
[dead]
Bit of a nit, it isn't the strong typing that makes Rust great for LLMs, it's the very strict compiler.
Plenty of languages have strong (enough) typing but their compilers happily let you or the LLM footgun yourself.
I'd say Java, because it has a massive footprint amenable for training, and a strong type system (does not have sum types though and those are trendy).
You'd have to steer the LLM to use the style you want, and not massively overarchitect things though, but that's going to be an issue nonetheless.
Java has sum types - they are fairly recent, called sealed records, and can be exhaustively pattern matched on.
(I do agree however, Java is a great target for LLMs)
C# is as close to an ideal language as you can get for most things IMO. I find AI does a great job with it.
I do agree. C# is an hidden gem for IA. There are not that much different ways to get somewhere so the model have probably been trained on the framework and libraries everybody uses (the Microsoft ones).
Compared to most languages, including Java, C# will have a hard time letting you compile incoherent code.
You barely need any dependencies other than aspnetcore and efcore for most applications and your AI knows them well.
It’s easy to do TDD with it so it’s easy to keep your IA from hallucinating.
I definitely agree with the sentiment. However this part.
> There are not that much different ways to get somewhere
This is far from true. C# is a language where you can operate on the raw pointers through unsafe keyword. On the other end of the spectrum, you can have duck-typing in dynamic blocks.
For operating on collections you can use old style loops, or chain of lambdas or sql like syntax.
I have been coding in C# old school way for most of my life at this point, and I feel like I'm in a foreign land reading code from some other C# projects.
I’m curious about the design space of languages & frameworks which are lower level than LLM prompts but higher level than Python, Ruby and Common Lisp.
Do you have any recommendations for systems where reasoning about large systems is easier than in python?
You have to go into live programming, code in a system, and saving images. Readability is no longer a factor, what you want is easy access to documentation, quick navigation, and a playground.
That’s true. Once you have APIs and want to use classes to create larger structures, the language is full of warts.
I have built large systems on python that use classes, for more than ten years. I came to it from Java, ten years.
As a rule, I avoid implementation inheritance. Occasionally I need to facade a library that assumes implementation inheritance to avoid it spreading into my codebase.
When the codebase hits a certain size, I hand-roll some decorators to create functionality like java interfaces. With that done, and a suite of acceptance tests, I find it scales up well.
Python is amazing for scripting.
Python is terrible for writing big systems.
Projects whose V1 is written in Go/Rust/C++ don't normally go out and re-write V2 in Python.
The reverse is really common.
Even many famous Python packages are now Python wrappers.
https://ashishb.net/programming/python-in-production/
> Projects whose V1 is written in Go/Rust/C++ don't normally go out and re-write V2 in Python.
That's because you would usually rewrite your Python program in something like C++ if you realise that it's too slow and you need the speed of a compiled language, despite the enormous extra complexity to create and maintain it that way.
You wouldn't go back the other way because it's very rare to go to all that extra effort writing in a more efficient language only to realise that the slower performance of Python would've been adequate after all. And, thanks to sunk cost fallacy, even someone that does realise it is unlikely to make the switch back.
There's no way you could convince me that writing your program in C++ is easier to code in, even for a very large system, than Python. C# maybe.
> Even many famous Python packages are now Python wrappers.
Of course! That's precisely because Python is much simpler to code in. If your Python libraries are wrappers around native code then you get the speed benefit without having to drop into those languages. (Plus they can release the GIL, allowing true multithreaded Python.)
If native coding languages were good enough then there would be no need for Python wrappers - you'd just call into the native library directly.
That and how many developers who would write first round in Go/Rust/C++ would think it beneath them to write in Python :) The complaints alone wouldn't be worth it even if there was some suprising specific use case.
If you use the typing system (which I do religiously) Python becomes a lot easier to reason about in larger projects it also makes linters and refactoring tools easier to use.
I dont know if the reasoning for a rewrite is purely for maintainability though. Ive used python at scale and its fine if you have reasonably good code hygiene. The reason I'd want to rewrite in any of those languages is they're significantly faster _and_ are maintainable at scale.
> Ive used python at scale and its fine if you have reasonably good code hygiene.
True but that's the problem. Once you have a big enough team, it becomes an uphill battle to maintain that.
Exactly. A lot of people forget that Python is just shell scripting++, taken way too far.
Python is faster to write so obviously you'll see things built in Python first more often than the reverse. What's that quote -- "Better to remain silent and be thought a fool..."
Indeed. Python is faster to write and harder to maintain over the long run.
The "faster to write" advantage becomes less relevant if most code is going to be auto-generated.
The "harder to maintain" might still remain more relevant.
I never really understood what exactly is so readable about python. I've been developing in Python for 8 years now, and before that I was a C# developer, and I don't find Python to be that more readable.
Sure there's less ceremony, and yes, you can have your project going with just a single file, but other than that...?
If you're doing non-CS academic research and you get only one course/module to teach the new grad students "programming", python it is. That you can get a project going with 3K LoC in a single file is a bonus in academia :)
The scipy/numpy dataframes model is really neat though, python's has all the cool machine learning features, and since they're just a wrapper around some C++ and FORTRAN, it runs fast too if you do things properly.
I think the meme come from the fact that in 00s and early 10s most people looked at Python code coming from C++ and Java.
In Java bad OOP conventions were commonplace, like everything using getters/setters, deeply nested class hierarchies and insane patterns like AbstractSingletonProxyFactoryBean. It got impossible to figure out what's going on.
C++ just got every possible feature that badly interacts with each other, in an amount that never could fit in a single person's context window. That basically led to a situation where every programmer or company had it's own dialect of the language; the other dialects than your own were mostly incomprehensive.
Python has it's own share of bad features, and for a long time really bad ecosystem around the language - Python 2 vs Python 3; eggs vs wheels; easy_install vs pip; 123489 ways of installing Python and each of them bad. But, once it started to become better, in the mid-late 10s, around Python 3.5 or 3.6, it exploded in popularity.
Python data processing/ML in the 2010s became a huge asset for the language.
C++ and Java and … Perl.
C# is also a great language, but notice how it have been moving closer to Pyhon-style syntax. E.g. now you can initialize a list like [a, b, c]. They wouldn’t add that syntax if they didnt think it was an improvement.
Less ceremony and boilerplate means more readable code.
Reaaaally?
I think a lot of the readability of python is in the fact you don't need to be recently familiar with it to pick up what its doing most of the time.
Over my career I've dipped in and out of rust, typescript, perl, swift, etc codebases. I'm no expert in any of these, but every single time I have to look something up to understand what this set of arcane symbols or syntax means.
When I dip into Python I just ... read it.
(None of this is to say I prefer Python, just that I really do get the readable thing)
"whitespace, not brackets" from a sibling comment touches on it, but a lot of people, beginners especially (but not uniquely), are put off by symbols when reading code. Python is less symbol-heavy than most languages, by using whitespace and syntax and words (eg. `and` not `&&`, explicit `lambda x:` rather than `x =>`) in their place. It doesn't go so far as COBOL as to be cumbersome, but far enough to make a difference to a lot of people.
I agree, especially very "pythonic" structures if overly shortened are hard to decipher especially if you don't use or read python on a regular basis.
Often times when I am reading a medium or advanced python codebase I need to look into the function definitions and operator documentation to understand what is supposed to be returned. Where with C-like languages I feel it is easier to build that context because there is more context written and less tricky syntactic sugar.
> if overly shortened are hard to decipher especially if you don't use or read python on a regular basis.
Sure, but this is the case for any language.
Python USED to be easy to read, before a lot of the newer features like type hints crept in. 20 years ago, Python looked like executable pseudocode.
I agree. My kotlin is readable. The functional code with typing all the way tells what every step is doing. My same code in python is a hot mess of nested list comprehensions and lacking lambdas.
" and before that I was a C# developer"
So .. you were already trained in reading abstract.
A beginner on the other hand sees lots of intimitading {} in C family languages everywhere. And Python does not need them and less is usually better in design.
The "other than that" is whitespace, not brackets. Whether that's a big deal is up to you, but the carry on effect of that is that the code is indented the way the control flow interprets it, so there are no bugs from misplaced braces. (Plenty of other bugs for other reasons, unfortunately.)
Whitespace forcing proper indentation practices has always been one of my favorite aspects of python. I TA'd a data structures in C++ class and the lack of proper indentation making code unreadable was my biggest pet peeve. I always made the student fix their indentation before I would help them debug it.
I know that is mainly a beginner coding issue, but never having to deal with that issue was always one of the biggest advantages of python.
That said, I believe a lot of the stuff that was added in 3 and beyond (to make it more typesafe, accounting for unicode, etc) has made it a lot less readable over time. You can argue that it has made Python a better and safer language, but the pseudocode aspect has gotten worse. I kinda miss that.
I find brackets help me understand structure from a distance much better than whitespace.
Misplaced brackets seem like a thing from the past to me when we didn't have IDEs. I don't remember ever having a bug due to that.
> I find brackets help me understand structure from a distance much better than whitespace.
I can't imagine how. Whitespace physically lays out the block structure on the screen; braces expect you to count and balance matching symbols, and possibly scan for them within other line noise.
This is a 00s POV. If you spend any time on syntax formatting in 2026, you're wasting it. It's a solved problem.
Any reasonable language with braces has standard formatter that will just put each brace level on a different whitespace level.
Working in C# i feel basically still read code structure by the visual block structure / indentation. I dont think I've ever counted braces in my professional life. The IDE makes sure it is formatted correctly and ambiguity is basically impossible.
Whitespace and braces work together to make the code more readable; both by the computer and the human. And they make it less likely to have errors, because the braces convey intent (much like parens in math when they're not "needed")
Nevertheless it happens that while moving code around one wonders what indentation level that code should go. Undo, undo or git show the original code, look at it, retry more carefully.
Brackets would allow the editor to autoindent the pasted code.
No choice is perfect.
So you would find bracketed code without any use of indentation easier to read than python?
It's no more 1990, when Python was born. Editors have been automatically indenting bracketed code for a long while. Probably notepad doesn't, or maybe plain vanilla vim.
Python and C are the only language in which I have experienced that class of bugs. And that is due to if statements without brackets in C and because Python has meaningful indentation which people have accidentally messed up when refactoring.
And today with autofotnatters I think only Python is still vulnerable.
If you are messing up indentation accidentally during refactoring there is either something wrong with your tooling (including your text editor) or you are letting things get too far out of hand before starting the refactoring.
Ah, the old "you're doing it wrong" argument. Moving code from one place to another (copy/paste from online or just from one file to another) is a fairly common source of bugs for a lot of people when it comes to Python. At some point, it becomes clear is an issue with the language, not the people.
I enjoy Python, but the significant whitespace is _not_ one of the reasons.
People confuse having fewer keywords/concepts to learn for readability, which is not really the same thing.
Someone who is equally expert at Java and Python will probably consider Java to be more readable.
The concept of "readable" is not really relevant for experts, because, well, they are experts. Being an expert automatically means you can read almost any line of code and know everything it does.
Everyone else appreciates and is more efficient working with code that is intuitive to grasp.
I have many years of experience with Java, and rarely use Python... and I'd say Python is, in general, easier to read. There's generally a lot less "having to go look at _other_ code to know what _this_ code is doing".
Other than that? Exactly that!
[dead]
Python is great at AI code gen for a combo of reasons: big stdlib, readable, 3rd party libraries to do most anything with great online documentation, big mind-share and presence online.
The big one to me is that it's interpreted. Claude Code does these wild `python -c` "one-liners" that end up spanning a hundred lines or more. It's so ingrained that it does this for solving general problems to create on-the-fly system reports, not just when you specifically are using it for Python development.
One of my more interesting experiments has been "mirroring" a Python codebase I maintain with a synchronized one in another language the AI maintains.
My preferences are always Go first and Python if there are specific libraries that make my life easier.
Go is a simple target for LLMs as the language has changed very little and with the Jetbrains go-modern-guidelines[0] skill the LLM can use the handful of recent additions effectively
And with Python there are things like ruff and pydantic that can enforce contracts in the code.
[0] https://github.com/JetBrains/go-modern-guidelines
The folks I work with rave about how well the LLMS work with Go.
I think this is where D language make an excellent alternative to Python for AI assisted coding [1].
1) It's a very consistent language even if you compared to the other popular languages namely Python, Rust, C++ and Go. Try to perform doubly linked list with them and compare them all [1].
2) It's probably the most "Pythonic" among the compiled language according to Walter.
3) It utilizes GC by default, you can also manage your own memory and you can hybrid.
4) It compiled fast and run fast, heck it even has built-in REPL eco-system.
5) Regarding the small training set, with recent self-distillation fine-tuning approach it should be good enough, D (actually D2 version) has been around for more than a decade [2].
[1] Looking for a Simple Doubly Linked List Implementation:
https://forum.dlang.org/thread/osmecwfnpqahoytdqpkr@forum.dl...
[2] Awesome D:
https://github.com/dlang-community/awesome-d
> 2. Use a language that has a large training set so the LLM can be most efficient.
I seriously doubt this is really the case. From my experience coding agents just love writing bad python code. It always needs explicit instructions for example to use uv instead of raw dogging pip. There is a lot of python code out there because it is being taught as a beginner language and because of that there is necessarily a lot python code written by beginners. That's my explanation at least for bad LLM generated python code.
No, I think the argument from the article is pretty good. Use a language that has a lot of guard rails built in.
or a compiler that makes the llm sad
tbh python seems really unreadable to me, and i'm saying that as someone who's first [non-Scratch] programming language was that. stuff with syntax closer to C or javascript seems easier to see [C?] where stuff starts and ends
I would assume it's important to know what's in that training set too
Because I get reliable generation out of "niche" languages already
Is it code with lots of SQL injections used in a different domain to your own?
It's maybe not good to conflate quantity with quality
This is dated, but a professor told me that LLMs are really really good a generating bad pandas code because it's been trained on so much of it!
> One obvious reason is Python's extreme readability, it has often been described as being as close to executable pseudo-code as one can get.
But it's LLMs that read it not humans. At least that's the trend
> Use a language that has a large training set so the LLM can be most efficient.
It's pretty efficient with Rust.
But plenty of humans like to be able to read the generated code and understand / edit that.
Haskell is more readable. It looks just like pseudocode. Change my mind.
c llm code is more readable as it probably trained on better code
Disagree, it's verbose, but it's full of needleslly verbose stuffs, use many _ for everything and the rest, and other opaque conventions. Not that any other dev ecosystem is free of any of these issues, but Python just don't shine much on them. If anything in term of script language, Ruby provides a far more solid ground for compact and readable exposure of ideas through something close to prosaic expression.
So in short, use Javascript /s
I think that pseudocode aspect is what makes it hard/frustrating to read for me.
I'm more of a c++/TS/etc user, so I miss braces a lot. I think a basic Python script sure it's easy to read through, but a large project starts to get quite ugh.
I am very jealous of Python's numerous built-ins though. I was looking for a JS sum function the other day and was surprised to see node.js still doesn't have a built in + you still cannot reference operator functions.
But at least JS now has a built-in leftpad function ;) (called padStart).
Lmao are people really -ing me because I don't like Python. Tribalism is present in all areas of human life I suppose.
You people should grow up. Programming languages are tools, not pets.