[zenkey]

I've been programming with Python for over 10 years now, and I use type hints whenever I can because of how many bugs they help catch. At this point, I'm beginning to form a rather radical view. As LLMs get smarter and vibe coding (or even more abstract ways of producing software) becomes normalized, we'll be less and less concerned about compatibility with existing codebases because new code will be cheaper, faster to produce, and more disposable. If progress continues at this pace, generating tests with near 100% coverage and fully rewriting libraries against those tests could be feasible within the next decade. Given that, I don't think backward compatibility should be the priority when it comes to language design and improvements. I'm personally ready to embrace a "Python 4" with a strict ownership model like Rust's (hopefully more flexible), fully typed, with the old baggage dropped and all the new bells and whistles. Static typing should also help LLMs produce more correct code and make iteration and refactoring easier.

[_ZeD_]

You think of code as an asset, but you're wrong: code is a cost.

Feature is what you want, and performance, and correctness, and robustness; not code

Older code is tested code, that is known to work, with known limitations and known performances

[shiandow]

A corollary is that if at all possible try to solve problems without code or, failing that, with less code.

[abirch]

I agree, older code is evidence of survivorship bias. We don't see all of the code that was written with the older code that was removed or replaced (without a code repository).

[anon-3988]

> I'm personally ready to embrace a "Python 4" with a strict ownership model like Rust's (hopefully more flexible), fully typed, with the old baggage dropped and all the new bells and whistles. Static typing should also help LLMs produce more correct code and make iteration and refactoring easier.

So...a new language? I get it except for borrow checking, just make it GC'ed.

But this doesn't work in practice, if you break compatibility, you are also breaking compatibility with the training data of decades and decades of python code.

Interestingly, I think as we use more and more LLMs, types gets even more and more important as its basically a hint to the program as well.

[pjmlp]

I think people are still fooling themselves about the relevance of 3GL languages in an AI dominated future.

It is similar to how Assembly developers thought about their relevance until optimising compilers backends turned that into a niche activity.

It is a matter of time, maybe a decade who knows, until we can produce executables directly from AI systems.

Most likely we will still need some kind of formalisation tools to tame natural language uncertainties, however most certainly they won't be Python/Rust like.

We are moving into another abstraction layer, closer to the 4GL, CASE tooling dreams.

[mpweiher]

"Since FORTRAN should virtually eliminate coding and debugging…" -- FORTRAN report, 1954 [1]

If, as you seem to imply and as others have stated, we should no longer even look at the "generated" code, then the LLM prompts are the programs / programming language.

I can't think of a worse programming language, and I am not the only one [2]

However, it does indicate that our current programming languages are way to low-level, too verbose. Maybe we should fix that?

[1] http://www.softwarepreservation.org/projects/FORTRAN/BackusE...

[2] https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

[3] https://objective.st/

[albertzeyer]

4GL and 5GL are already taken. So this is the 6GL.

https://en.wikipedia.org/wiki/Programming_language_generatio...

But speaking more seriously, how to get this deterministic?

[dragonwriter]

> I think people are still fooling themselves about the relevance of 3GL languages in an AI dominated future.

I think, as happens in the AI summer before each AI winter, people are fooling themselves about both the shape and proximity of the “AI dominated future”.

[Wowfunhappy]

Assemblers and compilers are (practically) deterministic. LLMs are not.

[sitkack]

> It is a matter of time, maybe a decade who knows, until we can produce executables directly from AI systems.

They already can.

[zenkey]

Yes I agree this is likely the direction we're heading. I suppose the "Python 4" I mentioned would just be an intermediate step along the way.

[krembo]

Wild thought: maybe coding is a thing of the past? Given that an llm can get fast&deterministic results if needed, maybe a backend for instance, can be a set of functions which are all textual specifications and by following them it can do actions (validations, calculations, etc), approach apis and connect to databases, then produce output? Then the llm can auto refine the specifications to avoid bugs and roll the changes in real time for the next calls? Like a brain which doesn't need predefined coding instructions to fulfill a task, but just understand its scope, how to approach it and learn from the past.

[kryptiskt]

I'd think LLMs would be more dependent on compatibility than humans, since they need training data in bulk. Humans can adapt with a book and a list of language changes, and a lot of grumbling about newfangled things. But an LLM isn't going to produce Python++ code without having been trained on a corpus of such code.

[johnisgood]

It should work if you feed the data yourself, or at the very least the documentation. I do this with niche languages and it seems to work more or less, but you will have to pay attention to your context length, and of course if you start a new chat, you are back to square one.

[energy123]

