I come to Python around version 1.5, painfully tired by debugging CGI scripts, created by wannabe perl-golfers. Unfortunately, I feel like Python is losing more and more of the zen that once tempted me...
Lazy loading looks like a last nail in the coffin, where my love to Python was buried, although it was a long, tiresome process.
It's now being used by a lot of people because they have to rather than want to so there is a desire to ** it up and reinvent their favorite language by adding all sorts of warts. That's the price of success.
A proper revenge would be to introduce "easy mode" to Rust - where the compiler takes a huge chill pill and you get non-enforced garbage collection. :-)
Zig strives to avoid numerous pitfalls, and I admire that.
Let's take a look at some of them:
1. Project control – if a LARGE company implements thousands of lines created by LLMs day after day – who is ultimately responsible for the project's progress? "You accept hundreds of PRs, so why not this one?"
And one more thing: will you be able to change the code yourself, or will you be forced to use LLMs? What if one of the "AI companies" implements a strict policy preventing "other tools that XXX" from editing the codebase?
2. Ownership. If most of the code was taken by an external company from their LLM, what about ownership of the code? The authors of Zig, the company, the authors of the original code, stolen by LLMs?
3. Liability. In the near future, a court may rule that LLMs are unethical and should not recombine code without the owners' prior consent. Who is responsible for damages and for removing the "stolen" code? The owners of Zig, the company that creates pull requests, or the authors of LLM programs?
4a. Vision. Creating and maintaining a large code base is very difficult – because without a broad perspective, vision, and the ability to predict and shape the future – code can devolve into an ugly mess of ad hoc fixes. We see this repeatedly when developers conclude, "This is unsustainable; the current code base prevents us from implementing the correct way to do things."
LLM programs cannot meet these requirements.
4b. There's another aspect – programming languages particularly suffer from a lack of vision or discipline. There are many factors that must be planned with appropriate capacity, vision, and rigor: the language itself should be modeled in a way that doesn't prevent correct implementation of behaviors. The standard library must be fast, concise, and stable. The compiler itself must be able to create code quickly and repeatably.
Users hate changes in a language – so if a language changes frequently, it is met with harsh criticism. Users hate incompatibility. Users hate technical debt and forced compatibility. Yes, there are conflicting requirements. The author of Zig understood this perfectly, having already gone through it himself (see, for example, "I/O Redesign").
This balance, in all aspects, is the pillar of human creativity.
To be honest, I'm not a huge fan of Zig because I dislike the tight syntax: too many periods and curly braces, which is why I prefer Odin. But I have a lot of affection and respect for Zig and its authors.
So - in that way - LLM will be Your mentor, it will shape Your way of thinking according to algorithms and datasets stuffed into by corporate creators.
Do You really want it?
There is also a second face of that: people are lazy. They wouldn't develop their own skills but rather they would off-load tasks to LLM-s, so their communicative abilities will be fade away.
> LLM will be Your mentor, it will shape Your way of thinking according to algorithms and datasets stuffed into by corporate creators.
How is this mutually exclusive with teaching better than most humans? Part of these "corporate" datasets include deep knowledge of the world's best literature and philosophy, for instance. Why can't it be both?
> Do You really want it?
If I'm in a hurry, don't know where to start, or don't have money for someone to teach me—sure.
> There is also a second face of that: people are lazy. They wouldn't develop their own skills but rather they would off-load tasks to LLM-s, so their communicative abilities will be fade away.
This is a recapitulation of the Luddite argument during the Industrial Revolution. And it's valid, but it has consequences for all technological change, not just this one. There was a world before Google, the Web, the Internet, personal computing, and computers. The same argument applies across the board, and the pre-AI / post-AI cutoff looks arbitrary.
Ah, so now we get to the "ed tech" question. What is teaching? Is there a human element to it, and if so, what is it? Or is it something completely inhuman? Or do we need to clarify what meaning of "teaching" we're talking about before we have a discussion?
Looks like a LLM hallucination - there is no thing like "RHEL 14.3", although referenced kernel signature (6.12.0-124.45.1.el10_1) contains reference to real RHEL release, i.e. 10.1.
I prefer ~/bin/ for my scripts, links to specific commands, etc.
~/.local/bin is tedious to write, when I want to see directory content and - most important - I treat whole ~/.local/ as managed automatically by other services and volatile.
"And it's just plain better at writing code than 60% of my graduating class was back in the day".
Only because it has access to vast amount of sample code to draw a re-combine parts. Did You ever considered emerging technologies, like new languages or frameworks that may be a much better suited for You area but they are new, thus there is no codebase for LLM to draw from?
I'm starting to think about a risk of technological stagnation in many areas.
> Did You ever considered emerging technologies, like new languages or frameworks that may be a much better suited for You area but they are new, thus there is no codebase for LLM to draw from?
Try it. The pattern matching these things do is unlike anything seen before.
I'm writing a compiler for a language I designed, and LLMs have no trouble writing examples and tests. This is a language with syntax and semantics that does not exist in any training set because I made it up. And here it is, a machine is reading and writing code in this language with little difficulty.
Caveat emptor: it is far from perfect. But so are humans, which is where the training set originated.
> I'm starting to think about a risk of technological stagnation in many areas.
That just does not follow for me. We're in an era where advancements in technology continues to be roughly quadratic [1]. The implication you're giving is that the advancements are a step function that will soon (or has already) hit its final step.
This suggests that you are unfamiliar or unappreciative of how anything progresses, in any domain. Creativity is a function of taking what existed before and making it your own. "Standing on the shoulders of giants", "pulling oneself up by the bootstraps", and all that. None of that is changing just because some parts of it can now be automated.
Stagnation is the very last thing I would bet on. In part because it means a "full reset" and loss of everything, like most apocalyptic story lines. And in part because I choose to remain cautiously optimistic.
First, we've fallen into a nomenclature trap, as so-called "AI" has nothing to do with "intelligence." Even its creators admit this, hence the name "AGI," since the appropriate acronym has already been used.
But, when we use "AI" acronym, our brains still recognize "intelligence" attribute and tend to perceive LLMs as more powerful than they actually are.
Current models are like trained parrots that can draw colored blocks and insert them into the appropriate slots. Sure, much faster and with incomparably more data. But they're still parrots.
This story and the discussions remind me of reports and articles about the first computers. People were so impressed by the speed of their mathematical calculations that they called them "electronic brains" and considered, even feared, "robot intelligence."
Now we're so impressed by the speed of pattern matching that we called them "artificial intelligence," and we're back to where we are.
As side note. Maybe someone knows, why rust devs chose an already used name for language changes proposal? "RFC" was already taken and well-established and I simply refuse to accept that someone wasn't aware about Request For Comments - and if it was true and clash was created deliberately, then it was rude and arrogant.
Every, ...king time, when I read something like "RFC 2789 introduced a sparse HTTP protocol." my brain suffers from a short-circuit. BTW: RFC 2789 is a "Mail Monitoring MIB".
But they were in different domains. Here, we have a strong clash because Rust is positioning itself as secure system and internet language and computer and internet standard are already defined by RFC-s. So, it may be not uncommon, when someone would tell about Rust mechanisms, defined by particular RFC in context of handling particular protocol, defined by... well... RFC too. But not by rust-one.
Not so smart, when we realize, that one of aspects of secure and reliable system is elimination of ambiguities.
A note from someone who specializes in long-term system maintenance:
There is also one, very important aspect, that is - (un)suprisingly - rarely mentioned in comments: a lack of dependence between sloppy work and personal comfort of particular person, responsible for problematic changes.
What I mean? A badly installed or configured system would be a problem in next three, maybe five years: to time of major OS upgrade, HW replacement or refresh, framework deprecation and so, and so... In current, corporate culture, there is almost impossible to being bite by own laziness - almost no one is working in particular company or for particular project so long. Especially, when installation is conducted by external party in model "grab the money and run!"
So, very basic motivation for good work, that comes from awareness, that today technological debt would lead to personal, painful experience in future, doesn't exists at all in modern, corporate environment. The things are even worse - there are multiple relations about negative career consequences resulting from concern for the quality of work: "because we want that product fast a we don't like troublemakers and defensive thinkers".
Nowadays NetBSD offers something similar to "context depended filesystem", i.e. a special form of symbolic links that can points to different locations, according to wide range set of attributes: from domainname via machine_arch to gid.
Lazy loading looks like a last nail in the coffin, where my love to Python was buried, although it was a long, tiresome process.
reply