181–190 of 201 posts
One thing that has become clearer to me over the years is that reasoning by analogy (like this article does) sounds a lot smarter than it is. If you look from first principles, it's clear that physical goods and software don't share the same properties and thus the analogy falls apart. Physical goods like clothes or cars have variable costs . The marginal unit always costs > 0, and thus the price to the consumer is a…
I've been thinking about this for a while, and largely agree that industralization of software development is what we are seeing. But the emphasis on low quality is misplaced. Take this for example: ``` Industrial systems reliably create economic pressure toward excess, low quality goods. ``` Industrial systems allow for low quality goods, but also they deliver quality way beyond what can be achieved in artisanal pro…
I share the vision of the author. People use software for specific features, but most software have lots of features people never use or need. A lot of modern software is designed to handle lots of users, so they need to be scalable, deployable, etc. I don't need any of that. I just need the tool to do the thing I want it to do. I'm not thinking about end users, I just need to solve my specific problem. Sure there mi…
Most commercial software is nowadays integrated into the real world in ways that can't be replicated by code alone, software which isn't like this can be easily replaced yes, but that kind of software already had free alternatives.
A question that was not addressed in the article and contrasts software with industrialized products from the past is - who are the consumers of the software produced at industrial scale? Stitching of clothes by machines accelerated garment product only because there was demand and consumption tied to population. But software is not tied to population similar to food and clothes. It doesn't deprecate, it is not exclu…
> who are the consumers of the software produced at industrial scale? Basically every company that does anything non-trivial could benefit from tailor-made software that supports their specific workflow. Many small companies don't have that, either they cannot afford their own development team, or they don't know that/how software could improve their workflow, or they are too risk-averse. Heck, even my small family o…
I wonder if this will lead to more "forks for one person" where you know of open source software that's close to what you want, except for one thing, so you point a coding agent at it.
We are seeing a lot of vibe-coded software primarily for one person. (See all the side projects Simon Willison does.) I wonder if this will lead to more "forks for one person" where you know of open source software that's close to what you want, except for one thing, so you point a coding agent at it.
I've recently started to contribute to open source, mostly just to add some tiny feature or such
I did not realise before this that getting your changes upstreamed can take a long time. Now I have even more respect for the likes of Asahi Linux. The code reviews usually improve the change a lot but it's not like coding at a company where best case you are able to get multiple changes deployed a day on repos your team does not even own.
But I feel it's worth the effort. For as long as my changes are not upstreamed I can keep using the forked version or just tolerate not being able to do something.
But the major issue I keep running into is how the build setup is painful. This is where Nix really comes to the rescue though. I can import the nixpkgs setup for the given project, point it to my forl/branch, and rebuild the software into my cachix for use in dev shells and containers.
I wish more people used nix. I would love to see it getting adopted as a backend for other package managers. Just maintaing a binary cache for your distro and it would be more or less the same.
But I suppose there are arguments against a monoculture as well.
This essay, like so many others, mistakes the task of "building" software with the task of "writing" software. Anyone in the world can already get cheap, mass-produced software to do almost anything they want their computer to do. Compilers spit out new build of any program on demand within seconds, and you can usually get both source code and pre-compiled copies over the internet. The "industrial process" (as TFA pu…
Design engineers can leave little details out and let contractors figure out the details. Software has no such luxury.
Software has design, edge case finding, and actually constructing the process.
Design is only 1/3 of the process in construction.
One thing that has become clearer to me over the years is that reasoning by analogy (like this article does) sounds a lot smarter than it is. If you look from first principles, it's clear that physical goods and software don't share the same properties and thus the analogy falls apart. Physical goods like clothes or cars have variable costs . The marginal unit always costs > 0, and thus the price to the consumer is a…
I use pointy-clicky software for visualizing relationships and correlations. I use draggy droppy software for building complex data workflows (including ML elements). I use desktop publishing software rather than LaTEX. I suffer industrial interfaces for (most of) my own software (where I am the chief customer) because it's easy for me to sling simple server-side UIs, but there are standalone servers out there which make creating apps (with RFID, QR, accellerometer support) just like, yes JUST like, desktop publishing (especially as you get closer to industrial control applications); one of my faves has a widget which is a "choose your own adventure" dashboard widget so that the users can create a dashboard customized just for them, yes, Inception (granted, that widget does need some configuration which requires a keyboard).
Granted, behind every one of those slick interfaces is a drippy gob of data. I have to create a CSV in the correct format for the visualizer, or surrender to their integrated "partner solutions"; or for a different visualizer I have to create some network services which it consumes for "enrichment". My data workflow tool has generic python "actions" so you can create custom tasks (it presents the data to your scripts using pandas). On very rare occasions I have a need to hack on DTP docs to format obscene amounts of repetitive data; but a lot of the time it's back to making a CSV and putting that in a spreadsheet / database which the software can then utilize for quaintly-named "mail merge". The UI software which I refer to integrates with SQL databases and authorization / access management engines, somebody still needs to set those up; and I stumbled across it in the first place because somebody needed a little (surprisingly little) help connecting to an obscure HTTP resource.
To short circuit a bunch of off track commentary: LLMs are not speaking english to other LLMs to design new LLMs AFAIK. I have never seen a debate or article about whether it is better for LLMs to utilize english or russian for this task. I just don't like the menu that is offered on this ship Titanic, and I'm uncomfortable with the majority of the passengers being incarcerated belowdecks; I'll book different passage, thanks.
Earlier quoted context omitted.
> 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…
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 bl…
"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?