Aren’t the towers of abstraction an enormous success? When I was learning to program around 1990, people were still writing think pieces about the lack of software reuse. Now that is a solved problem. If anything, people write think pieces about how there’s too much software reuse!
My response to the mountain metaphor is that a rising tide lifts all boats: our situation is more like Hawaii than the Himalayas. True, there’s a risk of drowning in abstraction and sometimes our mountains of software explode spectacularly. But it’s easier to draw something on a <canvas> now than it was to draw in a window 35 years ago. And new mountains with better abstractions are being built: look to CHERI, Rust, io_uring. Maybe Oxide’s approach to firmware will succeed? I’m optimistic.
When users of all kinds complain about the lack of interoperability of software, data silos, and pervasive mono-cultures that we can’t upend by some random individual working in their garage, I don’t think of success.
When the majority of software re-use is now delegated to shipping containerized binaries because we can’t actually build portable, composable software, I don’t think of success.
When I’m subject to the few, if any, outlets of configuration that a piece of software will give me, apart from what the authors allow, I don’t think of success.
When I think that we’re still in the same general spot as we were 35 years ago, just with the ability to move faster due to the demands of capital and product, I don’t think of success.
When the majority of software re-use is now delegated to shipping containerized binaries because we can’t actually build portable, composable software, I don’t think of success.
I feel like … we know how to build good software and good abstractions. We see this happen a lot in open source projects where people have the freedom to do the right thing without pressures from management and executives breathing down their necks. Tremendous successes abound.
But we don’t know how to incentivize producers of commercial software to build quality products. Sometimes it happens by accident.
software should be detached from profit and market economy. There are several fields in which this just works better, like healthcare. Any serious attempt at bringing software under public control, assuming there will ever be enough concentration of political capital to do that before the end of the information age, would be met with incredibly violent resistance by the oligarchs that profit from private software.
If anything, the current trend is going the opposite way: regulations on software are being attacked left and right by the oligarchs and planes started falling.
I think the danger with that approach is that it’s difficult to ensure that the correct software gets created. Markets are a very good way of ensuring that resources get allocated relatively efficiently without needing a central planning system, and without having lots of waste. (Waste in this context is having everyone learn how to write COBOL when app developers are necessary, or vice versa.) Markets have a lot of issues and require a lot of careful regulation and interventions, but they are really good at decentralised decision-making, and we should use them for that purpose.
In fairness, I can understand why people might not associate the current software market with efficiency, but we’re talking about a different kind of efficiency here! The goal of the market is to match people with desires and people who can solve those desires. Right now, few people desire fast, efficient software, as hardware is mostly cheap, so it doesn’t get created as often. It might seem counterintuitive, but this is good: it generally takes longer and more resources to write a shorter, faster, more efficient program (in the vein of “I would have written a shorter letter but I didn’t have the time”), and that time and those resources would be wasted if people didn’t actually need the efficiency.
Where problems arise is where the markets cannot capture some aspect of the “true price” of something. For example, in the discussion on software efficiency, there are environmental issues which don’t get factored into the price of hardware, and there are many groups of people who have needs, but don’t have enough buying power for those needs to be properly met. In these cases, we need regulation to “fix” the markets - pricing in environmental impacts to hardware and running costs, and ensuring minimum standards are met for all software that allow people with various disadvantages to still engage with software. However, just because the markets require adjustment, doesn’t mean that we should throw them away entirely. Software needs to remain attached to profit and markets to ensure that software gets written that actually serves people’s needs.
I realise we’re in danger of getting off-topic here and I don’t want to derail this discussion too much. But I wanted to provide a short leftist defence of markets in software, and point out ways of solving current issues that don’t involve rejecting markets entirely.
The goal of the market is to match people with desires and people who can solve those desires.
The idea that I could spend time working on software that does things that people actually want is why I write free software outside of a market. It appeals to me specifically because the opportunity to do that is so rare in the industry.
In theory, yes, a company that could do this would do well in the market, but in practice any company that achieves this ability briefly ends up self-sabotaging it away in a short time.
Aren’t the towers of abstraction an enormous success? When I was learning to program around 1990, people were still writing think pieces about the lack of software reuse. Now that is a solved problem. If anything, people write think pieces about how there’s too much software reuse!
I think the part that bothers me the most is that a lot of the “modern” abstractions are designed more for plug & play and not for extension. “Frameworks” instead of “libraries”, as I’ve seen the distinction before. If what you’re doing fits well into what the authors were expecting you to do things work really well. And if you try to step anywhere off of that pre-ordained path things start getting really hairy quickly. I wish I could remember what the project was that I was working on a few months ago… it was UI stuff and the framework provided a fabulous set of components, but adding a field validator to a text field involved climbing 3 or 4 layers up the abstraction tower and making your own variant of some superclass and then bringing back a bunch of extra functionality from the subclasses you couldn’t use.
When the majority of software re-use is now delegated to shipping containerized binaries because we can’t actually build portable, composable software, I don’t think of success.
I 100% agree. I mean… thinking about to the late 90s and early 2000s, I do somewhat appreciate that many of those containerized binaries are going to be talking JSON over HTTP and/or Websockets and the languages I use on a regular basis all have really good libraries for those protocols. On the other hand, it’d be really great if a lot of that was a matter of linking a .so and potentially using an FFI binding instead. I’m absolutely exhausted from looking at code that JPEG-encodes an image buffer, takes the JPEG, base64 encodes it, stuffs it in a JSON dict, only to have the whole decoded process reversed on the other side.
I draw a distinction between abstraction and composition, which is also in the article. It’s not a hard distinction, but I’d say:
Composition means putting parts together to form a working system. Does the result work? Is it correct? Is it fast and secure? (Composition does feel more “horizontal”)
Abstraction means hiding details. Abstracting over Windows and Unix is something that I think is often accidental complexity, or at least a big tradeoff. It saves time for the developer, but it can be a loss to the end user. (Abstraction does feel more “vertical” – and fragile when you get too high)
This person, commenting on the same article, pointed out “shallow and composable” as properties of Unix, and I agree:
So I think shell composes, but it’s actually not very abstract. And this is a major reason I’ve been working on https://www.oilshell.org/
IME, shell gets a lot of work done effectively, without much weight, and is adaptable to new requirements. One person can write a shell script to solve a problem – you don’t have to assemble a big team, and justify its existence.
(Of course something that’s challenging is for that shell script to not become a mess over the long term, and I believe we’re doing something about that)
From the article:
Programming models, user interfaces, and foundational hardware can, and must, be shallow and composable. We must, as a profession, give agency to the users of the tools we produce. Relying on towering, monolithic structures sprayed with endless coats of paint cannot last.
This is generally my preference, but I would say “must” is not true … One thing I learned the hard way is that interoperability is basically anti-incentivized.
Long story, but I think the prevelance of YAML in the cloud is a “factoring” problem, but there’s actually a deeper economic issue at play.
That is, the people on one side of the YAML write code and algorithms, and the people on the other “configure” those lego blocks that don’t actually fit together.
YAML arguably abstracts (it hides details behind an interface)
But it doesn’t compose (when you put things together, they don’t have the properties you want) …
abstracting over OS always feels weird to me, when one of the main purposes of an OS is to abstract over hardware
abstracting over hardware makes sense, because we keep getting better at making hardware, we have different tradeoffs, etc.
but with OSs, it mostly seems like a coordination problem. sometimes an intentional one, because the organizations involved were trying to build a moat
The OS already abstracts over hardware, and then we are piling more abstractions on top of OSes.
One that that leak – in terms of performance, security, or just making the application behave poorly
Electron is basically that – it lets you ship faster, but that’s about it
The “tower” or “stack’ is often not a good way of building software.
And the funny thing is that OSes are converging, with Windows gaining a Linux kernel in ~2016 (WSL), and then it also gained a Unix terminal some time later!
I guess to argue the other side, Unix was never good at GUIs … so it’s not like Macs or Unix were superfluous or anything. But it’s just that the most basic layer is still in flux, and it is converging on “Unix”, even in 2016 and 2024 …
(running Docker containers seems to require some sort of Linux x86-64 syscall ABI too)
As a thought experiment, I’d say if we knew how to perfectly abstract, we’d be able to write multi-platform GUIs that work perfectly on all targeted platforms.
But I think anyone who works in that area (I don’t) will tell you that it’s a big compromise. You can write something better if you start OS X only, or Windows only.
I think Flutter is something that abstracts over Android-iPhone, and there are many others.
And of course there were many attempts at Windows / OS X abstraction (QT etc.), but what seems to have happened is that desktop GUIs just got uniformly WORSE since those attempts were made.
Is an Electron app better than a QT app?
Rust is famously “not GUI yet”, and you can argue that if it had some yet-unknown great powers of abstraction, then it would be.
So you could say it’s an unsolved problem to have “zero-cost abstraction” in that respect (!)
(And yes this is a pun – the cost I’m talking about is in the behavior of the app, not the performance)
To summarize, I think there are many things better about where we were 20-30 years ago, but many things are worse. Latency is another one - https://danluu.com/input-lag/
Composing software from parts and maintaining latency is another unsolved problem.
I think a good stress-test of this argument is a field which seems like it’d pay in blood for every abstraction: gamedev. It’s also a field where 1) many projects are made by one person, despite the “proverbial death of the individual developer”, and 2) they work on towers of abstractions “as a tool to avoid hard thoughts.”
And yet these solo devs keep putting out absolute masterpieces: Minecraft, Stardew Valley, Baba is You, Tunic, just to name a few. If anything, the pace has accelerated in recent years, and I regularly play a game and find out later it was made by 1-2 people. So any conjecture that abstractions make it harder for individuals make software should explain why that doesn’t seem true in the field it’d matter most.
Oddly enough, I started my journey in game development! And I agree with you on some points, but not in others.
On the one hand, I am incredibly enthralled that indie developers have platforms to stand on. My argument isn’t “no abstractions”, it’s “careful use of abstractions”. Game development is where performance does matter to an extent, so the environment mirrors early computing where you actually pay the cost of the abstractions you introduce.
On the other, I think that we’re seeing the results of a filter, rather than the actual results. A lot of people burn out in game development, even technical individuals, because they exhaust themselves scaling mountains. Want to ship a game? You’ll realistically be dealing with entire engines and shifting your mental model to work within them, or you’ll be tolerant and technical enough to build your own.
I think it’s a question of tolerance of the norm rather than the norm being sustainable. But, as always, data, data, data.
I think if I’m in a position to advocate for better conditions for individuals, and I’m capable of bringing awareness to that, I should. I really don’t want to abstract these people away if possible.
Is it going to actually make things better, or just change the status quo ?
You said “On the other, I think that we’re seeing the results of a filter, rather than the actual results. A lot of people burn out in game development, even technical individuals, because they exhaust themselves scaling mountains.”
We have infinitely better tools than 30 year ago, yet much more people get burnt out today. Why ? Because the availability of these better tools actually increases competition and thus stress. The better the tools, the higher the mountain gets for everyone as our expectations increase - we always want something that is going to be better than the “average” video game / pizza / movie.
That’s a pretty good point! And I think it’s in line with what I’ve said: the disconnect between release cycles and “time to mastery” grew as time went on, and those curves diverged. If I give you more power over a system, phrased in terms of abstractions, your demands very well might scale with it, leading to the requirement for more power, leading to more abstractions, etc. etc.
It’s partly why I don’t think the solution is purely a technical “throw new languages/software/hardware at it” one, but something that sits firmly between how individuals interact with computers that are embedded in their daily lives and the cumulative technical knowledge we’ve acquired in the past 40+ years.
Minecraft and SdV is not masterpiece because of the engineering. MC will drop to 4 fps if you add 4k textures to it, Starfield on the other hand can provide a smooth 100 fps on the same machine.
SdV is looking like a game from before the millenia. Gaming experience is not always related to the engineering efforts put in those games.
I think a good stress-test of this argument is a field which seems like it’d pay in blood for every abstraction: gamedev.
So, gamedev, as a field has definitely always pushed the bounds of what we know how to do with a machine. But the games you listed aren’t exactly AAA 3D graphics-porn. Not to say the devs aren’t good. You can definitely screw up bad enough to make those games run like trash if you’re incompetent. But you can definitely take on a couple abstractions to make things easier that a Crysis-level game can’t.
I faded out a bit in the middle, but what is the problem exactly? This piece has lots of discussion about the cause of the crisis and very little on what the crisis is about.
I agree that this article could use some clarification. It seems like it’s giving some sort of call to attention or maybe even action, but I don’t know to whom or for what purpose.
To be charitable, and because the article was short, I read it a few times. Here’s what I got out of it at the end:
(begin attempted summary)
The origins of the software crisis
The first bit seems to describe some history relating to the term “software crisis,” but forgive me for not knowing my history well, I don’t actually know what this means. It then discusses how we have failed to address the crisis, although we think we have addressed it because we can hide its crisis-ness through abstraction (of what? I think of software itself?). At this point I’m picking up on the repetition of the word “performance,” and specifically the line
Every roadblock that was hit was met with a hardware upgrade.
makes me think that this crisis is kind of like saying “our computers got faster [= smarter] so we got dumber.” Like how our forefathers knew how to tie 8 million knots and start a fire with their bare hands while we struggle to operate the electric can opener.
OK, cool, so that’s a start to understanding the problem.
The perils of the software crisis
It continues with detailing how as a result of abstraction, things are less hackable now and the individual developer wields less power (because of this? or maybe because of all the competition (corporations?) who can out-muscle them and are committed to preserving the less-control status quo). The end users feel this too, although it’s unclear whether it’s because there are fewer solo developers offering highly-configurable solutions (see above) or if it’s because software not being hackable is part of a larger problem of less configuration for everyone.
The bad actors in the software crisis (us)
The article then circles around to asking “if this sounds so bad, why haven’t people done anything about it?” It answers this by saying “well we all are to blame here [we = software producers, but presumably not the solo developers because they’re a dying breed, so I’m guessing this is like people working for big tech companies], but we kind of have been ignoring our sins of abstraction for external reasons such as: curiosity, passion, peer pressure.” But also it’s explainable because using abstractions has been the path of least resistance for doing software development for some time.
At this point I’m still not entirely sure what an abstraction is but I’m convinced that it is the Devil I need to get out of my house. Or maybe the Devil I need to prevent from getting into my brain when I sneeze. Also, we haven’t been doing a whole lot of preventing the Devil from entering our abode/noses because we [now switching to the readers of Lobsters because they are also largely software producers] are the reason why software has a crisis.
Things can be better
Aha! We return to the damning of Moore’s law. Well I’m acting like this is a triumph but I knew we would return here because I read the piece several times already. To be clear: the problem the author recapitulates is that we are separated so far from our hardware that we continue to “sweep things under the rug” which I presume means like no longer rolling our own graphics drivers or monitoring the heat levels of our CPUs to change major modes (sorry this is going off the rails but I couldn’t resist). And there is another mention of how people “way back when” knew how to Write Code because they had to, otherwise their program would take literally years to run. We [= modern day programmers], on the other hand, are not even bothered by programs taking literal years to run as long as they’re parallel enough that we can just run them on a big enough cluster in a few days.
So we finally move toward the end, which I must warn you is a cliffhanger, but not before a repeated mention that by killing abstraction we also lower the barrier to entry (of software development, presumably). After some mentions of other movements which seek to accomplish similar goals (but not identical ones, presumably), we are told that there is hope and we will hear about it.
(end attempted summary, which at this point is less summary and more annotation)
I think I puzzled out what is bothering me most about the article, which is that while it condemns Big Abstraction, it only does so in the abstract, thereby muddling its point. Lots of pronouns or “thing”s are referred to without it being made clear what they are. I know the author is floating around these comments: I would suggest giving a kind of “motivating example” of this problem (while also convincing the reader it generalizes to other examples/areas). Tell me what is the “that” and who is the “they” in “that’s what they say” (this is a square Far Side reference forced into a round hole, so forgive me if it doesn’t make sense). And additionally, please forgive my snide or snark: I’m in an impish mood.
I also am bothered by the whole “people were smarter when they wrote assembly” line beneath the surface, but I won’t go further into that.
Users don’t adore these things, businesses that pay top dollars trying to reduce time-to-market to the minimum do, it’s not because of “users loving javascript” that NPM is one of the biggest package repositories in existence today; same reason why Java got so big, it caters to businesses not to the software crafters, they don’t give a damn about building better software, let’s just see how far Go went without even supporting generics and basically throwing away innovations in programming language design since the 80s.
Make no mistake, software as it is today caters to the capitalist business model, if you want a technology to succeed better have a good marketing team and good preacher/salesman behind.
Not to keep bashing on Go, but think for a second, if it was not by Google and not having Rob Pike or Ken Thompson behind it, would it have succeeded? The answer is NO, let’s be honest.
Microwave interfaces have whole interface subsystems designed for one poke start, rather than entering specific time and power. Also, again: iPhones, VCRs, Windows 3.1.
Your model is “businesses don’t care about shipping shoddy”.
I suggest that users are fine with that quality, if they don’t have to think - https://en.wikipedia.org/wiki/Don't_Make_Me_Think . That is, lack of needing to attend to details is a significant advantage for many users across many domains, regardless of the underlying whatevers.
I write Rust, use emacs heavily, and spent a decade running Gentoo, so - I’m not that person. But I recognize the popularity and weight behind that world.
“The solution to the software crisis will not be a reversion to more constrained platforms.”
The stereotype of reversion to non-automated, non-abstracted usage of software as a solution is one I really need to argue against. We can build things that users enjoy without having to revert to constrained platforms, while at the same time restricting the amount of abstraction we can apply.
I’m saying that you need to address the well observed preference (revealed preference) for KISS designs, even if they strictly constrain the user - and many users do prefer to be constrained.
I’m not going to say I am one of them. 🙃 Just, most people (devs) I have worked with want the ez button to slap, even though it isn’t optimal in many ways.
For sure! I also want that easy button, just not phrased in terms of existing towers of abstractions. If you consider all current software “prototypical”, in that we’re building scaffolding on top of scaffolding, rather than core building materials, then it’s time for us to step back and see where we can start solidifying things.
That’ll come with the removal of a lot, but like a good diff, judgement shouldn’t fall upon the lines removed, but on the functionality present after the patch. We need to do some compression and consolidation.
There are a couple of references I’d bring to the conversation. I’m going to get details of these recommendations wrong, since they’re larger reads than I have time to check at the moment, but I hope they’re helpful in broad strokes.
First and foremost, Fred Brooks’ No Silver Bullet. One of the things I took away from Brooks’s essay is that resolving some part of the “software crisis” does not actually make engineering easier. Rather, it increases the scope and complexity of the domains to which we apply engineering. Whatever else you’d say, software is extremely more important to functioning society than it was in the ’60s when the Software Crisis was described.
Secondly, and I’m not as confident here, Peter Drucker’s The Effective Executive. I have the idea from Drucker (I believe) that “executives” (the way he used the term) are characterized by those whose decisions (as opposed to more straightforward execution of stereotyped activities) make material difference to the success of an organization. This is, I think, most of us, though not all in the same way. I bring this up because in the software industry, we’re working largely with thought-stuff, rather than physical or chemical processes. When the medium is thought, the bottleneck of forward progress is the speed of thought, and of communication. Being a bottleneck is difficult, and (I seem to recall) Drucker’s book had much to say about managing priorities in such circumstances. When forward progress is (more-or-less) always possible, time spent on business needs to be explicitly balanced with other desires and obligations. Feeling that the set of technical demands on practitioners constitutes a crisis feels (to me) like a failure of prioritization or of realistic planning.
If curious developers can no longer build software without scaling mountains
Is this true? To echo the article “against innovation tokens” plenty of shiny new software exists to reduce the operational complexity of managing the kind of online computer systems that back saas.
This is a great introductory post and I’m looking forward to the follow-ups. Is there an Atom or RSS feed associated with the blog?
Regarding the point in the article, I think abstractions are important because they allow us to ignore things we don’t care about. Without (or with too little) abstraction, you’d just end up with sprawling amounts of low-level code, which is hard to navigate and make sense out of. With too much abstraction, you end up with towering complexity and it will be hard to get down to “what does this code actually do?”.
But abstractions also have other risks, since creators of abstractions often don’t care about things you might personally care about. Oftentimes, that’s performance, but there can be other things as well. Then you end up bypassing the abstraction or hacking around to “reach down” underneath to get to the thing you need to do. That’s when it gets ugly - like trying to type with mittens on, it hampers your ability to express what you want to express.
Aren’t the towers of abstraction an enormous success? When I was learning to program around 1990, people were still writing think pieces about the lack of software reuse. Now that is a solved problem. If anything, people write think pieces about how there’s too much software reuse!
My response to the mountain metaphor is that a rising tide lifts all boats: our situation is more like Hawaii than the Himalayas. True, there’s a risk of drowning in abstraction and sometimes our mountains of software explode spectacularly. But it’s easier to draw something on a <canvas> now than it was to draw in a window 35 years ago. And new mountains with better abstractions are being built: look to CHERI, Rust, io_uring. Maybe Oxide’s approach to firmware will succeed? I’m optimistic.
When users of all kinds complain about the lack of interoperability of software, data silos, and pervasive mono-cultures that we can’t upend by some random individual working in their garage, I don’t think of success.
When the majority of software re-use is now delegated to shipping containerized binaries because we can’t actually build portable, composable software, I don’t think of success.
When I’m subject to the few, if any, outlets of configuration that a piece of software will give me, apart from what the authors allow, I don’t think of success.
When I think that we’re still in the same general spot as we were 35 years ago, just with the ability to move faster due to the demands of capital and product, I don’t think of success.
I feel like … we know how to build good software and good abstractions. We see this happen a lot in open source projects where people have the freedom to do the right thing without pressures from management and executives breathing down their necks. Tremendous successes abound.
But we don’t know how to incentivize producers of commercial software to build quality products. Sometimes it happens by accident.
software should be detached from profit and market economy. There are several fields in which this just works better, like healthcare. Any serious attempt at bringing software under public control, assuming there will ever be enough concentration of political capital to do that before the end of the information age, would be met with incredibly violent resistance by the oligarchs that profit from private software.
If anything, the current trend is going the opposite way: regulations on software are being attacked left and right by the oligarchs and planes started falling.
I think the danger with that approach is that it’s difficult to ensure that the correct software gets created. Markets are a very good way of ensuring that resources get allocated relatively efficiently without needing a central planning system, and without having lots of waste. (Waste in this context is having everyone learn how to write COBOL when app developers are necessary, or vice versa.) Markets have a lot of issues and require a lot of careful regulation and interventions, but they are really good at decentralised decision-making, and we should use them for that purpose.
In fairness, I can understand why people might not associate the current software market with efficiency, but we’re talking about a different kind of efficiency here! The goal of the market is to match people with desires and people who can solve those desires. Right now, few people desire fast, efficient software, as hardware is mostly cheap, so it doesn’t get created as often. It might seem counterintuitive, but this is good: it generally takes longer and more resources to write a shorter, faster, more efficient program (in the vein of “I would have written a shorter letter but I didn’t have the time”), and that time and those resources would be wasted if people didn’t actually need the efficiency.
Where problems arise is where the markets cannot capture some aspect of the “true price” of something. For example, in the discussion on software efficiency, there are environmental issues which don’t get factored into the price of hardware, and there are many groups of people who have needs, but don’t have enough buying power for those needs to be properly met. In these cases, we need regulation to “fix” the markets - pricing in environmental impacts to hardware and running costs, and ensuring minimum standards are met for all software that allow people with various disadvantages to still engage with software. However, just because the markets require adjustment, doesn’t mean that we should throw them away entirely. Software needs to remain attached to profit and markets to ensure that software gets written that actually serves people’s needs.
I realise we’re in danger of getting off-topic here and I don’t want to derail this discussion too much. But I wanted to provide a short leftist defence of markets in software, and point out ways of solving current issues that don’t involve rejecting markets entirely.
The idea that I could spend time working on software that does things that people actually want is why I write free software outside of a market. It appeals to me specifically because the opportunity to do that is so rare in the industry.
In theory, yes, a company that could do this would do well in the market, but in practice any company that achieves this ability briefly ends up self-sabotaging it away in a short time.
I’m with you.
From the GP:
I think the part that bothers me the most is that a lot of the “modern” abstractions are designed more for plug & play and not for extension. “Frameworks” instead of “libraries”, as I’ve seen the distinction before. If what you’re doing fits well into what the authors were expecting you to do things work really well. And if you try to step anywhere off of that pre-ordained path things start getting really hairy quickly. I wish I could remember what the project was that I was working on a few months ago… it was UI stuff and the framework provided a fabulous set of components, but adding a field validator to a text field involved climbing 3 or 4 layers up the abstraction tower and making your own variant of some superclass and then bringing back a bunch of extra functionality from the subclasses you couldn’t use.
I 100% agree. I mean… thinking about to the late 90s and early 2000s, I do somewhat appreciate that many of those containerized binaries are going to be talking JSON over HTTP and/or Websockets and the languages I use on a regular basis all have really good libraries for those protocols. On the other hand, it’d be really great if a lot of that was a matter of linking a .so and potentially using an FFI binding instead. I’m absolutely exhausted from looking at code that JPEG-encodes an image buffer, takes the JPEG, base64 encodes it, stuffs it in a JSON dict, only to have the whole decoded process reversed on the other side.
I draw a distinction between abstraction and composition, which is also in the article. It’s not a hard distinction, but I’d say:
Composition means putting parts together to form a working system. Does the result work? Is it correct? Is it fast and secure? (Composition does feel more “horizontal”)
Abstraction means hiding details. Abstracting over Windows and Unix is something that I think is often accidental complexity, or at least a big tradeoff. It saves time for the developer, but it can be a loss to the end user. (Abstraction does feel more “vertical” – and fragile when you get too high)
This person, commenting on the same article, pointed out “shallow and composable” as properties of Unix, and I agree:
https://news.ycombinator.com/item?id=40885635
So I think shell composes, but it’s actually not very abstract. And this is a major reason I’ve been working on https://www.oilshell.org/
IME, shell gets a lot of work done effectively, without much weight, and is adaptable to new requirements. One person can write a shell script to solve a problem – you don’t have to assemble a big team, and justify its existence.
(Of course something that’s challenging is for that shell script to not become a mess over the long term, and I believe we’re doing something about that)
From the article:
This is generally my preference, but I would say “must” is not true … One thing I learned the hard way is that interoperability is basically anti-incentivized.
Long story, but I think the prevelance of YAML in the cloud is a “factoring” problem, but there’s actually a deeper economic issue at play.
That is, the people on one side of the YAML write code and algorithms, and the people on the other “configure” those lego blocks that don’t actually fit together.
YAML arguably abstracts (it hides details behind an interface)
But it doesn’t compose (when you put things together, they don’t have the properties you want) …
Similar to this comment - https://lobste.rs/s/saqp6t/comments_on_scripting_cgi_fastcgi#c_28yzy4
abstracting over OS always feels weird to me, when one of the main purposes of an OS is to abstract over hardware
abstracting over hardware makes sense, because we keep getting better at making hardware, we have different tradeoffs, etc.
but with OSs, it mostly seems like a coordination problem. sometimes an intentional one, because the organizations involved were trying to build a moat
Yes exactly !!
The OS already abstracts over hardware, and then we are piling more abstractions on top of OSes.
One that that leak – in terms of performance, security, or just making the application behave poorly
Electron is basically that – it lets you ship faster, but that’s about it
The “tower” or “stack’ is often not a good way of building software.
And the funny thing is that OSes are converging, with Windows gaining a Linux kernel in ~2016 (WSL), and then it also gained a Unix terminal some time later!
I guess to argue the other side, Unix was never good at GUIs … so it’s not like Macs or Unix were superfluous or anything. But it’s just that the most basic layer is still in flux, and it is converging on “Unix”, even in 2016 and 2024 …
(running Docker containers seems to require some sort of Linux x86-64 syscall ABI too)
As a thought experiment, I’d say if we knew how to perfectly abstract, we’d be able to write multi-platform GUIs that work perfectly on all targeted platforms.
But I think anyone who works in that area (I don’t) will tell you that it’s a big compromise. You can write something better if you start OS X only, or Windows only.
I think Flutter is something that abstracts over Android-iPhone, and there are many others.
And of course there were many attempts at Windows / OS X abstraction (QT etc.), but what seems to have happened is that desktop GUIs just got uniformly WORSE since those attempts were made.
Is an Electron app better than a QT app?
Rust is famously “not GUI yet”, and you can argue that if it had some yet-unknown great powers of abstraction, then it would be.
So you could say it’s an unsolved problem to have “zero-cost abstraction” in that respect (!)
(And yes this is a pun – the cost I’m talking about is in the behavior of the app, not the performance)
To summarize, I think there are many things better about where we were 20-30 years ago, but many things are worse. Latency is another one - https://danluu.com/input-lag/
Composing software from parts and maintaining latency is another unsolved problem.
I think a good stress-test of this argument is a field which seems like it’d pay in blood for every abstraction: gamedev. It’s also a field where 1) many projects are made by one person, despite the “proverbial death of the individual developer”, and 2) they work on towers of abstractions “as a tool to avoid hard thoughts.”
And yet these solo devs keep putting out absolute masterpieces: Minecraft, Stardew Valley, Baba is You, Tunic, just to name a few. If anything, the pace has accelerated in recent years, and I regularly play a game and find out later it was made by 1-2 people. So any conjecture that abstractions make it harder for individuals make software should explain why that doesn’t seem true in the field it’d matter most.
Oddly enough, I started my journey in game development! And I agree with you on some points, but not in others.
On the one hand, I am incredibly enthralled that indie developers have platforms to stand on. My argument isn’t “no abstractions”, it’s “careful use of abstractions”. Game development is where performance does matter to an extent, so the environment mirrors early computing where you actually pay the cost of the abstractions you introduce.
On the other, I think that we’re seeing the results of a filter, rather than the actual results. A lot of people burn out in game development, even technical individuals, because they exhaust themselves scaling mountains. Want to ship a game? You’ll realistically be dealing with entire engines and shifting your mental model to work within them, or you’ll be tolerant and technical enough to build your own.
I think it’s a question of tolerance of the norm rather than the norm being sustainable. But, as always, data, data, data.
Isn’t that true for every business though ? For every success there is a thousand people burnt out or living in terrible conditions.
I think if I’m in a position to advocate for better conditions for individuals, and I’m capable of bringing awareness to that, I should. I really don’t want to abstract these people away if possible.
Is it going to actually make things better, or just change the status quo ?
You said “On the other, I think that we’re seeing the results of a filter, rather than the actual results. A lot of people burn out in game development, even technical individuals, because they exhaust themselves scaling mountains.”
We have infinitely better tools than 30 year ago, yet much more people get burnt out today. Why ? Because the availability of these better tools actually increases competition and thus stress. The better the tools, the higher the mountain gets for everyone as our expectations increase - we always want something that is going to be better than the “average” video game / pizza / movie.
That’s a pretty good point! And I think it’s in line with what I’ve said: the disconnect between release cycles and “time to mastery” grew as time went on, and those curves diverged. If I give you more power over a system, phrased in terms of abstractions, your demands very well might scale with it, leading to the requirement for more power, leading to more abstractions, etc. etc.
It’s partly why I don’t think the solution is purely a technical “throw new languages/software/hardware at it” one, but something that sits firmly between how individuals interact with computers that are embedded in their daily lives and the cumulative technical knowledge we’ve acquired in the past 40+ years.
Minecraft and SdV is not masterpiece because of the engineering. MC will drop to 4 fps if you add 4k textures to it, Starfield on the other hand can provide a smooth 100 fps on the same machine. SdV is looking like a game from before the millenia. Gaming experience is not always related to the engineering efforts put in those games.
So, gamedev, as a field has definitely always pushed the bounds of what we know how to do with a machine. But the games you listed aren’t exactly AAA 3D graphics-porn. Not to say the devs aren’t good. You can definitely screw up bad enough to make those games run like trash if you’re incompetent. But you can definitely take on a couple abstractions to make things easier that a Crysis-level game can’t.
If there is a software crisis, and if there is a solution to it, it is definitely not writing software at a lower level.
I faded out a bit in the middle, but what is the problem exactly? This piece has lots of discussion about the cause of the crisis and very little on what the crisis is about.
I agree that this article could use some clarification. It seems like it’s giving some sort of call to attention or maybe even action, but I don’t know to whom or for what purpose.
To be charitable, and because the article was short, I read it a few times. Here’s what I got out of it at the end:
(begin attempted summary)
The origins of the software crisisThe first bit seems to describe some history relating to the term “software crisis,” but forgive me for not knowing my history well, I don’t actually know what this means. It then discusses how we have failed to address the crisis, although we think we have addressed it because we can hide its crisis-ness through abstraction (of what? I think of software itself?). At this point I’m picking up on the repetition of the word “performance,” and specifically the line
makes me think that this crisis is kind of like saying “our computers got faster [= smarter] so we got dumber.” Like how our forefathers knew how to tie 8 million knots and start a fire with their bare hands while we struggle to operate the electric can opener.
OK, cool, so that’s a start to understanding the problem.
The perils of the software crisisIt continues with detailing how as a result of abstraction, things are less hackable now and the individual developer wields less power (because of this? or maybe because of all the competition (corporations?) who can out-muscle them and are committed to preserving the less-control status quo). The end users feel this too, although it’s unclear whether it’s because there are fewer solo developers offering highly-configurable solutions (see above) or if it’s because software not being hackable is part of a larger problem of less configuration for everyone.
The bad actors in the software crisis (us)The article then circles around to asking “if this sounds so bad, why haven’t people done anything about it?” It answers this by saying “well we all are to blame here [we = software producers, but presumably not the solo developers because they’re a dying breed, so I’m guessing this is like people working for big tech companies], but we kind of have been ignoring our sins of abstraction for external reasons such as: curiosity, passion, peer pressure.” But also it’s explainable because using abstractions has been the path of least resistance for doing software development for some time.
At this point I’m still not entirely sure what an abstraction is but I’m convinced that it is the Devil I need to get out of my house. Or maybe the Devil I need to prevent from getting into my brain when I sneeze. Also, we haven’t been doing a whole lot of preventing the Devil from entering our abode/noses because we [now switching to the readers of Lobsters because they are also largely software producers] are the reason why software has a crisis.
Things can be betterAha! We return to the damning of Moore’s law. Well I’m acting like this is a triumph but I knew we would return here because I read the piece several times already. To be clear: the problem the author recapitulates is that we are separated so far from our hardware that we continue to “sweep things under the rug” which I presume means like no longer rolling our own graphics drivers or monitoring the heat levels of our CPUs to change major modes (sorry this is going off the rails but I couldn’t resist). And there is another mention of how people “way back when” knew how to Write Code because they had to, otherwise their program would take literally years to run. We [= modern day programmers], on the other hand, are not even bothered by programs taking literal years to run as long as they’re parallel enough that we can just run them on a big enough cluster in a few days.
So we finally move toward the end, which I must warn you is a cliffhanger, but not before a repeated mention that by killing abstraction we also lower the barrier to entry (of software development, presumably). After some mentions of other movements which seek to accomplish similar goals (but not identical ones, presumably), we are told that there is hope and we will hear about it.
(end attempted summary, which at this point is less summary and more annotation)
I think I puzzled out what is bothering me most about the article, which is that while it condemns Big Abstraction, it only does so in the abstract, thereby muddling its point. Lots of pronouns or “thing”s are referred to without it being made clear what they are. I know the author is floating around these comments: I would suggest giving a kind of “motivating example” of this problem (while also convincing the reader it generalizes to other examples/areas). Tell me what is the “that” and who is the “they” in “that’s what they say” (this is a square Far Side reference forced into a round hole, so forgive me if it doesn’t make sense). And additionally, please forgive my snide or snark: I’m in an impish mood.
I also am bothered by the whole “people were smarter when they wrote assembly” line beneath the surface, but I won’t go further into that.
Users found programming a vcr unpleasantly technical. Users flooded to the iPhone. Users loved Windows 3.1 instead of DOS.
Users adore not being in fine control and having a simple on off button.
Pip install anything was earthshaking. (Although ofc cpan was earlier).
Any model of software that doesn’t incorporate the low control high black-box approach in some fashion isn’t going to work well.
I would argue that the essay Engelbart’s Violin hits the problem better.
Users don’t adore these things, businesses that pay top dollars trying to reduce time-to-market to the minimum do, it’s not because of “users loving javascript” that NPM is one of the biggest package repositories in existence today; same reason why Java got so big, it caters to businesses not to the software crafters, they don’t give a damn about building better software, let’s just see how far Go went without even supporting generics and basically throwing away innovations in programming language design since the 80s.
Make no mistake, software as it is today caters to the capitalist business model, if you want a technology to succeed better have a good marketing team and good preacher/salesman behind.
Not to keep bashing on Go, but think for a second, if it was not by Google and not having Rob Pike or Ken Thompson behind it, would it have succeeded? The answer is NO, let’s be honest.
Microwave interfaces have whole interface subsystems designed for one poke start, rather than entering specific time and power. Also, again: iPhones, VCRs, Windows 3.1.
Your model is “businesses don’t care about shipping shoddy”.
I suggest that users are fine with that quality, if they don’t have to think - https://en.wikipedia.org/wiki/Don't_Make_Me_Think . That is, lack of needing to attend to details is a significant advantage for many users across many domains, regardless of the underlying whatevers.
I write Rust, use emacs heavily, and spent a decade running Gentoo, so - I’m not that person. But I recognize the popularity and weight behind that world.
“The solution to the software crisis will not be a reversion to more constrained platforms.”
The stereotype of reversion to non-automated, non-abstracted usage of software as a solution is one I really need to argue against. We can build things that users enjoy without having to revert to constrained platforms, while at the same time restricting the amount of abstraction we can apply.
I’m saying that you need to address the well observed preference (revealed preference) for KISS designs, even if they strictly constrain the user - and many users do prefer to be constrained.
I’m not going to say I am one of them. 🙃 Just, most people (devs) I have worked with want the ez button to slap, even though it isn’t optimal in many ways.
For sure! I also want that easy button, just not phrased in terms of existing towers of abstractions. If you consider all current software “prototypical”, in that we’re building scaffolding on top of scaffolding, rather than core building materials, then it’s time for us to step back and see where we can start solidifying things.
That’ll come with the removal of a lot, but like a good diff, judgement shouldn’t fall upon the lines removed, but on the functionality present after the patch. We need to do some compression and consolidation.
There are a couple of references I’d bring to the conversation. I’m going to get details of these recommendations wrong, since they’re larger reads than I have time to check at the moment, but I hope they’re helpful in broad strokes.
First and foremost, Fred Brooks’ No Silver Bullet. One of the things I took away from Brooks’s essay is that resolving some part of the “software crisis” does not actually make engineering easier. Rather, it increases the scope and complexity of the domains to which we apply engineering. Whatever else you’d say, software is extremely more important to functioning society than it was in the ’60s when the Software Crisis was described.
Secondly, and I’m not as confident here, Peter Drucker’s The Effective Executive. I have the idea from Drucker (I believe) that “executives” (the way he used the term) are characterized by those whose decisions (as opposed to more straightforward execution of stereotyped activities) make material difference to the success of an organization. This is, I think, most of us, though not all in the same way. I bring this up because in the software industry, we’re working largely with thought-stuff, rather than physical or chemical processes. When the medium is thought, the bottleneck of forward progress is the speed of thought, and of communication. Being a bottleneck is difficult, and (I seem to recall) Drucker’s book had much to say about managing priorities in such circumstances. When forward progress is (more-or-less) always possible, time spent on business needs to be explicitly balanced with other desires and obligations. Feeling that the set of technical demands on practitioners constitutes a crisis feels (to me) like a failure of prioritization or of realistic planning.
Is this true? To echo the article “against innovation tokens” plenty of shiny new software exists to reduce the operational complexity of managing the kind of online computer systems that back saas.
Adding ladders to a mountain doesn’t change its height.
This also applies to all kinds of software written, not just software as a service.
This is a great introductory post and I’m looking forward to the follow-ups. Is there an Atom or RSS feed associated with the blog?
Regarding the point in the article, I think abstractions are important because they allow us to ignore things we don’t care about. Without (or with too little) abstraction, you’d just end up with sprawling amounts of low-level code, which is hard to navigate and make sense out of. With too much abstraction, you end up with towering complexity and it will be hard to get down to “what does this code actually do?”.
But abstractions also have other risks, since creators of abstractions often don’t care about things you might personally care about. Oftentimes, that’s performance, but there can be other things as well. Then you end up bypassing the abstraction or hacking around to “reach down” underneath to get to the thing you need to do. That’s when it gets ugly - like trying to type with mittens on, it hampers your ability to express what you want to express.