fidzu : belgium

Programming language generations

When I was young, I learned about a model of classifying programming language: the system of programming language generations.

In this model, first generation programming languages are, basically, where you program the computer in the language that is defined by its architecture. On a Von Neumann machine, with its load-and-store architecture, you do that by inputting a string of numbers. The first programmer in human history -- her name was Ada Lovelace -- wrote in a first-generation language. 1GLs aren't so much invented as they are a byproduct of the computers for which they're created.

Second-generation languages are the assembler languages. Because humans are not computers, and because decoding long lines of numbers to understand what the computer is doing, when programming became a full-time job, the programmers that did it decided that doing all this assembling manually is too complicated, so they quickly wrote assemblers to automate the process for them. They still could understand the 1GL output of the 2GL assembler, but most of them quickly forgot how to write software in a first-generation language. Not that anyone cared, as the translation from a 2GL to a 1GL is lossless and you can just revert it.

Third-generation languages are higher-level languages. When the first 3GLs were invented (such as COBOL and, more famously, FORTRAN) in the late 1950s and early 1960s, it was believed by some that the work of programming a computer so accessible to non-programmers that the job of programmer would eventually cease to exist, and people would just ask the computer what they needed by entering COBOL instructions. This of course was ridiculous and incorrect, because converting algorithms to computer instructions, whether at the 2GL or 3GL level, is a specialized skill that some automation can perhaps make simpler but never completely take away the need for. At the time, some people also felt to some extent that using 3GL wasn't the same thing as actually programming 3GLs, but eventually the world moved on and embraced things. The invention of 3GL environments reduced, but did not completely take away, the need for people to understand 2GLs, as compiler and operating system authors still need to understand them, and some highly optimized code still continues to be written in 2GLs to this day.

Fourth-generation languages abstract away some or all of the process of programming. For instance, a database-related 4GL will hide away the complexities of storing data in particular locations, how to fetch that data, how to index it such that you can fetch it efficiently, how to loop over the data to get you a summary of that data, and instead allows you to express the required information in an abstract way, expecing the computer to fill in the blanks. When SQL, an early 4GL, was invented, some people believed that the language made accessing databases so simple that the requirement to implement database applications would eventually cease to exist and we would just hand SQL prompts to users who need to access data. This of course was ridiculous and incorrect, because understanding data schemas and using that understanding to query data from a database is a specialized skill that perhaps a higher abstraction can help you make simpler, but that in the longer run it can never completely take away the need for. The invention of 4GLs also reduced, but did not completely take away, the need for people to understand how to do the things that the 4GLs automate for you manually, as the people who do write those things still need to understand them, and there are also environments where these particular 4GLs are rather not appropriate or just very slow.

The first definition of programming language generations that I read about in the 1980s simply stated that fifth-generation languages did not yet exist, but that they would in the future, and that in those, you would "tell the computer what to do, and it would then do that". Now that we have a way of doing so, it could be said that by some definition, we now actually do have a number of 5GLs. The existence of these LLM systems has caused some, especially the people who build and exploit these systems, to exclaim that programming as we know it today is going to cease to exist, and everyone will just ask an LLM to generate a program, which will then do so. That is of course ridiculous and incorrect, as no automaton can generate software from nothing; input is still required for the model to be able to produce something that approaches usability, and being able to word that input in a correct and productive fashion will be a skill that future programmers can benefit from. I ran some experiments a while back, and from that concluded that, if we look only at the technical side, LLM use can, in some niches, increase productivity for a programmer. There are certainly things that you shouldn't use an LLM for, but equally there can be cases where use of an LLM to perform some task that traditionally would have been done by a programmer would be a net positive.

But LLMs, as they exist today, are highly problematic.

They require vast amounts of data to build the model. The companies that build these models are disrespectful of people who run web services, and as a result, everyone now has to implement various types of application firewalls just to not make systems fall over from the overwhelming requests for data. They are also disregarding the licenses that are attached to these vast amounts of data, which makes me, as a person who believes in the tenets of free software, sad.

They require vast amounts of energy, causing an already-critical global warming crisis to, well, not improve.

They require vast amounts of coolant to dissipate the energy concentrated in their data centers, causing further environmental effects.

In this, they are problematic and to be avoided. But these are side states of the current state of affairs; I do not believe that they are inherently implied to be able to build and operate an LLM -- any LLM.

I guess it's fair to say that my feelings towards LLM usage are complex and many-faceted. I haven't been involved in many debates about the subject, debates that to me seem to be mostly focused on "LLM good" vs "LLM bad" arguments that aren't as nuanced as the position that I would believe is more accurate. This is not because I don't care, but partially because I've been busy in my personal life recently and partially because the whole thing seems somewhat disheartening.

But then Debian popped up GR 2026-002, meaning, I now have to come up with an opinion about various candidate statements in the context of the above, which is... not easy. But I did it anyway.

There are 8 choices on the ballot, and they all have some truth and some falsehood to them. My position about LLMs can be summarized as:

• The current state of affairs wrt LLMs is disastrous and we should not encourage them
• However, there's no technical reason why this must remain true for all time
• And so any statement should keep in mind what might happen in the future and that the current disastrousness of the whole thing isn't guaranteed to continue to exist for all eternity.

With that, let's go over them.

GR vote options

Proposal A

