A Plea for Lean Software (1995)
liam-on-linux.dreamwidth.org
liam-on-linux.dreamwidth.org
Thank you, @thunderbong. I just thought it might be more readable than the various PDFs floating about. I have had emails from blind readers of El Reg saying that some PDF versions are inaccessible.
Not my own writing, obviously. All I did was transcription.
The other reason software bloat persists is because knowing enough about the runtime of your software to even be offended by the presence of bloat is exceedingly rare. Repetitious and pointless tasks abound in modern software, where work is done at one layer and then thrown away and redone by another, repeated N times. But to even know about this requires that you understand your runtime and what its doing in your case, and in our industry, ignorance is (economic) bliss, where "go along get along" is richly rewarded and any aesthetic or moral objection to how things are done is harshly punished.
Strong and real social and economic forces drive bloat and punish the individual that would combat it. Which is why those who make the (at some level, doomed) attempt to fight bloat deserve at least our respect and some honor, since they will not only not receive thanks, they will be actively attacked by those who (correctly) perceive their work as a challenge to the status quo, and hence dangerous, unwanted, and a target.
* Dip pens and brushes, the original inking tools, rely on the user having a pot of ink available and some fine-pointed object capable of holding the ink. It's very simple, but this two-piece design limits situational use and requires the tip to be scrubbed off like used silverware. But you are relatively unlimited in what you put in the ink and the style of the nib, making it one of the best artist's tools even today.
* Fountain pens innovated by creating a reservoir inside the pen, and a feed mechanism. This creates a modular pen body, allowing the user to customize a body with different inks, reservoir mechanisms(cartridge, piston, etc.) and nibs. However, the ink has to be liquid enough to gravity feed, and cleaning the pen and fixing feed issues is a more involved process, making fountain pens reputed as a temperamental platform with many tradeoffs for portability.
Disposable ballpoints and markers devised a one-size-fits-all solution: make refills be the "whole pen", comprising tip and reservoir, and leaving the body as just a shell. This has allowed the designs to become very intensively engineered, with customized gel ink formulas, rubberized marker tips, etc. However, most of these designs are not made for longevity in some dimension - gel refills dry up, oil-based refills fade, marker tips get smashed. As well, there is a limited range of line styles achievable from a ball or marker.
Lastly, there is a recurring Kickstarter scam in which a "printer pen" is demonstrated, with selectable RGB color. Besides the fact that this product doesn't really exist, it would make the pen into something even more complex than a fountain pen.
So in solving technical problems, I think computing necessarily converges on answers similar to how pens are engineered: if you want it to be very simple and exacting, it's a dip pen, and you have to "plug it in" each time. If you want it to be easy-use, to last a while and to get out of the way, you want a pack of Bic ballpoints. If you want some mix of those things, you end up in the space of markers or fountain pens.
But software lets us make the RGB pen, actually have it work and be used by people. And that is a problem, because now our expectations are that nobody should have to use a dip pen ever again, when a large part of the population didn't even get exposed to them and lacks the agency to choose.
I write high-performance business/enterprise software every day and get rewarded for it. Keeping the architecture simple but fast by design makes everything so much easier and productive.
I really wish developers would take responsibility for their own low performance code instead of blaming everybody/everything else.
Software increasingly adds itself to "run at startup" automatically. Nobody needs to have a bunch of startup user interface apps. It is completely unnecessary and has little purpose other than data collection.
A work VPN I have to use requires a startup background service. I'm not even using it, it does not need the service to operate at boot. Steam service does this too, as do many other applications.
Microsoft will remove my group policy that disables their useless and performance destroying antivirus. The software that is one of the big 10 in causes for why windows laptops are trash. FYI AV's are humorously easy to bypass. Adblockers and browser settings are more effective.
On MacOS I can just disable these easily. On windows, I need auto runs to ensure, and either the application breaks (steam) or it'll turn itself back on.
"A plea for windows' demise". Preferably the rest of Microsoft with it.
Most apps that throw a startup process in the background are probably aiming for (in part) an auto update service. Why don’t OSes provide a service that an app can register a URL to check for updates at? Yes the App Store does this for apps installed there, but outside the App Store there’s no way to do that and to my knowledge nothing like that exists for Linux or windows (barring the few things that seem to be available in windows updates).
The other part of course would be even if the OSes did provide this, who would write code for it? Maybe electron would have a function to register with the os native endpoint but until/unless they did, would any electron devs code for it or would they keep writing their own services?
It's great that your development computer has 32 cores and 64GB of RAM. But your users aren't so lucky.
“A Plea for Lean Software” by Prof. Niklaus Wirth (Non-PDF Version) - https://news.ycombinator.com/item?id=33203181 - Oct 2022 (2 comments)
A Plea for Lean Software (1995) [pdf] - https://news.ycombinator.com/item?id=27661559 - June 2021 (137 comments)
A plea for lean software by Niklaus Wirth [pdf] - https://news.ycombinator.com/item?id=27617277 - June 2021 (1 comment)
A Plea for Lean Software (1995) [pdf] - https://news.ycombinator.com/item?id=24059704 - Aug 2020 (137 comments)
A plea for lean software (1995) [pdf] - https://news.ycombinator.com/item?id=17872400 - Aug 2018 (100 comments)
A Plea for Lean Software (1995) [pdf] - https://news.ycombinator.com/item?id=8537970 - Oct 2014 (3 comments)
Niklaus Wirth: A Plea for Lean Software (1995) [pdf] - https://news.ycombinator.com/item?id=8301511 - Sept 2014 (12 comments)
A 2024 plea for lean software - https://news.ycombinator.com/item?id=39315585 - Feb 2024 (240 comments)
Features are celebrated and make money - whereas performance can be gradually salami-sliced away, with nobody advocating for it.
If you can add a feature and it adds just 50ms to a 300ms pageload - it's unlikely anyone is going to block its release on performance grounds. And once the feature is released, there's no removing it.
This means performance gradually ratchets slower and slower - until it becomes intolerable. And by then, different performance issues will be everywhere in the codebase, so fixing them will seem an insurmountable challenge.
Far cheaper to ignore the problem. "Jira is only slow because customers insist on creating tickets"
The whole process today exists to support a big class of managerial people(including scrum masters, PO's and PM's) whose salary depends on not understanding that the process is completely broken.
I think it's even worse than that - those unnecessary processes only exist to try to help management attempt to manage content they don't understand in the first place.
And I say this as someone who regularly implements said delivery processes for customers.
(The "test everything" culture was also AIUI in the service of quick iteration; the first versions of Agile are from the early 2000s when dynamic languages were starting to get popular and there wasn't really any kind of static analysis.)
The problem is that companies don't understand what this means, and find it simpler to pay an "expert" who will bastardize this definition, and implement processes and tools that make them appear useful to the company. There's an entire industry built on this model.
Agile depends on not having a “big class of managerial people” micromanaging [1] every move done by the squad.
No methodology will work when someone is actively fucking up the process, and agile is no exception.
[1] In before some smartass comes to say “so you don’t want managers”… I qualified my statement with the word “micromanaging”.
You put a hundred developers on a project and you'll generously get twice the meaningful output of ten developers (but 50 times the LOC; as demanded by conway's law).
The upside is that this makes it all the more feasible for a small group or even single individual to be surprisingly competitive. Peak productivity per person is probably is probably found in a self-organized 1-3 person team.
[1] https://adamdrake.com/command-line-tools-can-be-235x-faster-...
Based on my job experience, this is rather an artifact of how software projects are (badly?) managed.
Give each of the developers some small "hotspots" to work on (i.e. critical code fragment that is
- hard to implement correctly and fast
- which is critical to implement very fast and correctly
- a correct and intended implementation will likely consist of few highly sophisticated lines of code
), and the scaling will be much better. This is a little bit like theses are assigned to students: each thesis is one isolated non-trivial scientific challenge (often open research problem) that is to be solved by the student.
I guess the "management incentives" nevertheless prevent such a method: managers prefer/are incentivised to "tell stories" instead of explaining the deep, sophisticated challenges and solutions in making great implementations of these "hotspots".
This is what in my opinion senior programmers or project managers are for. If they are not capable of handling this task decently, these people simply are not (yet) ready for this role.
Having this consideration in the back of your mind:
What might be helpful concerning your questions is to consider that many programming languages suggest a specific style of approaching the programming project, structuring the code, often managing the team, ... . There exist good reasons why one talks of "Java shops", "C# shops", "Python shops", ... because these programming languages often imply very different company cultures. Note that very prevalent programming languages can also have various "subcultures" ...
So what will likely be valued is to have a good understanding of the "desired programming style", "desired problem solving approach", "desired management style", ... that is encouraged by the "programming ecosystem" in which the company is placed, and going by it.
This will likely yield a decent, conservative code base that can more easily be passed over to a more experienced programmer as soon as one becomes available: especially for such a situation, it is in my opinion much more important to "not to make huge (also architectural) mistakes" than to deliver the most fancy/ideal code (but note that if you work at a startup that has an "all or nothing" approach (i.e. if the product won't become great, the startup has failed) or is in fear of running out of money, the priorities might differ quite a lot).
> not to make huge (also architectural) mistakes
I'm noticing it's the first time I'm even having to make significant architectural decisions, which is difficult because I don't have much experience to draw from, so even the smallest decisions often require a lot of research.
I think big projects are worse simply in proportion to their size. I once spent months with a client adding requirements when we were supposed to be doing UAT!
It's an inherently more unpredictable way of working, but that definitely cuts both ways. There are definitely more risks, but also far greater payoffs in terms of what you can do working in this fashion.
The principle of ensuring predictable velocity across a team comes a cost of limiting maximal produtivity amongst talented individuals.
Business skips part where for years they insist on pushing features out. Where there most likely are tons of easy fixes that can speed up performance if you give the team time to focus on that.
Going back to “outside help” then you get people who don’t understand current system and propose some silver bullet like throwing noSQL because that “will fix your issues” - but they don’t say cost is basically redoing the system, project goes under, third party guys count money, put another success story on CV because no one will validate it anyway…
I worked on a team that did this. It was easy to justify because the benefits of the feature were almost always counterbalanced by less usage of the product, and we had numbers to back it up.
- Optimists tend to be promoted, so the higher up in the organization you are, the more optimistic you tend to be. If one manager says "I can do that in 4 months", and another only promises it in 6 months, the 4 month guy gets the job. When the software is 4 months late, the overall system complexity makes it easy to assign blame elsewhere, so there's no way to judge mis-management when it's time for promotions.
- There's a disconnect between engineering and marketing. It's not surprising -- marketing wants all the whiz-bang features, it wants to run in 16 megabytes, and it wants it yesterday. Although engineering would like the same things, it is faced with the reality of time limits, fixed costs, and the laws of nature.
- The complexity of our system software has surpassed the ability of average SGI programmers to understand it. And perhaps not just average programmers. Get a room full of 10 of our best software people, and you'll get 10 different opinions of what's causing the lousy performance and bloat. What's wrong is that the software has simply become too complicated for anyone to understand.
- There was never an overall software architect
- We should sell 'bloat credits', the way the government sells pollution credits
- SGI software has a cracked engine block, and we're trying to fix it with a tune-up.
From 1993:
https://www.seriss.com/people/erco/sgi-irix-bloat-document.t...
I like your take, but I'm not 100% sure this is accurate.
Obviously to some extent features make money, and "featureless" software by definition couldn't exist. But I think a lot of software contains features that don't drive demand at all - the worst contender for this that I can think of is [Microsoft Teams' Together Mode](https://www.microsoft.com/en-us/microsoft-teams/teams-togeth...) which I doubt has led to a single sale of the product worldwide, but probably adds some maintenance burden.
I think a bigger part is, like you mentioned, the organisation of companies. Engineers like building things, and although maintaining software and improving performance can be rewarding, you'd struggle to find developers that are happy to only do that. Features also lead to promotions more than maintenance, so there's a strong personal incentive to create features even if they don't have a business benefit.
I think this is a bit of an over generalisation. There were (and still are) many large companies producing performant and reliable software. I suspect when things just work (think of the global phone system) people don't realise how much software is involved. When was the last time you picked up a fixed line hand set and there was a software bug preventing you from calling any other handset on the planet - without varying delays or dropped packets?
Unfortunately this is happening, because compute power is cheap these days. It allows programmers to be lazy, take short cuts and not think about good software architecture. There is no economic incentive to optimise, because human perception won't perceive a difference and thus nobody complains. It's wild to think that we have basically supercomputers in our home and yet developers managed it to bring it down to a crawl with things like electron apps.
Just an alternative take that I don’t entirely agree with but I often find rephrasing a problem in alternative tone it can help to understand it in non adversarial terms.
In this case I see strong parallels with the auto industry and food distribution
I think it has little to do with laziness, and more to do with the taboo of reinventing wheels. If there's a very generic and very broad solution to your very specific and very narrow problem, you're encouraged to use (or invent!) the very generic and very broad solution.
This leads to everything being abstracted to the point where most of your application does absolutely nothing. Just look at the call stack of a modern java web application. The depth of the layers of abstractions that you need to navigate to reach anything that performs any real work is vertigo inducing and nauseating.
It far from ideal and I agree that economics is behind it, but I strongly oppose the wording that it "allows" programmers to be lazy.
Now we do the same, but we look at the text editors of 1995 which used 4 MB of RAM as incredibly efficient and well made, paragons of craftsmanship.
Things never change, the old generation fights the new one and calls it stupid.
I'm not saying old editors weren't more efficient but the stuff editors handle today got more complex. LSP servers do way more analysis than any 1995 editor and they do it in an editor agnostic way. It costs more memory but it also lets us all jump into the future faster rather then every editor having to implement their own for every language.
Remote editing back in the 1980s was such a common thing on the Smalltalk and Lisp Machines that all system code was on another machine, more times than not you wouldn't even notice that it was a remote file!
One could do "emoji" just fine as well, and files would have WYSIWYG like look to them using "fat strings" -- that is 1980s technology. There is a dungeon crawler map using that feature to render the map as graphics, it is how you would implement chess pieces, or other "picture" like stuff.
Auto-complete was already standard, similar look up of "who calls" / "who uses" functionality to figure out where things are used, online documentation, etc etc etc...
So all this was perfectly possible, and already used and abused in 1995 -- VSCode isn't doing anything new in that regard.
Lest we mention Plan 9!
A color dialog was tens of KB of code in the 1980s.
My own editor handles Unicode well enough for most users in a few dozen lines of code. RTL would take a bit more, but not much. LSP servers if anything reduce the need for the editor resource use to grow.
It's not that these justify no extra resources use because they do, but they don't need to significantly increase resources use.
A lot of apps get away with huge resource use simply because people aren't used to paying attention to it any more, because for most it affects them little enough in isolation, per app, that when it matters addressing the resources use of one hardly makes a difference.
It's only when you subjectively remove all the features that you don't care about that it becomes doable to make smaller editors. And that's fine. But you can't have your cake and eat it.
The reason most people don't care is because it simply doesn't matter. Not even a little bit. Laptops are cheap. Memory is cheap. CPU is cheap. Your time is not. And it takes investing your time to make this stuff more optimal and faster. And VS code just does a lot of nice things that make you more productive. I use Intellij myself which uses even more resources. But it's a bit smarter and saves me even more time. The point with both is that you lose more than you gain by replacing them with something faster. It's not worth it.
My first computer was a commodore 64, so I'm well aware what that thing could do (and couldn't do). I'm writing this on a M1 macbook. Orders of magnitudes faster, doing things I could not imagine back when I had a commodore 64, etc. You can have one second hand / refurbished for next to nothing. Basically below my day rate when I'm consulting.
> It's a bit theoretical because no editors exist that are smaller that do all of what vs code does
You can't ever compare two things if you look for all features to match. Sublime is a pretty good comparison - it's wicked fast, has a bunch of the same features and language extensions. Emacs handles unicode just fine and has a huge extension surface area.
> The reason most people don't care is because it simply doesn't matter
Hard disagree here - the reason people don't care is because features sell, and as you said, the alternative option isn't there. I work in Unreal Engine most of the time, and about 3-4 years ago, there was an almost overnight exodus of game programmers who would live and die by Visual Studio who switched to Rider, primarily because it was faster than VS+VAX.
> Laptops are cheap. Memory is cheap. CPU is cheap. Your time is not
This only applies with one application. Now add Slack/Teams, Postman, Outlook, FF/Chrome, Spotify in the mix, and all of a sudden I'm running 6 full web browsers duplicated with all their resources isolated, using more menoey and CPU than Intellij does. I'm fine with Intellij pegging my 32 core thread ripper to index millions of lines of code. I'm less fine with Postman using more CPU than Intellij to display a json document.
> Im writing this on a M1 macbook
Depending on what software you're working on, your users aren't using M1 Macbookd. My partner's work machine is a5 year old i3 with 8GB of RAM. It's borderline unusable with teams and Outlook running IMO. But the person who benchmarks teams is doing so on the M1 MacBook.
Anyway, end users care even less. The paying user variety typically has a newish computer (of the last five years or so). The rest are not a great revenue stream. But of course, if you develop for users stuck on really old crappy laptops, of course you are going to invest your precious time in making sure they get a great experience and make all sorts of compromises to ensure they do. But for the rest of the users, good enough is good enough. You'll see from your revenue/usage statistics what that is.
I find the people that whine the most about this topic are exactly those people you should expect to have decent hardware (i.e. developers). Either way, use things that are useful to you.
Spotify and Slack, Teams, etc. seem to be doing OK with user popularity for example and don't seem to be getting a lot of churn over their application performance. And of course a lot of this stuff is used on mobile as well. I've used both for the last ten years without much issues on modestly sized laptops. 16GB is more than enough for me running stuff like that, vs code, intellij, a bunch of docker things, and a few other bits and bobs.
People using MS Windows seem to get a particularly rough experience. That's why lots of developers prefer mac or linux based machines.
If those apps were PWAs instead, it would mean no extra browser copies are running. In my experience this only really accounts for 70-100 MB per app for the browser copy. No reason slack couldn't be a PWA, same with Spotify.
I'm not really sure how slack and others use so much RAM. I've built quite functional, complicated, and non trivial web apps. Mine typically use <50 MB with some coming in at 20-25 MB. When I'm deploying in electron I'm still in the 80-150 range.
The biggest performance questions for me are network latency vs local data and figuring out ways to mitigate network latency. The difference between 200 ms navigation and 5 ms navigation is pretty stark. Even if most people don't flinch at 200 ms.
Or your company should buy you a new 96 core Threadripper 1 TB RAM system so that when you use Spotify/Slack/Postman it doesn't impact your productivity.
You feel entitled to use a $10K machine to compensate for slow IntelliJ for maximum productivity and convenience, yet deny others (Postman/Slack/...) using the most productive and convenient technology for them (Electron). And while continuing to use their convenient products, you say they are bad. Use IRC, use curl instead of Postman.
The Postman programmers say the same thing: our users have $3K+ machines, no point in optimizing code to be fast, instead lets add more features since it's clearly working and our users are not switching. Obviously they love the iteration speed that Electron gives us.
I've been a paying slack customer for a decade at this point. I pulled up my email, my support ticket for "slack is using more ram than visual studio" was in February 2015. I don't have the political sway over Salesforce to makthem make these sorts of decisions.
> You feel entitled to use a $10K machine to compensate for slow...
Youre doing it again. I don't feel entitled. I don't have a choice in my chat app, my employer forces it on me. And even if I did, slack is on the whole the least worst option. As for postman. I did the same thing. I was a paying customer, I submitted support tickets, provided traces when asked and ultimately I did decide to change tool.
> while continuing to use their convenient products, you say they are bad.
Am I not allowed to have an opinion just because I have a fast machine? Am I not allowed to want my software to be better?
> The Postman programmers say the same thing:
No they say "performance is a top priority for us, we're sorry you're not happy with it. Please send us your hardware specs" and the ticket gets auto closed after 2 weeks.
> Obviously they love the iteration speed that Electron gives us.
It's not just electron - snappy electron apps exist. Startup time aside. VSCode is pretty damn good. Figma is an excellent example of how good it can be (and if you want to compare what it looks like when a company cares Vs a company doesn't, see figma and Miro).
$10/month is not what I meant by "paying them". I worked at a company where clients would routinely pay us $200K to implement a particular niche feature which was not on the roadmap. If they asked for a non-roadmap feature, yes, the ticket would be closed "not-planned".
> the alternative option isn't there
> I don't feel entitled. I don't have a choice in my chat app
Your responses are predicated on the option being there and the person you're responding to is just not taking it. This despite the fact that his or her responses strongly suggest they would take it if it were there, but it's simply not an option.
All this Electron app complaining reads like First-World Problems(TM).
Or one can go back complaining "how the world is cruel, people are mean and greedy, I'm a good and misunderstood person which writes the most efficient and user considering software, unlike the evil people at Slack"
Not GP, but they could buy me a 1024 core monster if it exists, it would still not solve the problem of Slack.
I still have to open it in the browser every once in a while, to search old threads or other stuff that is not supported. But day to day I can do everything in irc. There is also a weechat plugin afaik.
It's a bit annoying to configure the access but it seems the tokens never expire (or have not yet expired) so it shouldn't be too frequent for you either.
It's not special. If anything it's one of the most clunky editor I've used because it tries to shoehorn everything into a convoluted UI. It's because my time matters to me I avoid VS Code as much as possible.
The problem with VS Code is not that it's too slow, or too memory hungry. It could use far less, sure. And it could do so without losing any of the things about it that makes me dislike it.
If you don't like it, use something else of course. But there are valid reasons for it being browser based and a lot of people choose to use it at this point.
A lot of people choosing to use it is besides the point being made, which is not that people won't use it, but that it could be a lot leaner without sacrificing functionality.
Of course, Sublime Text exists and does everything I want from VSCode at a fraction of the hardware usage. So I don't have to choose one or the other, because actual good software exists.
An Unicode font is easily 15 mb in size. Let alone that you'll have several of those. And the code and memory that takes to do all the magic of rendering it, hinting, and subpixel antialiasing.
Then there's that a 4K framebuffer is 32MB in size.
Smooth compositing requires every running program to have a buffer it draws into. So there goes a couple hundred MB more just to make sure you don't see the screen repaint like in Windows 3.1.
Yeah, you can have compact software where your only requirement is that it uses ASCII, does it at 80x25 and doesn't do anything more fancy than editing text.
The idea was that programs would share libraries, and so why have a dozen identical frameworks on the same system? Install your libraries into system32. If it's already there but an earlier version, deploy your packaged one on top.
Turns out that nobody writes good installers, and binary level dependency requires too much discipline, and dependencies are a pain for users to deal with.
So shove the entire thing into a huge package, and things actually work at a cost of some disk space and memory.
I have ~10 000 .exe files on this machine, if none of them shared code and/or data (or were written in a ``modern`` language with 50+ MB hello worlds), they would not fit on my 1TB disk.
What if you're working on something reasonably novel, like say, open source VR? Well, turns out you may want a quite eclectic mix of dependencies. Some you need the latest version, because it's state of the art stuff. Some is old because the new version is too incompatible. Some is dead.
Getting our work into a Linux distro is on my list, but even if dealing with all the dependencies works out, there's the issue of that we sometimes need to do protocol changes and upgrade on our own schedule, rather than whenever the new distro is released.
Distros are great for things that are supposed to integrate all together. They're less ideal for when you're working on something that is its own, separate thing like a game.
So for the time being, shoving it all into an AppImage it is.
Why? Well, because it's the one everyone else uses. It's what comes with everyone's Linux distro. Therefore, if there's something wrong with it, it's pretty much guaranteed it'll break other stuff and somebody else is going to have to fix that. Also it probably supports everything anyone might ever want.
If your 700 LOC TTF renderer doesn't perform as it should, it might become my problem to figure out why, and I don't really want that.
I ended up with this one in large part because it took less time to rewrite libschrift (the C option I mentioned) and trim it down for my use than figuring out how to make Freetype work for me. I now have a codebase that's trivially understandable in an hour or two of reading. That's what compact code buys you.
No, it won't do everything. That's fine. If I need Freetype for something where it actually saves me effort, I'll use Freetype. It's not about blindly rewriting things for the sake of it, but not lazily default to big, complex options whether or not they're the appropriate choice.
A lot of the time people pick the complex option because they assume their problem is complex, or because it's "the default", not on the merits.
There are tradeoffs, and plenty of times where the large, complex component is right, but far too often it is picked out of laziness and becomes a huge liability.
You say that as if it was some kind of failed one-off experiment of the 90s. We tried it in the Multics days, it caught on and the design philosophy is still popular to this day. It works quite well in systems with centrally managed software repositories, even if it doesn't in a system where software is typically distributed on a 3rd party shareware collection CD or download.com.
Behold! The peak of technological prowess! So many poor souls of the past died in misery and 4 MB of RAM. They could not taste those sweet fruits of progress.
E.g. in "waste" that is fine, I'd categorise AmigaE's choice to read the entire source file into memory, instead of doing IO character by character, or line by line from small buffers. It was a recognition that there was no compelling reason to not sacrifice that small amount of RAM for simplicity and speed. What you gain can differ, but as long as the benefit is proportionally good enough relative to the cost, that's fine.
But so much modern software pulls in huge dependencies for very little benefit, or try to be far too much, instead of being focused tools that interoperate well.
It's not so much that the new generation is stupid, as that a lot of people (of any generation) always choose the easy option instead of stopping to think. Sometimes that's the right tradeoff, often it's not.
And hardware advances mean you can get away with more and more. Sometimes that justifies more extravagant resource use. Often it doesn't.
This is only an issue if your OS doesn't have virtual memory and mmap. Modern OS's automatically prefetch files into free RAM (so there's no such thing as "free RAM is wasted RAM" either). I think newer versions of Amiga OS were supposed to be getting virtual memory support at some point, too.
It was an inspired choice, and about 30 years on it's still underutilized, on machines that typically have 3-4 orders of magnitude more RAM.
I was with you until here, which I think is the wrong take. That is, this gets it exactly backwards. It's not just that every generation gets upset at the previous generation so let's all shrug and move on, it's that this is really a thing that is unfolding from one generation to the next.
It seems like the reflex of oh well the previous generation said it so let's ignore it comes up a lot, to the point that I have this go to example that I use every time it does. I'm a baseball fan. And one thing you used to hear in the '80s, with a guy like, say, Rob Deer or Steve Balboni, was that they tried too hard to hit home runs and they struck out too much. Then you heard that in the '90s as well. Then you heard that in the 2000s, especially with money ball and guys like Jack Cust. Then it just kept getting even more extreme with guys Carlos Pena and now Joey Gallo.
So one thing you could say is, well, every generation says that there were less strikeouts in third day. But there's actually data on this and..... it's true! Almost every decade, from the 1800s through every decade of the 1900s through now, strikeouts really have been going up year to year. And so that intergenerational commentary, well, it's describing a real thing that really is happening.
The same can be said of other things, like people saying they always used to remember the environment being better. Or people saying attention spans are getting shorter. But, they are.
The instinct here I think is to dismiss these since every generation says it. But I think the conclusion should be opposite, that these are real things unfolding on a multi-generational level. So if you see it happening with software, maybe that's because there's really something to it.
The argument seems to imply that the dissatisfaction would be there regardless of the circumstances. But the point I'm making is that the dissatisfaction can be understood as meaningful and not as just a generalized disposition that's a natural consequence of getting old.
And whether or not I'm right on that, the devil is in the details there, and it's going to depend on a case-by-case basis. But it won't do just to say well the older generation is going to complain no matter what, because that doesn't credit them with the possibility of complaining for a legitimate reason.
And there is no dissatisfaction of the younger generation? There is no, this is the old way let's do it differently because we are more clever by the young generation?
Tell a kid learning to program today "you should program in assembly because it's efficient, like I did back in my days".
Kid looks around and sees it would take him 3 days to implement a hello world in assembly, but only 3 seconds to do it in Python. He has a 16 core computer with 64 GB of RAM. Both hello worlds run instantly. So how does that advice make sense? Kid calls you a crazy old man out of touch with the times. Kid goes on running locally a 50 GB LLM to make it do a hello world and feels very excited about the future of programming.
For one, I think the accepted premise in this conversation up till now was that there is a real issue with software bloat. And you've switched that detail out for a different one where we assume no discernible bloat or difference in performance as time passes.
I also don't think that I understand what's going on in the pivot from generational examples to individual ones. I feel like at least the comment I replied to was pretty clearly about generational trends. But on another level I think that the upshot is the same regardless of whether your surveying that disagreement at a general level versus its equivalent manifestation at an individual level.
I think the upshot would be the same in each case as long as you keep all the details the same, and I think somewhere in the transposition from the general to the individual and agreed assumption about bloat and underperformance of software, as well as some implications about what that means about prevailing assumptions and practices surrounding software development, got lost in the translation from one to the other.
I agree with the factual observations in your post, but there's an additional bit here, and that there's qualitative value being assigned to what The Youths don't mind and The Olds protest. In baseball, the guys who strike out a lot but hit a ton of home runs create more runs, and therefore create more wins, than most base-hit machines (obvious outliers exist, but you get the idea). On my computer, VS Code does more things that benefit me than vim does (and the outlier here, I guess, would be "a lovingly crafted vim monstrosity that uses all the LSPs etc. designed for VS Code et al in the first place"--doable but not the happy path, etc.).
There's also (and IMO this is more in code than baseball) some kind of bizarre moral valence assigned, and that I don't even pretend to understand, but that's a different story.
A few things here. I want the main center of gravity in the point that I'm making to be a way of approaching intergenerational reports of a given phenomenon, namely that they shouldn't just be dismissed as a function of old age or a function of changing perspective. After that point, pretty much any point you want to make is fair game as far as I'm concerned. In the case of baseball, there are positives and negatives. It clearly seems to be a positive trade-off for hitters who are choosing which style to take. I suppose there's another consideration at a higher level as to whether it benefits the game itself. So that can go either way in my opinion depending on what's important.
I tried at the end to throw in some other examples, shortening of attention spans, and environmental degradation. I think in those cases it's clear that there's something negative going on. But in general we don't have to agree with the value judgment if it's negative, but I think the positive or negative value judgments is an independent thing from the phenomenon of multiple generations attesting to some thing happening.
That's because the text editors don't exist in a vacuum; the 4MB-RAM text editor would be slow on a 1995 computer but blazingly-fast on a 2024 computer.
VS Code is slow and annoying to use, and RAM is just a more measurable symptom of that.
Jetbrains (IDEA IntelliJ, Pycharm, etcetc) put a lot of effort into making their IDE low latency as it was getting to a point of being almost ridiculous. Their editor is built in Java, and they run on their own runtime as they have so many hacks and tweaks to make it work as a desktop app as well (font rendering, etc).
Pavel Fatin has a [great article](https://pavelfatin.com/typing-with-pleasure/) about typing latency and his work around implementing this in IntelliJ, well worth a read.
Running a heavily scriptable editor with a GUI was entirely viable on a 7.16MHz Amiga with 1MB RAM, and more responsive than many modern editors.
Integration with other tooling, like RCS, compilers, or linkers was a given for Amiga apps at that time.
(FrexxEd was also notable for exposing internal buffers as files in a special filesystem, so you could e.g. lint or compile or call your revision control - limited as they were - directly on the buffers without any custom integration)
The easiest optimization strategy is just to load it all up into the memory. Compare that to other strategy like catching partial file data, and it's obvious why the simpler solution is often chosen.
Another example that comes to mind is vector art vs baked art. You can render nice icons as vector art. Or you could ship perfect baked icons for all possible size variations. There are clear trade-offs here. One of them wastes more CPU cycles, and another one wastes storage space and download time.
My computer could be way faster but it's fast enough that I don't care to remove from autostart the software that doesn't need to be there.
I think that's the reason of software not keeping the pace with hardware in terms of speed. It's just fast enough and if you make it faster people just pile up stuff to make it as slow as tolerable for them.
If you ignore the tiger, the object containing its affection values will remain null, causing a nullpointer (and crashing the 3D environment) eventually as the text editor tries to check if you fulfilled the requirements for the tiger stripe font you can get if your affection levels with the tiger are high enough.
At the very least they could add a resource (battery especially) usage traffic light.
That said, it would encourage small apps rather than efficient apps.
They’re taking enough heat charging for (what they claim is) the costs of the services they do provide. The absolute hurricane of doom saying that would be sparked by charging for the resources the app uses on the users machine would probably take down the internet for a day or two.
A 2024 Plea for Lean Software
bun for the js runtime
zed for text editors
superhuman for email
Nothing is perfect, but I hope the market starting to value performance will lead product teams to prioritize performance.
The truth is that developers are responsible for developing slow software. Nobody else.
So if your code is slow, take responsibility for your own work and fix it! Learn how to make your code fast. Listen to developers who know how to write fast software (game developers for example). You might learn something.
But most importantly pick architectures that are fast by design. Most popular architectures are not and never will be.
A single modern server is unbelievably powerful and can do an enormous amount of work if you code it well.
~/scratch/wrong$ cat ./index.html
<!doctype html>
<html>
<head>
<script src="otherfile.js"></script>
</head>
<body>
<p>otherfile.js did not run</p>
</body>
</html>
~/scratch/wrong$ cat ./otherfile.js
window.onload = (() => {
document.querySelector("p").textContent = "wrong. (otherfile.js ran)";
});