A Plea for Lean Software (1995)
liam-on-linux.dreamwidth.org
A Plea for Lean Software (1995)
1–10 of 136 posts
Re: A Plea for Lean Software (1995)
#2(1995)
Re: A Plea for Lean Software (1995)
#3(1995)
And a more recent heavily discussed rendition:
A 2024 Plea for Lean Software
Re: A Plea for Lean Software (1995)
#4We need something that dictates how commercial software can be distributed, installed, and what it can automate and do without your consent.
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.
Re: A Plea for Lean Software (1995)
#5He was calling 1995 text editors which used 4 MB of RAM incredibly bloated compared to the lean software of his youth which ran in 32 KB.
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.
Re: A Plea for Lean Software (1995)
#6I've come to suspect the normal way large companies are organised makes performant software almost impossible.
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"
Re: A Plea for Lean Software (1995)
#7He was calling 1995 text editors which used 4 MB of RAM incredibly bloated compared to the lean software of his youth which ran in 32 KB. 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.
>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.
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.
Re: A Plea for Lean Software (1995)
#8Electron entered the chat.
Re: A Plea for Lean Software (1995)
#9He was calling 1995 text editors which used 4 MB of RAM incredibly bloated compared to the lean software of his youth which ran in 32 KB. 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.
>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. 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.
I don't care about memory usage for editors as much I care about input latency and responsiveness.
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.
Re: A Plea for Lean Software (1995)
#10He was calling 1995 text editors which used 4 MB of RAM incredibly bloated compared to the lean software of his youth which ran in 32 KB. 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.
That 1995 text editor didn't handle unicode. Didn't edit all the languages of the world. Didn't handle emoji. Didn't do auto-complete. Didn't replace colors in CSS with their actual color and popup an inline editor to edit them. They didn't edit remotely (editing remotely is not the same as tmux + vim). VSCode not only edits the files. When you're in a terminal on the remote machine and type 'code somefile', somefile opens on your local machine. When you start a web server in the VSCode terminal, VSCode auto forwards it to your local machine.
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.