If you don't know what is Pinyin I googled it for you (I didn't know what it is):
Pinyin is a system for writing Mandarin Chinese sounds using the Latin alphabet. Pinyin is commonly used for learning Chinese pronunciation and for typing Chinese characters.
> It might seem weird for us to teach beginners Python, knowing that they’ll then have agents output other, faster languages. I see an analogy here with Chinese: Many people don’t realize this, but children in China first learn Latin characters, which they use to spell out Chinese phonetically, using a system called “pinyin.” They then use their knowledge of Latin characters to learn Chinese characters, whose pronunciation isn’t obvious from the characters themselves.
Pinyin is widely used, but pinyin’s primacy is oversold. Chinese texts start with teaching Chinese characters - many are recognizable to children from daily exposure to begin with, so they don’t need the pinyin. Pinyin only comes in when the character is genuinely unknown.
I've been taking Chinese lessons for a number of years, and my teacher described her son as learning characters via pinyin. But it's quite possible (even likely) that the common ones don't require pinyin, and/or that I misunderstood how it's used. Nevertheless, even if I pushed the analogy a bit, I still think this might happen as a bridge between learning to code and agentic coding.
It’s funny because I consider myself a Python veteran - about a decade or so of Python, and I had exactly the same thought. 99% of my code now is Java. It’s much less pleasant but the “enterprise nobs” just work. Static types, fast with Graal, awesome threading, and the quality of tooling are great - those are all areas that Python severely lacks in and has no interest expanding into, because it is a “fast prototype language”.
That fast prototyping can now be done in annoying but stable languages like Java or Go or Rust (or NET or Swift). So that cuts a massive leg from Python. Who will bother to maintain the ecosystem if a lot of senior folks are leaving in doves? No idea honestly
Python has wonderful set of libraries so it is probably going to stay with us for a while. However, I suspect major takeover by Typescript (despite I like Python more).
I’m a JS/TS dev (and fan) I don’t think either is a replacement for Python. They are not standalone languages but require some runtime to interact with the world (DOM or Node.js etc) which have limited capabilities for interacting with the system - their focus is network services. It’s not that inaccurate to say that JS is just API for a C++ app. :)
Now if .NET was still not so embedded in the Windows ecosystem that would be very interesting to me to jump from TS. As it is I am learning Go instead.
.NET has had Linux support since 2016 or so. The only major part of .NET that is still stuck in Windows is official UI frameworks from MS, though there are third party frameworks like Avalonia that support Linux.
It's an interesting point but I fear Go's FFI is going to kneecap its ability to be widely adopted unless that story improves significantly. It's a lovely language if your interop with other languages is minimal.
I can see Rust (and to some degree, Go) as the modern outputs from AI. My point about Python being Pinyin is that both of these languages have a relatively steep learning curve for someone without programming experience, and that it might be worth learning Python before doing agentic coding in Rust, much as children in China learn Latin characters before they learn characters.
The problem with Rust is that, AI aside, the learning curve is steep. Even senior engineers need to wrap their head around Rust for several weeks.
You can pick up Go or Java in an afternoon. It’s fast, it mostly makes sense. Unless you do very specific low level things I don’t particularly see Rust becoming the de facto norm for the vast amount of enterprise code
I 100% agree about Go. It is definitely going to claim its share, even without AI being particularly good at it, because of its speed, native concurrency, and strong typing. It is much less flexible than Python and clearly loses in some areas — for example, Python’s ML and parsing libraries are far superior. However, for API-focused projects, like a typical Flask or FastAPI app, Go seems more powerful.
I feel like the moment for typescript taking over has come and gone. It also became way more complicated than necessary and that limits its appeal compared to python (not to say python doesn’t have problems of its own)
Interesting. Can you please elaborate more? Is it due to the combination of popular foundation (js) and the addition of strong typing? The runtime environment differences? The ease of integration with other languages / tools?
* Most applications run on the web nowadays. With TypeScript, you can write both the front end and the back end.
* TypeScript shares many syntactic-sugar ideas with Python, but it is also statically typed. Whether that is good or bad is a hot topic, but it gives you a lot of confidence through compile-time checks.
* Running Node for system tasks is as easy as running the Python interpreter. However, Python is still slightly ahead there.
Interesting -- I still think that Python is an easier onramp than TypeScript for new developers. But given the popularity and depth of JavaScript, and the clear advantages (and popularity) of TypeScript in serious development, that's not a bad prediction.
One thing that Python has that virtually no (well okay groovy and nim do too) other programming language has is whitespace for blocks rather than visible braces (or even BEGIN/END ala Wirthian languages). That's something much like line numbers in classic BASIC that introduces a roadblock when learners move on from it.
I don't know if it's that hard for people to go from Python (where whitespace is significant) to languages that use {} and the like. But hey, people only hire me when they want people to learn Python, not when they're moving away from it. :-)
To what extent do you see Python drifting toward stronger typing? I ask because after 10 years without touching a single line of Python, I recently worked on a Python code base and I was very positively surprised by the static typing that's available in the language now. Not even necessary to to reach for additional tooling like JS and TS.
Drifting? I think it's there. basedpyright is awesome and super fast. Our latest services are all CI gated by type checking. Early in my career you'd hit so many dumb errors running your code - NoneType, attribute, value, and type errors. I'd say that's been cut over 95%.
> Why ask AI to write its output in a dynamic language with relatively slow execution (i.e., Python)?
So that it's easy for humans to review it. Same reason as ever. Obviously Python isn't always the correct choice, but the overlap with cases where vibe coding is the correct choice is pretty high.
> Many people don’t realize this, but children in China first learn Latin characters, which they use to spell out Chinese phonetically, using a system called “pinyin.” They then use their knowledge of Latin characters to learn Chinese characters, whose pronunciation isn’t obvious from the characters themselves.
Code isn’t just execution, code is also abstraction. You need to be able to understand requirement => unit of work.
Unless you’re an uber geek this mostly isn’t the case and reading and retaining any amount of assembly will be practically impossible.
In a wishful world you could simply have a bunch of markdown specifications that are executed as machine code. But specifications are by design usually ambiguous, and so you need to build some level of abstraction to be able to accommodate and still understand that. That’s what code does, or should do
It's not portable and in today's world, you have x86 and ARM to contend with. My argument is that should make Java the default language for LLM output.
If you don't know what is Pinyin I googled it for you (I didn't know what it is):
Pinyin is a system for writing Mandarin Chinese sounds using the Latin alphabet. Pinyin is commonly used for learning Chinese pronunciation and for typing Chinese characters.
> It might seem weird for us to teach beginners Python, knowing that they’ll then have agents output other, faster languages. I see an analogy here with Chinese: Many people don’t realize this, but children in China first learn Latin characters, which they use to spell out Chinese phonetically, using a system called “pinyin.” They then use their knowledge of Latin characters to learn Chinese characters, whose pronunciation isn’t obvious from the characters themselves.
The article did explain, albeit near the end.
Pinyin is widely used, but pinyin’s primacy is oversold. Chinese texts start with teaching Chinese characters - many are recognizable to children from daily exposure to begin with, so they don’t need the pinyin. Pinyin only comes in when the character is genuinely unknown.
I've been taking Chinese lessons for a number of years, and my teacher described her son as learning characters via pinyin. But it's quite possible (even likely) that the common ones don't require pinyin, and/or that I misunderstood how it's used. Nevertheless, even if I pushed the analogy a bit, I still think this might happen as a bridge between learning to code and agentic coding.
Pinyin is also the main way people input Chinese into computers, so it's rather important in that regard.
Interesting take. Python is my first language, but when working with AI for my latest desktop project I just used Rust because of the performance.
Why teach people bad habits starting out? Probably dating myself specifically but I started out with Pascal, and I'm glad I did.
It’s funny because I consider myself a Python veteran - about a decade or so of Python, and I had exactly the same thought. 99% of my code now is Java. It’s much less pleasant but the “enterprise nobs” just work. Static types, fast with Graal, awesome threading, and the quality of tooling are great - those are all areas that Python severely lacks in and has no interest expanding into, because it is a “fast prototype language”. That fast prototyping can now be done in annoying but stable languages like Java or Go or Rust (or NET or Swift). So that cuts a massive leg from Python. Who will bother to maintain the ecosystem if a lot of senior folks are leaving in doves? No idea honestly
> quality of tooling are subpar - those are all areas that Python severely lacks in
I do not think subpar means what you think. Or maybe you rewrote the sentence and forgot to change that word? Anyway, this does not make sense.
Indeed, wrong word
Python has wonderful set of libraries so it is probably going to stay with us for a while. However, I suspect major takeover by Typescript (despite I like Python more).
I’m a JS/TS dev (and fan) I don’t think either is a replacement for Python. They are not standalone languages but require some runtime to interact with the world (DOM or Node.js etc) which have limited capabilities for interacting with the system - their focus is network services. It’s not that inaccurate to say that JS is just API for a C++ app. :)
Now if .NET was still not so embedded in the Windows ecosystem that would be very interesting to me to jump from TS. As it is I am learning Go instead.
.NET has had Linux support since 2016 or so. The only major part of .NET that is still stuck in Windows is official UI frameworks from MS, though there are third party frameworks like Avalonia that support Linux.
This is a non-sequitur? Python is also not a "standalone language" and requires "some runtime".
My money would be on Go and Rust. Most of the major downsides of either language go away if you let the agent write almost all of the code
Go might have the advantage because it's easier to read outside the IDE
It's an interesting point but I fear Go's FFI is going to kneecap its ability to be widely adopted unless that story improves significantly. It's a lovely language if your interop with other languages is minimal.
I can see Rust (and to some degree, Go) as the modern outputs from AI. My point about Python being Pinyin is that both of these languages have a relatively steep learning curve for someone without programming experience, and that it might be worth learning Python before doing agentic coding in Rust, much as children in China learn Latin characters before they learn characters.
The problem with Rust is that, AI aside, the learning curve is steep. Even senior engineers need to wrap their head around Rust for several weeks. You can pick up Go or Java in an afternoon. It’s fast, it mostly makes sense. Unless you do very specific low level things I don’t particularly see Rust becoming the de facto norm for the vast amount of enterprise code
> Most of the major downsides of either language go away if you let the agent write almost all of the code
But then you have the major downside of 'writing' poor code.
I 100% agree about Go. It is definitely going to claim its share, even without AI being particularly good at it, because of its speed, native concurrency, and strong typing. It is much less flexible than Python and clearly loses in some areas — for example, Python’s ML and parsing libraries are far superior. However, for API-focused projects, like a typical Flask or FastAPI app, Go seems more powerful.
Not to forget "The Beam" - especially gleam!
A big selling point for Python is the large number of native extensions.
Rust has a huge advantage here, in fact many popular Python libraries use Rust underneath.
Maybe the/a big "selling point" for python is the fact, that many teachers don't know better.
I feel like the moment for typescript taking over has come and gone. It also became way more complicated than necessary and that limits its appeal compared to python (not to say python doesn’t have problems of its own)
Interesting. Can you please elaborate more? Is it due to the combination of popular foundation (js) and the addition of strong typing? The runtime environment differences? The ease of integration with other languages / tools?
Don't underestimate the significance of code being runnable in a browser environment.
A few points that come to mind:
* Most applications run on the web nowadays. With TypeScript, you can write both the front end and the back end. * TypeScript shares many syntactic-sugar ideas with Python, but it is also statically typed. Whether that is good or bad is a hot topic, but it gives you a lot of confidence through compile-time checks. * Running Node for system tasks is as easy as running the Python interpreter. However, Python is still slightly ahead there.
Interesting -- I still think that Python is an easier onramp than TypeScript for new developers. But given the popularity and depth of JavaScript, and the clear advantages (and popularity) of TypeScript in serious development, that's not a bad prediction.
One thing that Python has that virtually no (well okay groovy and nim do too) other programming language has is whitespace for blocks rather than visible braces (or even BEGIN/END ala Wirthian languages). That's something much like line numbers in classic BASIC that introduces a roadblock when learners move on from it.
I don't know if it's that hard for people to go from Python (where whitespace is significant) to languages that use {} and the like. But hey, people only hire me when they want people to learn Python, not when they're moving away from it. :-)
js is a web scripting language that can be strong-armed into running scripts through a runtime.
Python is a general development language that can be used to build servers and web pages, but does a lot more besides.
They're not really comparable.
Having said that - I wouldn't be surprised if Python drifts towards stronger typing, although it will probably remain optional.
To what extent do you see Python drifting toward stronger typing? I ask because after 10 years without touching a single line of Python, I recently worked on a Python code base and I was very positively surprised by the static typing that's available in the language now. Not even necessary to to reach for additional tooling like JS and TS.
Drifting? I think it's there. basedpyright is awesome and super fast. Our latest services are all CI gated by type checking. Early in my career you'd hit so many dumb errors running your code - NoneType, attribute, value, and type errors. I'd say that's been cut over 95%.
How are you getting static typing without additional tooling?
I mean, of course there is tooling involved. But it's part of the language. Unlike TypeScript which is a superset of JS and requires transpilation.
Nowadays a lot of web servers are written in js, for better or worse
Frankly, I prefer Python because I find it more elegant. However, in my industry bubble, I see a clear drift toward TypeScript.
> Why ask AI to write its output in a dynamic language with relatively slow execution (i.e., Python)?
So that it's easy for humans to review it. Same reason as ever. Obviously Python isn't always the correct choice, but the overlap with cases where vibe coding is the correct choice is pretty high.
Also wtf is Pinyin?
> Also wtf is Pinyin?
From the article:
> Many people don’t realize this, but children in China first learn Latin characters, which they use to spell out Chinese phonetically, using a system called “pinyin.” They then use their knowledge of Latin characters to learn Chinese characters, whose pronunciation isn’t obvious from the characters themselves.
If we're not writing code by hand anymore anyway, why not skip programming languages altogether and have the AI output machine code right away?
Code isn’t just execution, code is also abstraction. You need to be able to understand requirement => unit of work. Unless you’re an uber geek this mostly isn’t the case and reading and retaining any amount of assembly will be practically impossible. In a wishful world you could simply have a bunch of markdown specifications that are executed as machine code. But specifications are by design usually ambiguous, and so you need to build some level of abstraction to be able to accommodate and still understand that. That’s what code does, or should do
Code is for human consumption. Believe it or not, some of us like to understand how things work.
Well you can read python, you can't read machine code...
“Vibe coders” don’t read the code their LLM produces. That’s the whole point.
It's not portable and in today's world, you have x86 and ARM to contend with. My argument is that should make Java the default language for LLM output.
Then you could have it output LLVM IR