upvote
For larger systems you create your own modules and abstractions, so comprehensibility at higher level does not depend so much on the language.
reply
The tools the language gives you to create those abstractions make a lot of difference, however.
reply
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.

reply
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?

reply
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.
reply
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.

reply
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.
reply
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.

reply
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.

reply
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.

reply
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?

reply
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.
reply
That’s true. Once you have APIs and want to use classes to create larger structures, the language is full of warts.
reply
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.

reply