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

11–20 of 136 posts

Re: A Plea for Lean Software (1995)

#11

Post by bluetomcat »

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

Re: A Plea for Lean Software (1995)

#12

Post by marginalia_nu »

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

Re: A Plea for Lean Software (1995)

#13

Post by vidarh »

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.

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

Re: A Plea for Lean Software (1995)

#14

Post by zozbot234 »

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

CSS grid exists now, so it should be easy enough to achieve the same "repaint small areas of the window, don't do global layout" workflow in a web-based app.

Re: A Plea for Lean Software (1995)

#15

Post by dale_glass »

nox101 wrote: post #10
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.

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…

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

Re: A Plea for Lean Software (1995)

#16

Post by vidarh »

nox101 wrote: post #10
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.

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

Re: A Plea for Lean Software (1995)

#17

Post by xipix »

dale_glass wrote: post #15
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…

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.

Re: A Plea for Lean Software (1995)

#18

Post by ozim »

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…

Fun part in context of big corporations is when performance becomes awful business will call in some guys from outside because clearly people currently working don’t know how to make it perform better.

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…

Re: A Plea for Lean Software (1995)

#19

Post by zozbot234 »

vidarh wrote: post #13
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.

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.

Re: A Plea for Lean Software (1995)

#20

Post by lp4vn »

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…

Development in any corp today, even middle-sized ones, is a big red tape festival. You have a project divided in sprints that are divided in (often meaningless) tasks, then you have a completely bloated CI/CD system and then things get deployed to three or four environments where people pretend to test everything. Things that might be developed by a journeyman developer in five days take six weeks to be done by a team of eight developers.

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.

Post reply on HN