Its summary, from the GR text:

This proposal aims to expressly forbid any contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools.

This falls squarely in the "LLM bad" camp, outlawing all generative-AI contributions, disregarding potential future ones where the problematic situations that exist today are not present.

It makes a change to the social contract, which is especially difficult to reverse (on purpose), and which therefore also will require a 3:1 supermajority, but if we want to ban LLM-assisted contributions, this is probably the best way to do it.

Proposal B

This one tries to allow AI-assisted contributions under certain conditions. It's mostly an "LLM good" proposal, with some caveats that can be discribed as "make sure you know what you're doing".

Proposal C

This proposal is both a weaker (in some places) and stronger (in other places) version of Proposal A. It makes changes to the code of conduct instead of to the social contract, and it also wants to, at least, suggest policy to parties beyond the Debian project. By not changing the social contract, however, it is more likely to reach its simple majority requirement than proposal A.

I don't think the language that it wants to add to the code of conduct is particularly well phrased, however.

Proposal D

This is a weaker form of proposal B. The language is more compact and there are a few requirements that are spelled out in proposal B that are not spelled out in proposal D, but if you read between the lines you'll see that the requirement is still there really and I don't understand why proposals B and D were not merged into one.

Proposal E

This proposal tries to hold a middle ground between "LLM good" and "LLM bad". It appreciates that things are quite muddled at the present time, and that perhaps the situation might might change in the future. It acknowledges that certain questions remain unanswered and that perhaps future considerations might therefore be different. But it essentially refuses to take a stance on whether LLMs should be accepted by the project or not.

Proposal F

Similar to proposal E, this proposal tries to discourage Debian contributors from using LLMs, while still allowing people to use it should they want to, but with some requests and requirements to mark LLM-assisted contributions to account for those people who don't want to interact with LLM-generated software. As such, it is a proposal similar to proposal E that leans closer to the "LLM bad" camp.

Proposal G

This proposal aims to ensure that contributions directly to Debian are created by humans, while at the same time avoiding restrictions on the tools those humans may choose to use when contributing

Another "LLM bad" proposal, it however restricts the "bad" bits to only the direct output of the LLM. If you use an LLM to do something and then clean-room re-implement the same thing yourself, that's apparently fine.

Proposal H

This proposal condemns the use of LLM for its environmental and moral problems, but explicitly not for its technical considerations. I feel that it is closest to my position as explained above.

Voting

Expressing a vote on a ballot so convoluted and complicated like this one takes time. I have to read and understand every ballot option, and formulate an order of them.

And I shouldn't just state which option has my preference; Debian's voting process allows a rich expression of opinion on ballot options.

Anyway, I eventually ended up voting in a way that I think is consistent with my opinion. But it wasn't easy.

23 Aug 2026 10:02pm GMT

I've found my ideal format for shipping apps for personal & family use: PWAs, with an offline-first focus, rendering (mostly) entirely client-side. JavaScript is powerful enough to do pretty much anything these days - especially if you don't have to write the code yourself.

23 Aug 2026 10:02pm GMT

If AI can generate an application from a description, is software still worth anything?

I have lived with a version of that question longer than most.

I released Drupal for free more than twenty-five years ago, and later co-founded Acquia, which has grown into a large enterprise software company built around Drupal.

Granted, Drupal is free in a different way than AI-generated applications are free, but I'm not sure that changes the basic question of how to build a successful business around either one.

Open Source made code abundant by giving people broad rights to use, modify, and redistribute it. AI is lowering the cost of producing code. One lets you copy the software; the other makes it cheaper to recreate software.

Free code changes what customers pay for

Because anyone could use Drupal for free, Acquia could never build a durable business around access to the code. From the start, we had to make money another way.

We built that business around helping enterprises build, run, and manage Drupal applications throughout their lifecycle. That includes hosting, but goes well beyond it: the tools and services needed to develop, deploy, secure, scale, monitor, and improve applications in production.

Proprietary SaaS typically bundles access to the application with the hosting and operations required to run it. With Open Source, organizations can run the software themselves or choose who hosts and operates it.

As AI makes applications cheaper to recreate, the traditional SaaS bundle of software and operations comes under pressure. Customers may become less willing to pay for access to application functionality without becoming any less willing to pay to run and manage applications in production. For Open Source businesses those economics are not new.

Dependability becomes the product

Software can be free, or nearly free, without becoming cheap to depend on. The more people and organizations depend on a system, the more of its value comes from operating it securely, reliably, and at scale.

Once people depend on an application, the cost of its failure has little to do with how much it cost to build. An application that costs $1,000 to build can still cause a $10 million failure.

As AI makes enterprise applications easier to create, adapt, and integrate, they still have to be deployed, secured, scaled, monitored, and run reliably over time. As software cost comes down, dependability becomes a differentiator.

Linux is abundant; dependable cloud infrastructure is a service worth paying for. Drupal is abundant; dependable digital experience infrastructure is a service worth paying for.

Acquia has lived with those economics for nearly 20 years. Drupal made the code abundant, so we built our business around helping organizations build, run, and improve what they created with it. As AI makes code cheaper to generate, that business model may start to look a lot less unusual.

Either way, more software companies will have to answer the same question: if code and capabilities are abundant, what are customers really paying you for?

23 Aug 2026 10:02pm GMT