Rendered at 21:37:42 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
maxheiber 1 days ago [-]
The post is built around a metaphor based on a misunderstanding. The following is not a "well-actually", but is to illustrate that the real world is often stranger and harder to predict and categorize than we might expect. From the post:
> '''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.”'''
My understanding is that children in China learn many characters before pinyin. Characters are mapped to meanings first, and only later to sounds. Fwiw even in my Chinese-as-a-second-language course we were thrown into Chinese characters from the beginning.
Also, of course, Chinese characters have been around for thousands of years and sound-based writing for Chinese is very new. The techniques to get leverage and build up understanding of characters gradually are incredibly varied. Just as the ways we relate to code in the future are unlikely to be familiar or easy to predict.
drob518 1 days ago [-]
The post focuses on Python, but I think it touches on an interesting question before skipping past it: ideally, what language would be best for our AIs to be programming in? The article says Rust. But can we do better? Rust has strong typing and memory guarantees which I think are important, but it’s also slower to compile. If we’re going to be doing agentic programming, where the agent is operating in a tight loop, iterating on the code, then it seems like we’d want something that can be faster to run after creating new code. Effectively, we’d want the agentic equivalent of a Lisp REPL, but optimized for the agent, or at least a language that compiles quickly, as it is run. This is one of the roles that Python plays today. Perhaps there is also a slow, sophisticated compiler that digests the same syntax and spits out the fastest , most secure code possible once the agent has iterated its way to the final answer.
reuven 1 days ago [-]
A very interesting point. Coding with AI definitely requires tight, fast loops. I don't have much experience with Rust, but I had heard that the compiler is slow (because it's doing so much thinking and checking in advance).
I'm OK with Lisp output, but maybe that just shows how old I am. :-)
I wonder if it's possible (or wise) to have two different compilers for a language -- one that's optimized for such tight loops, and another that does thorough checking, etc. You know, kind of like -O, but at a much deeper level.
aw1621107 1 days ago [-]
> but I had heard that the compiler is slow (because it's doing so much thinking and checking in advance).
The compiler is indeed not particularly speedy, but the reason you were given is not entirely accurate. As measured in this blog post [0] different parts of the compilation pipeline will take different amounts of time depending on what you're doing (cargo check vs. incremental build vs. full build, building a library vs. binary, etc.), but generally speaking type/borrow checking take up relatively small portions of compilation time (~15% or less, based on eyeballing the charts [1, 2]) compared to everything else.
> one that's optimized for such tight loops, and another that does thorough checking
I think that would risk producing diverging language subsets, especially if the checks are essential for language semantics. For example, what exactly does it mean if a program passes the "relaxed" compiler but fails the "thorough" one? How close does that actually get you to a "real" working program?
I mean if we're getting really serious about ai-first development, we might be able to get away with a ton of micro services written with clear, simple apis to communicate all in a giant mono-repo managed by an army of agents. That way the full surface any one agent has to touch is small, compile time of each individual service is very fast, and services can be hand-written if super critical.
Anyway, I've played around with the idea a bit so far, and it seems that current agents/harnesses use way more tokens with that architecture.
pjmlp 1 days ago [-]
This exactly how integrating tools with AI agents in low code/no code orchestration engines looks like.
See Workato, Bomi, LangFlow,...
yjftsjthsd-h 1 days ago [-]
It seems like the obvious point of tension is that you probably want AI to be constrained to/by some rigor. Rust is good because it enforces some safety measures, but I'm more interested yet in the work to have AI work with lean4 or the like to prove its code is up to spec. But that proof checking is probably in direct conflict with fast compilation.
dnautics 1 days ago [-]
yeah but you dont have to proof check every cycle, anyways rust safety is not the slow step
Garlef 1 days ago [-]
> what language would be best for our AIs to be programming in
I think "batteries included" is not a good thing to have in the future.
We'll want to be very explicit about what AI generated code can and can not do.
And so some form of effects based scripting language seems like a plausible choice: A language where by default "all batteries are removed".
drob518 6 hours ago [-]
Good point. I think you’re right. We need more rigor for the AI, which would actually help code generation, I suspect. Included batteries are for humans and AIs don’t need convenience.
dnautics 1 days ago [-]
Definitely not python. at least in the immediate future, context is the limiting factor, and not knowing if a function call might mutate your object is not good for context (the llm must either dangerously assume or look it up, both of which are context-expensive)
satvikpendem 1 days ago [-]
OCaml, its compiler is very fast, and it has a stronger type system than Rust in some areas.
noon-raccoon 1 days ago [-]
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.
crazylogger 1 days ago [-]
> 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.
faitswulff 1 days ago [-]
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.
RationPhantoms 1 days ago [-]
I think computer/smartphone usage has been changing that latent space for quite some time. People have been talking about "character amnesia" since 2010.
faitswulff 21 hours ago [-]
Sort of, but the amnesia typically applies to writing characters, rather than reading them.
nneonneo 1 days ago [-]
Pinyin is also the main way people input Chinese into computers, so it's rather important in that regard.
reuven 1 days ago [-]
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.
harimau777 1 days ago [-]
Something to keep in mind is that teaching Pinyin in schools is at least partially an attempt by the Chinese government to drive non-Mandarin dialects of Chinese extinct.
That's because Chinese characters are sred by all of the dialects of Chinese while Pinyin is based on the Mandarin pronunciation.
noon-raccoon 2 days ago [-]
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).
wongarsu 1 days ago [-]
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
PxldLtd 1 days ago [-]
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.
reuven 1 days ago [-]
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.
usernametaken29 1 days ago [-]
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
jorvi 1 days ago [-]
> 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.
noon-raccoon 1 days ago [-]
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.
fpauser 1 days ago [-]
Not to forget "The Beam" - especially gleam!
dist-epoch 1 days ago [-]
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.
fpauser 1 days ago [-]
Maybe the/a big "selling point" for python is the fact, that many teachers don't know better.
dist-epoch 1 days ago [-]
Does this also apply to the industry professionals who pushed it to number 1/2?
gbuk2013 1 days ago [-]
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.
b40d-48b2-979e 1 days ago [-]
This is a non-sequitur? Python is also not a "standalone language" and requires "some runtime".
gbuk2013 1 days ago [-]
Sure but that runtime is much more general purpose - JS runtimes are focused on network apps. For example you can write an app like Calibre in Python and QT and it is much lighter than writing something with JS and Electron.
Python is easier to interface with C/C++ libs.
jim33442 23 hours ago [-]
Yeah, I've thought about this since I do prefer JS as a language... Always thought the main advantage of Python was interaction with C libs. Which is also why CPython was the only serious option for an interpreter, even though things like PyPy were faster.
b40d-48b2-979e 1 days ago [-]
The async loop does not automatically make it "focused on network apps". Most apps I work with in Python also run on an async runtime.
gbuk2013 1 days ago [-]
It’s not the async loop - it’s interfacing with the system. JS is designed to run in a sandbox and the only way out in say Node.js is to write C++ addons.
For example you don’t get to see TCP headers with Node out of the box and you can’t craft packets, whereas you can in Python.
gorjusborg 1 days ago [-]
> require some runtime to interact with the world
This was why I was excited by Bun until recent events. A typescript runtime with a rich standard library, and fast. It looked like it would be a great sweet spot for many use cases.
JCTheDenthog 1 days ago [-]
.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.
gbuk2013 1 days ago [-]
I am well aware it supports Linux but the vast majority of work still involves being in Windows-only shops which is a circle of hell I am keen to tread only when I absolutely have to. :)
dwroberts 1 days ago [-]
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)
reuven 1 days ago [-]
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.
jhbadger 1 days ago [-]
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.
reuven 1 days ago [-]
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. :-)
TheOtherHobbes 1 days ago [-]
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.
SwiftyBug 1 days ago [-]
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.
kortex 1 days ago [-]
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%.
kccqzy 1 days ago [-]
How are you getting static typing without additional tooling?
SwiftyBug 1 days ago [-]
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.
kccqzy 1 days ago [-]
What tooling are you thinking of that’s part of the language? I don’t think CPython ships with a type checker, does it? People typically use mypy or pyright and neither or these are part of the language.
jim33442 23 hours ago [-]
Both of these started as scripting languages
samat 1 days ago [-]
Nowadays a lot of web servers are written in js, for better or worse
1 days ago [-]
noon-raccoon 1 days ago [-]
Frankly, I prefer Python because I find it more elegant. However, in my industry bubble, I see a clear drift toward TypeScript.
prinny_ 1 days ago [-]
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?
herrkanin 1 days ago [-]
Don't underestimate the significance of code being runnable in a browser environment.
noon-raccoon 1 days ago [-]
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.
jim33442 23 hours ago [-]
These articles keep coming up, and the author never actually tries agentic coding in Rust vs Python. You will probably find that the LLM does better with Python for kinda similar reasons as humans. It's succinct and can be rerun quickly while you iterate. There's also the difference in training data. If/when a human needs to review code or intervene, same applies.
Can't say I've tried Rust, but my AI tooling has always been noticeably worse at doing comparable tasks in C++ instead of Python. Not just toy examples but real systems in prod with testing, maintenance, oncall, feature rollouts, etc.
pornel 23 hours ago [-]
> the author never actually tries agentic coding in Rust vs Python
> Can't say I've tried Rust
...
Well, I've actually tried both. The result is similar to what happens when humans code: for small programs the simplicity and terseness of Python helps, but in large programs that accumulate many more invariants that have to be upheld, strictness of Rust becomes an advantage, because it can catch subtler issues with ownership, lifetimes, thread safety.
Although ownership and lifetimes seem like a Rust-specific chore, they're used in APIs to represent all kinds of temporary and single-use objects, so ownership errors are often symptoms of logic bugs that would exist in C++ and even Python, like an event handler callback assuming the event will fire only once when it can fire n times.
You don't see as much improvement with C++, because C++ requires the programmer to get these things correctly, instead of correcting the programmer.
16 hours ago [-]
dzonga 12 hours ago [-]
> If you’re going to write code with agents, then you have to know how to write code on your own
I still think learning to code, then learning engineering (i.e solving problems using rules of thumb) is crucial before any of agentic coding being sold these days. & lastly having taste - making sure you're not just accepting any library that the llm suggests
sthix 1 days ago [-]
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.
superze 1 days ago [-]
Wat
usernametaken29 1 days ago [-]
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
Hendrikto 1 days ago [-]
> 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.
usernametaken29 1 days ago [-]
Indeed, wrong word
DonsDiscountGas 1 days ago [-]
> 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?
dkdbejwi383 1 days ago [-]
> 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.
jim33442 23 hours ago [-]
I was about to guess that Pinyin was yet another Python package manager, that you have to install with pipx
spjt 1 days ago [-]
Why teach people bad habits starting out? Probably dating myself specifically but I started out with Pascal, and I'm glad I did.
waffletower 6 hours ago [-]
"(O)ther well-known developers are now writing code in languages they don’t know. It’s as striking as a Poet Laureate of the United States writing poetry in a language they don’t speak" This statement ought to be embarrassing to the author, but unfortunately the brazenness of this statement shows how far The Humanities have declined in attention for our culture. Let's try this as taking the poetry approach is probably hopeless -- I have never written any Haskell. I have lived in Japan for 5 1/2 years. I can read and understand Haskell far more than I can Japanese. Programming languages are far far far smaller and less complex than natural languages, and share many characteristics among them, despite their differences.
kleiba2 1 days ago [-]
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?
usernametaken29 1 days ago [-]
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
ftmootnomoat 1 days ago [-]
Code is for human consumption. Believe it or not, some of us like to understand how things work.
JodieBenitez 1 days ago [-]
We still want readable language. We still want code we can check and modify ourselves. For now.
1PlayerOne 1 days ago [-]
Well you can read python, you can't read machine code...
xigoi 1 days ago [-]
“Vibe coders” don’t read the code their LLM produces. That’s the whole point.
kleiba2 1 days ago [-]
Thanks for getting what I meant.
More than one reply to my original comment is along the lines of "but humans cannot read/understand machine code effectively". Perhaps instead of starting my comment with "If we're not writing code by hand anymore anyway", I should have said "writing or reading", but it was implied.
fragmede 1 days ago [-]
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.
JCTheDenthog 1 days ago [-]
Then you could have it output LLVM IR
keybored 1 days ago [-]
> Of course, the topic on everyone’s mind was AI.
Some against their will.
> In a world where all coding is agentic, and where we are asking the agents to produce Rust, we might ask a deep and more disturbing question: Why learn Python at all? What’s the point of learning a programming language that an increasingly small group of people will be writing and using?
All the same structure everywhere.
- Now with the AI
- (Not the future; the present)
- Everything is changing
- But colon points to potential problem:
You’re worried about the future of Python. But not programming?
Be a part of the problem or the solution. But no, the author will say, one can’t stop a tsunami.
> Python has a future. But in a world of agentic coding, it might be increasingly for teaching the basics of software engineering and providing AI with high-quality training data, rather than for direct coding of applications. It’s still worth learning and knowing Python — but it’s also worth doubling down on basic software-engineering principles, which we’ll increasingly be using to instruct and judge AI agents.
Remember to mention AI Era, Agentic Era, or some other statement that is on the one hand completely obvious in the author’s mind but bears repeating like a mantra.
Yeah Python will be used to teach arithmetic before we spend the rest of our lives with a calculator. The conclusion is as banal as all the other fluff thought pieces.
> '''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.”'''
My understanding is that children in China learn many characters before pinyin. Characters are mapped to meanings first, and only later to sounds. Fwiw even in my Chinese-as-a-second-language course we were thrown into Chinese characters from the beginning.
Also, of course, Chinese characters have been around for thousands of years and sound-based writing for Chinese is very new. The techniques to get leverage and build up understanding of characters gradually are incredibly varied. Just as the ways we relate to code in the future are unlikely to be familiar or easy to predict.
I'm OK with Lisp output, but maybe that just shows how old I am. :-)
I wonder if it's possible (or wise) to have two different compilers for a language -- one that's optimized for such tight loops, and another that does thorough checking, etc. You know, kind of like -O, but at a much deeper level.
The compiler is indeed not particularly speedy, but the reason you were given is not entirely accurate. As measured in this blog post [0] different parts of the compilation pipeline will take different amounts of time depending on what you're doing (cargo check vs. incremental build vs. full build, building a library vs. binary, etc.), but generally speaking type/borrow checking take up relatively small portions of compilation time (~15% or less, based on eyeballing the charts [1, 2]) compared to everything else.
> one that's optimized for such tight loops, and another that does thorough checking
I think that would risk producing diverging language subsets, especially if the checks are essential for language semantics. For example, what exactly does it mean if a program passes the "relaxed" compiler but fails the "thorough" one? How close does that actually get you to a "real" working program?
[0]: https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-ta...
[1]: https://kobzol.github.io/assets/posts/compile-sections/binar...
[2]: https://kobzol.github.io/assets/posts/compile-sections/libra...
Anyway, I've played around with the idea a bit so far, and it seems that current agents/harnesses use way more tokens with that architecture.
See Workato, Bomi, LangFlow,...
I think "batteries included" is not a good thing to have in the future.
We'll want to be very explicit about what AI generated code can and can not do.
And so some form of effects based scripting language seems like a plausible choice: A language where by default "all batteries are removed".
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.
The article did explain, albeit near the end.
That's because Chinese characters are sred by all of the dialects of Chinese while Pinyin is based on the Mandarin pronunciation.
Go might have the advantage because it's easier to read outside the IDE
But then you have the major downside of 'writing' poor code.
Rust has a huge advantage here, in fact many popular Python libraries use Rust underneath.
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.
Python is easier to interface with C/C++ libs.
For example you don’t get to see TCP headers with Node out of the box and you can’t craft packets, whereas you can in Python.
This was why I was excited by Bun until recent events. A typescript runtime with a rich standard library, and fast. It looked like it would be a great sweet spot for many use cases.
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.
* 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.
Can't say I've tried Rust, but my AI tooling has always been noticeably worse at doing comparable tasks in C++ instead of Python. Not just toy examples but real systems in prod with testing, maintenance, oncall, feature rollouts, etc.
> Can't say I've tried Rust
...
Well, I've actually tried both. The result is similar to what happens when humans code: for small programs the simplicity and terseness of Python helps, but in large programs that accumulate many more invariants that have to be upheld, strictness of Rust becomes an advantage, because it can catch subtler issues with ownership, lifetimes, thread safety.
Although ownership and lifetimes seem like a Rust-specific chore, they're used in APIs to represent all kinds of temporary and single-use objects, so ownership errors are often symptoms of logic bugs that would exist in C++ and even Python, like an event handler callback assuming the event will fire only once when it can fire n times.
You don't see as much improvement with C++, because C++ requires the programmer to get these things correctly, instead of correcting the programmer.
I still think learning to code, then learning engineering (i.e solving problems using rules of thumb) is crucial before any of agentic coding being sold these days. & lastly having taste - making sure you're not just accepting any library that the llm suggests
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.
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?
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.
More than one reply to my original comment is along the lines of "but humans cannot read/understand machine code effectively". Perhaps instead of starting my comment with "If we're not writing code by hand anymore anyway", I should have said "writing or reading", but it was implied.
Some against their will.
> In a world where all coding is agentic, and where we are asking the agents to produce Rust, we might ask a deep and more disturbing question: Why learn Python at all? What’s the point of learning a programming language that an increasingly small group of people will be writing and using?
All the same structure everywhere.
- Now with the AI
- (Not the future; the present)
- Everything is changing
- But colon points to potential problem:
You’re worried about the future of Python. But not programming?
Be a part of the problem or the solution. But no, the author will say, one can’t stop a tsunami.
> Python has a future. But in a world of agentic coding, it might be increasingly for teaching the basics of software engineering and providing AI with high-quality training data, rather than for direct coding of applications. It’s still worth learning and knowing Python — but it’s also worth doubling down on basic software-engineering principles, which we’ll increasingly be using to instruct and judge AI agents.
Remember to mention AI Era, Agentic Era, or some other statement that is on the one hand completely obvious in the author’s mind but bears repeating like a mantra.
Yeah Python will be used to teach arithmetic before we spend the rest of our lives with a calculator. The conclusion is as banal as all the other fluff thought pieces.