My gut feeling is, this post is 180° wrong. LLMs are the exact opposite of "elite coders", they're perfect StackOverflow users:
* they memorize adapt and write back small-scale patterns very efficiently;
* they know widespread libraries inside out, and can learn others in minutes, even if their doc sucks;
* they often produce good results, because most of the time we write unoriginal code, which paraphrases something it already has dozens of versions of in their training corpus;
* but they're bad at seeing meaningful, non-obvious, simplifying abstractions, we really have to spoon-feed those to them;
* they _love_ verbosity, that's literally how they "think";
* they also love repetition: the other term for "repetition" is "patterns", and they're basically excellent pattern matchers.
So, Lisp is enjoyable for your typical LLM-complementary hacker, but not for LLMs. LLMs typically replace the kind of "non-elite" developers who hated Lisp, for remarkably similar reasons.
What I'd love would be an LLM trained to faithfully rephrase a "normal" program into Lisp-ish pseudo-code, that would make reviews faster, more reliable, more enjoyable. But hand-written code is going the way of hand-written machine code; let LLMs have what suits them best, and higher level tools for the more abstract jobs where we're still relevant, and that would be various forms of code reviews.
As for calling "elite" the kind of developer won't understand that development is a team sports, and that the proper tool is the one that fits the team, not their own peculiar quirks, I'm not going to address that, it isn't the keystone of his argument; but a lot could and should be said about that too.
Being the maintainer of such a big open-source application as Chrome used to grant dictatorial power: maintaining a fork represented too much work. It only happened in the most awful situations, such as Oracle acquiring OpenOffice.
But that was before LLM-driven development, I think that now the game has changed, and maybe Google hasn't got the leverage it thinks it has.
Smart move: now that they're an established player, and that they have a few billions of investors' money to spend, they comfort a jurisprudence that stealing IP to train your models is a billion dollar offense.
What a formidable moat against newcomers, definitely worth the price!
> it's questionable whether this is a net benefit for Romania as a whole.
it depends what's most beneficial: having a few percents of very mathematically experts people in maths-heavy professions? Or having everyone somewhat decent at maths, even when it doesn't affect their productivity in their jobs?
I don't have any hard data about this, but instinctively I'd bet on the former: I'd rather have a few hundreds more Sutskevers, than most of the country's bakers know their way around PDE.
Yet Ilya Sutskever was not an Olympiad participant.
Heck, he attended a correspondence college for 2 years (Open University of Israel) before his family immigrated to Canada and then attended UToronto (an amazing university, but not significantly selective by any means).
Ilya is by definition an example of why heavily stratified systems are subpar for human capital development - they remove the opportunity to identify talent from a broad pool, because humans can change.
And as I pointed out from personal experience, the difference in outcomes between IMO and non-IMO participants when I studied CS at HYS was nonexistent - we all did equally well professionally as well as academically. The difference was we all had the ability to study and get guidance from the same professors if we so chose.
And alternative explanation is that he's really nothing special. There are literally dozens of people like him in my social circle. Heck, my very spouse has a more impressive school record. The difference could be connections. He lucked out with his circle and a field of study.
Absolutely! And that's my point! Broading access to education is a net benefit to society, because fortune prepares an able mind.
> The difference could be connections
In Ilya's case, not really. He was an immigrant twice (first USSR to Israel, then Israel to Canada), and wouldn't have been able to do an MS/PhD at UT without actually being capable - it's not difficult to enter UToronto, but it's difficult to leave with a CS bachelors degree.
I've always felt a broad access system like the Warren-era UCs along with LBJ's "Great Deal" is of better benefit for a country than investing in building isolated ivory towers for education, because we have the ability to better ourselves, and that door should always remain open.
* be completely autonomous from day 1, and progressively increase the number of situations you can drive through;
* or drive through every legal situation from day 1, and increase the % of them handled autonomously.
I believe the 2nd approach, Tesla's, has one key advantage: it collects data about freak situations much faster and more exhaustively. Given how data has become the key resource in AI, that's probably a very strategic asset they've accumulated here.
Also, Waymo's joker (remote operation by humans when the software bails out) is totally replicable by Tesla robotaxis.
the magic power of spreadsheets is that they encourage improvisation, and it probably applies to that one.
you have only one data structure (the 2D table), data types are super-weak, there are no variable names... all of this guarantee a maintenance nightmare, and rightfully scares developers. But it's also a very low barrier to entry. You've got data, you paste them into the grid, and you start toying with them, before having figured anything about them.
That's an amazing superpower, when targeting non-developers, and that's why Excel is the most used programming language over the world, by far: it's probably got an order of magnitude more users than there are trained developers in the world.
and _that_ is why I'm still very sad that Lotus Improv didn't make it in the marketplace --- gathering all the formulae into one pane was _incredible_ for organization and providing a single top-level view of what a spreadsheet was doing.
I really wish Flexisheet would get to a usable point, or that Quantrix wasn't so expensive.
Remote has been fantastic, to extend our pool of potential customers/employers. Not working in an open space, not being disturbed by pointless red-tapers and middle managers is a productivity boost. Not losing time and energy in commutes as well.
I can see one serious drawback with pure remote: it's a cumbersome way to mentor junior developpers. In big companies which maintain a balance of junior/senior staff, and try to make the former grow, it's a legitimate issue. In start-ups, which expect you to hit the ground running, and don't have an army of managers to keep busy, remote should be the norm.
That's what better IDEs did to Java codebases indeed: they made layered boilerplates and leaky abstractions somewhat navigable, therefore generations of careless contractors have been able to ship ever nastier messes.
* they memorize adapt and write back small-scale patterns very efficiently; * they know widespread libraries inside out, and can learn others in minutes, even if their doc sucks; * they often produce good results, because most of the time we write unoriginal code, which paraphrases something it already has dozens of versions of in their training corpus; * but they're bad at seeing meaningful, non-obvious, simplifying abstractions, we really have to spoon-feed those to them; * they _love_ verbosity, that's literally how they "think"; * they also love repetition: the other term for "repetition" is "patterns", and they're basically excellent pattern matchers.
So, Lisp is enjoyable for your typical LLM-complementary hacker, but not for LLMs. LLMs typically replace the kind of "non-elite" developers who hated Lisp, for remarkably similar reasons.
What I'd love would be an LLM trained to faithfully rephrase a "normal" program into Lisp-ish pseudo-code, that would make reviews faster, more reliable, more enjoyable. But hand-written code is going the way of hand-written machine code; let LLMs have what suits them best, and higher level tools for the more abstract jobs where we're still relevant, and that would be various forms of code reviews.
As for calling "elite" the kind of developer won't understand that development is a team sports, and that the proper tool is the one that fits the team, not their own peculiar quirks, I'm not going to address that, it isn't the keystone of his argument; but a lot could and should be said about that too.