I don't know if that's a big blocker now we have abundant synthetic data from a RL training loop where language-specific things like syntax can be learned without any human examples. Human code may still be relevant for learning best practices, but even then it's not clear that can't happen via transfer learning from other languages, or it might even emerge naturally if the synthetic problems and rewards are designed well enough. It's still very early days (7-8 months since o1 preview) so to draw conclusions from current difficulties over a 2-year time frame would be questionable.

Consider a language designed only FOR an LLM, and a corresponding LLM designed only FOR that language. You'd imagine there'd be dedicated single tokens for common things like "class" or "def" or "import", which allows more efficient representation. There's a lot to think about ...

[zzzeek]

> As vibe coding becomes normalized

Just want you to know this heart monitor we gave you was engineered with vibe coding, that's why your insurance was able to cover it. Nobody really knows how the software works (because...vibes), but the AI of course surpasses humans on all current (human-created) benchmarks like SAT and bar exam tests, so there's no reason to think its software isn't superior to human-coded (crusty old non "vibe coded" software) as well. You should be able to resume activity immediately! good luck

[lioeters]

Welcome to the flight, this is your captain speaking. Just want to let you know our entire flight system was vibe coded to the strict standards you expect from our industry, iterated and refined in a virtual environment over twenty virtual-years, with no fallible human eyes reviewing it - even if it were possible to review the mountain of impenetrable machine-generated code. The pilot will be controlling the plane via a cutting-edge LLM interface, prompt-engineering our way to our overseas destination. Relax, get comfortable, and pray to the collective intelligence distilled from Reddit posts.

[brookst]

What percent of applications require that level of reliability?

Vibe coding will be normalized because the vast, vast majority of code is not life or death. That literally what “normal” means.

Exceptional cases like pacemakers and spaceflight will continue to be produced with rigor. Maybe even 1% of produced code will work that way!

[adsharma]

You described the thinking behind py2many.

Code in the spirit of rust with python syntax and great devx. Give up on C-API and backward compat with everything.

Re: lifetimes

Py2many has a mojo backend now. You can infer lifetimes for simple cases. See the bubble sort example.

[fulafel]

> embrace a "Python 4" with a strict ownership model like Rust

Rust only does this because it targets low-level use cases without automatic memory management, and makes a conscious tradeoff against ease of programming.

[procaryote]

100% coverage won't catch 100% of bugs of course

[mountainriver]

At the point which you describe we could easily write Rust or even just C

[mdaniel]

> Static typing should also help LLMs produce more correct code and make iteration and refactoring easier.

You say that as if they "understand" and, as actual usage has shown us, if they're perfectly comfortable making up whole function names I'm super confident a little nuance of "what type is this?" is not going to stand in their way of just placating the requestor

[pseudony]

Ownership models like Rust require a grester ability for holistic refactoring, otherwise a change in one place causes a lifetime issue elsewhere. This is actually exactly what LLM's are doing the worst at.

Beyond that, a Python with something like lifetimes implies doing away with garbage-collection - there really isn't any need for lifetimes otherwise.

What you are suggesting has nothing to do with Python and completely misses the point of why python became so widely used.

The more general point is that garbage collection is very appealing from a usability standpoint and it removes a whole class of errors. People who don't see that value should look again at the rise of Java vs c/c++. Businesses largely aren't paying for "beautiful", exacting memory management, but for programs which work and hopefully can handle more business concerns with the same development budget.

[pjmlp]

While I go into another direction in a sibling comment, lifetimes does not imply not needing garbage collection.

On the contrary, having both allows the productivity of automatic resource management, while providing the necessary tooling to squeeze the ultimate performance when needed.

No need to worry about data structures not friendly to affine/linear types, Pin and Phantom types and so forth.

It is no accident that while Rust has been successful bringing modern lifetime type systems into mainstream, almost everyone else is researching how to combine linear/affine/effects/dependent types with classical automatic resource management approaches.

[vlovich123]

Rust lifetimes are generally fairly local and don’t impact refactoring too much unless you fundamentally change the ownership structure.

Also a reminder that Rc, Arc, and Box are garbage collection. Indeed rust is a garbage collected language unless you drop to unsafe. It’s best to clarify with tracing GC which is what I think you meant.

[oivey]

I mean, why not just write Rust at that point? Required static typing is fundamentally at odds with the design intent of the language.

[trealira]

A lot of people want a garbage collected Rust without all the complexity caused by borrow checking rules. I guess it's because Rust is genuinely a great language even if you ignore that part of it.

[tgv]

Not only that: Rust is considerably faster and more reliable. Since you're not writing the code yourself, Rust would be an objectively better choice.

Who are we trying to fool?

[poulpy123]

Why would you want a fully typed, with ownership model python ? Especially if you consider that backward compatibility is useless ?

[throwaway48476]

I would like an optionally garbage collected version of rust for less performance critical parts.

[qaq]

You pretty much described Mojo