Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Plea for Lean Software (1995)

liam-on-linux.dreamwidth.org

Post reply on HN
Print view View original

21–30 of 136 posts

Re: A Plea for Lean Software (1995)

#21

Post by vidarh »

bluetomcat wrote: post #11
hugryhoop wrote: post #5

He 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.

1995 text editors didn't use a "layout engine" that executes JavaScript, attempting to JIT fragments of code. They were an event loop that processes native OS events and responds with repainting areas of the window. They also weren't able to automatically recognise language syntax and didn't have Git integration :-)

One of my favourite editors from the 1990's was FrexxEd, co-authored by the author of Curl, whose main event loop processed Arexx commands and events for every internal command, so you could rebind every event to a script in their own scripting language (FPL; C-like), and access every internal function from it. (It incidentally also came with FPL scripts that provided some degree of syntax highlighting for a few languages, and you could add more, though not as expansive as most modern editors).

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)

Re: A Plea for Lean Software (1995)

#24

Post by monkeydust »

michaelt wrote: post #6

I'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, th…

Depends. In certain fields like trading software, performance is a feature.

Re: A Plea for Lean Software (1995)

#25

Post by dale_glass »

xipix wrote: post #17
dale_glass wrote: post #15

Earlier quoted context omitted.

People drastically underestimate the cost of things we now expect. 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 hu…

That's data size, not code. There's no fundamental reason that a program that can smoothly render unicode at 4k needs a GB download when kB could suffice.

We tried that in the Windows 9x days. We called that "DLL hell".

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.

Re: A Plea for Lean Software (1995)

#26

Post by jillesvangurp »

vidarh wrote: post #16
nox101 wrote: post #10

Earlier quoted context omitted.

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…

None of what you describe requires a lot of resources. Remote editing stubs are decades older than VS code, but also, many of us used X - for many years I did all my work over the network because there was no reason not to. 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 a…

It's a bit theoretical because no editors exist that are smaller that do all of what vs code does. And a lot of what it does relies heavily on the notion that it's running in a browser. So, just tossing that out won't fly since you kind of need it for at least some of the features.

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.

Re: A Plea for Lean Software (1995)

#27

Post by vidarh »

zozbot234 wrote: post #19
vidarh wrote: post #13

Earlier quoted context omitted.

There is waste that is fine, and there's waste that doesn't really come with an upside. 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 diff…

> in "waste" that is fine, I'd categorise AmigaE's choice to read the entire source file into memory, instead of doing IO 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.

Yes, but because it was an issue, even now decades later a lot of compilers still use file IO instead of just reading a file in one go even when you gain benefits (e.g. no "ungetting" or building a token buffer - just keep the index of the start and end). I'm guilty of that myself.

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.

Re: A Plea for Lean Software (1995)

#28

Post by aleph_minus_one »

marginalia_nu wrote: post #12
michaelt wrote: post #6

I'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, th…

There's a lot of overhead and inefficiencies in how large companies do anything. It's hard to organize thousands of people well. It's the social equivalent of the old 'Command-line Tools can be 235x Faster than your Hadoop Cluster'[1] conclusion. 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 up…

> 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).

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".

Re: A Plea for Lean Software (1995)

#29

Post by vidarh »

dale_glass wrote: post #25
xipix wrote: post #17

Earlier quoted context omitted.

That's data size, not code. There's no fundamental reason that a program that can smoothly render unicode at 4k needs a GB download when kB could suffice.

We tried that in the Windows 9x days. We called that "DLL hell". 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 ar…

You presume one option when the other option is a bundled but smaller renderer. The truetype renderer my terminal uses is about 700 lines of code. The C it's a translation of is about 1500. There's a sweet spot that might well be a bit higher to e.g. handle ligatures etc., but the payoff from going from that to some huge monstrosity is very small.

Re: A Plea for Lean Software (1995)

#30

Post by Jensson »

michaelt wrote: post #6

I'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, th…

At Google they argued over microseconds, but there microseconds are money. If every software engineer working on search or ads added 10 microseconds each to load times Google would become unbearably slow extremely quickly and no longer make money.
Post reply on HN