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.

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.

That's looks like a strong dystopia for me.

~/.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.

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.

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.

Not so smart, when we realize, that one of aspects of secure and reliable system is elimination of ambiguities.

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".

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".

In consequence, one cannot throw a rock without hitting a dozens of such a cases, like that one: https://discourse.ubuntu.com/t/release-26-04-lts-without-the...

For details see https://man.netbsd.org/symlink.7 - section Magic symlinks at very end of manual.

Official version is: "because there is a whole history of correspondence and it is convenient to forward it to new participants".

In reality? It doesn't matter. Almost no-one reads, neither top- or bottom-posted mails. But there is a drawback in top-posting and I mean a "my comments inside original post, in color/bold/with indent/randomly inserted between two phrases". There is no standard of citing in top-posting - thus sometimes original mail gone. Edited, re-edited and commented in various, inconsistent and often unreadable ways.

But, high-level language can offer a very interesting possibilities, even if it was not created for such kind of programming. For example, some time ago I made another attempt to emulate family of 65xxx. Previous versions were written in typical manner, like work of every other programmer on Earth.

A new approach, when a code was written in more regular way (see link below), like mentioned tabular-one, gave me excellent results. I was able to fully understood a program and processor logic and finally I was able to re-create a most magical command for 65xx: SBC/ADC with BCD support in very straightforward and clear way (especially for a cpu-like logic).

For example: https://github.com/aniou/morfeo/blob/a83f548e98bd310995b3c37...

There is one thing that not fits into pure, tabular-like code logic: more complicated conditionals and loops. But maybe, in future...

Of course, it gives "better publicity" for RAID-Z, but it is rather an marketing trick not engineering.

See https://en.wikipedia.org/wiki/Standard_RAID_levels

Creating a tools, that allows us doing a simple, repeatable and - usually - automated tasks, always was an important part of sysadm role. Of course, there were ones that did everything manually and wasn't able to write own code: we called them "operators".

From my point of view: "devop is that hasty one, that doesn't care about long-term support of underlying infrastructure".

I'm always upset when I see a installations that are created with pattern: "we need it to run and we doesn't care where system will be in next two years" (in trashcan, usually - or it will act as a jumphost for another scam/DDoS). And I see such systems everyday. And that dramas, when I ask a simple question like: "how it will be upgraded"? "What is your plan about dealing with manually-installed python modules that overwrites files from system-installed ones when system upgrade will be performed?" and so on, and so on...

Fortunately a separate "devops" team that really cares about infrastructure reliability usually evolves into a normal sysadmins in no-time and their priorities are usually different that rest of "dev-teams".

In case of manually written math equations (or LaTeX-ones) operators are easy distinguishable from arguments. They have a different sizes too.

For example, "result = axe" and "result = a×e" in many cases looks the same and, even in my browser, with font larger, than ones usually used by my colleagues, they are very hard to distinguish. Difference between "result a÷n" and "result a-b" can be spot easier, but it depends on two one-pixel dots.

Ok that was only a mumbling of malcontent - in fact we all know that we all have a sharp, young eyes and we never will be tired or distracted, I'm pretty sure of that. ;)

Re: affordable: I come rather from 8-bit Atari and - in my opinion - it is not a cheap hobby. Modern extensions like Sophia2 or VBXL aren't cheap, memory extensions also require some bucks. Not mention about SD-card interfaces, although they are cheaper. And re-implementations like already assembled EclaireXL or Atari 1088 XEL are even more expensive.

320x240 (double-pixel), 640x480, 800x600 all with 8 bit colors - 2 to 4MB of RAM, SD-card, IDE, FDD, joysticks, DVI for modern monitors - there are even expansion cards (second monitor(!), Ethernet) already available.

Community is - currently - small and it affects the amount of software available, unfortunately - but it is a matter of time, I hope.

There is a wiki [4], but discussions and deep technical details are available mostly on project Discord [5].

1 - https://c256foenix.com/

2 - https://github.com/Trinity-11/FoenixIDE

3 - https://github.com/aniou/go65c816

4 - https://wiki.c256foenix.com/index.php?title=Main_Page

5 - https://discord.gg/wvM2vABR

6 - https://github.com/aniou/of816/tree/C256/platforms/C256

7 - https://github.com/aniou/retro816

See also https://github.com/aniou/cof/wiki/Draft