[throw0101d]

> What software developers actually do is closer to the role of an architect in construction or a design engineer in manufacturing. They design new blueprints for the compilers to churn out. Like any design job, this needs some actual taste and insight into the particular circumstances. That has always been the difficult part of commercial software production and LLMs generally don't help with that.

As Bryan Cantrill commented (quoting Jeff Bonwick, co-creator of ZFS): code is both information about the machine and the machine:

* https://www.youtube.com/watch?v=vHPa5-BWd4w&t=4m37s

Whereas an architect creates blueprints which is information, that gets constructed into a building/physical object, and a design engineer also creates documents that are information that get turned into machine(s), when a developer writes code they are generating information that acts like a machine.

Software has a duality of being both.

How does one code and not create a machine? Produce a general architecture in UML?

[WJW]

I think what Cantrill is getting at here is that a running program necessarily consists of both code and hardware. If the software is missing, the hardware will be idling. If the hardware is not present, then the software will be just bytes on a storage device. It's only the combination of hardware and software that makes a working system.

What software developers produce is not a machine by itself. It's at most a blueprint for a machine that can be actualized by combining it with specific hardware. But this is getting a bit too philosophical and off track: LLMs can help produce source code for a specific program faster, but they are not very good at determining whether a specific program should be built at all.

[throw0101d]

> I think what Cantrill is getting at here is that a running program necessarily consists of both code and hardware.

"The thing that is remarkable about it is that it has this property of being information—that we made it up—but it is also machine, and it has these engineered properties. And this is where software is unlikely anything we have ever done, and we're still grappling on that that means. What does it mean to have information that functions as machine? It's got this duality: you can see it as both."

It's not about software and hardware needing each other, but rather about the strange 'nature' of software.

He has made the point before:

> We suffer -- tremendously -- from a bias from traditional engineering that writing code is like digging a ditch: that it is a mundane activity best left to day labor -- and certainly beneath the Gentleman Engineer. This belief is profoundly wrong because software is not like a dam or a superhighway or a power plant: in software, the blueprints _are_ the thing; the abstraction _is_ the machine.

* https://bcantrill.dtrace.org/2007/07/28/on-the-beauty-in-bea...

(Perhaps @bcantrill will notice this and comment.)

> If the hardware is not present, then the software will be just bytes on a storage device.

And what do you mean by "hardware" and what is meant by 'running software'? If you see a bunch of C or Python or assembly code, and you read through it, is it 'running' in your brain? Do you need 'real' CPUs or can you run software on stuff that is not made of silicon but the carbon between your ears?

[bcantrill]

Yes, the point I was making (and as you point out, have been making for the last quarter century) is that we err when not making this realization -- and indeed, I think the linked piece is exactly backwards because it doesn't understand this. That is, the piece views a world of LLM-authored/-assisted software as "industrialized" when I view it as the opposite of this: because software costs nothing to replicate (because the blueprints are the machine!), pre-LLM ("handcrafted") software is already tautologically industrialized. Lowering the barrier to entry of software with LLMs serves to allow for more bespoke software -- and it is, if anything, a kind of machine-assisted de-industrialization of software.

[throw0101d]

> Lowering the barrier to entry of software with LLMs serves to allow for more bespoke software -- and it is, if anything, a kind of machine-assisted de-industrialization of software.

Instead of people downloading / purchasing the same bits for a particular piece of software which is cookie cutter like a two-piece from Men's Suite Warehouse, we can ask LLM for custom bit of code: everyone getting a garment from Savile Row.