I am not so sure that's this simple.

No matter your preference, programs in dynamically typed languages are still very much deterministic.

To be able to reason about the output of LLMs (though it is debatable how often will this be needed), you want the output from your imprecise human language spec to a deterministic spec (code) to be as easy to review as possible (for correctness, but mostly for any glaring errors). With proper setup, ensuring correctness of one deterministic output (Python) in comparison with another (eg. typed language like Rust) is just a deterministic run away (a test suite) that should not use any tokens from the LLM, and should have no practical differences in compute use.

Static type checking catches a whole class of programming errors for free. Writing tests costs tokens or human time, so you end up needing more code (and probably more CPU time) to achieve the same level of error-checking in a dynamic language.

Very simplistic look, IMO. I'll add another one mostly as a counterpoint (not that I believe it is strictly true, but largely yes!).

Python is a lot more expressive than other languages and has a very terse syntax, and thus requires LLM to output much fewer tokens to achieve the same job compared to other languages.

Adding a few more tests to ensure data conformity on top of what you have to do anyway with a statically typed language still results in fewer tokens overall.

The expressiveness of a language and whether it does static/dynamic type checking are orthogonal. Type inference and generics are a thing in most modern languages. I also think you're underestimating the amount of code you need to guarantee that there are no type errors in your Python code.

You were talking about token economics: expressiveness surely matters there?

Does it have a terse syntax? I main F#, and when I have to work with Python I generally find myself complaining about how verbose it is. (Needing intermediate variables for what should have been a pipeline, the ceremony around parallelism, having to store constructor parameters as object fields, etc.)

It sure does in comparison with most mainstream statically typed languages — if you feel that way about Python, I wonder what you say about Java, C++ or even Rust or Go?

Checking some examples at https://learn.microsoft.com/en-us/dotnet/fsharp/tour, I'd say it's quite similar in verbosity — eg. no need to declare a module in Python since the code already lives in a file that is the module (plus one less indentation level for module level functions); inline function declaration and calling is thereabouts with F# slightly more terse (let vs lambda + spaces vs parenthesis); if-then more verbose in F# (no then in Python, just "if x:"); F# does not seem to need "return"...

In many cases you can avoid intermediate varibles: inline ifs, list comprehensions, lambdas, etc... Constructor arguments are a good point, but this is mostly about idiomatic use instead of language itself: you can simply do

  def __init__(self, **kwargs):
      self.args = kwargs

I'll give you one on the ceremony around concurrency, though! I have different ideas of how it should have been done to shift the cost to the language runtime instead of the developer, but alas... :)

Python is dynamically, strongly typed. It cares a lot about the types of its objects, you can't just mix and match at will.

Perhaps you meant statically typed?

Oops thank you, I did mean static. I should know better as I am a cpp fan. Updated.

This is probably the most intellectualism ive seen anyone put into a comment that is so very, very, obviously wrong.

Yeah, in the age of AI where the whole goal is to not have to think, type as fast as you can with misspellings, and copy paste stuff without thinking, its TOTALLY a better system to worry about the types of whatever you are feeding into llms.

Its about limiting surface area.

The gymnastics people are putting their ops teams through in order to validate oceans of generated slop is insane. Just use Rust and half of that work goes away.

Please stop trying to make Rust happen. You guys are reaching SO hard now.

There is no way that Rust will be faster than simply specifying tests for an agent to run after it has generated code.

If I had said c++ would that have triggered you less?

No.

The future of coding is english, no matter what way you put it. Many people already at this point are hardly writing code and outputting things that work.

And if you want clean structure, thats accomplished with AI too. You can analyze the code for common structures, identify refactoring opportunities, and map it to code organization guidelines.

A compiler is more efficient than an 8 layer llm lasagna stack of tools. Likewise, to stay on topic: a strictly typed language is better than running five python type checkers if you really want type checking.

Its more efficient to have a llm write in a strictly typed language than to duct tape guardrails(either tools or more llm work) after the fact. Depends on what you're building of course. I speak from an industry that ships large executables. (games)

Maybe, but AI models are better at writing python and JS than any other language. Probably because they are the most common and thus had the most code available for training.

Or attach an LSP server with a type checker and require the model to produce strict strongly typed python code