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

31–40 of 136 posts

Re: A Plea for Lean Software (1995)

#31

Post by bigstrat2003 »

jillesvangurp wrote: post #26
vidarh wrote: post #16

Earlier quoted context omitted.

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 tha…

My time is free. I'm not going to see a dime for any time I save by using this tool or that tool on my computer. Hardware, on the other hand, is not free, so I prefer to sacrifice time for being able to use less expensive hardware (within reason).

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.

Re: A Plea for Lean Software (1995)

#32

Post by fransje26 »

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…

Goodbye, Atom editor..

Re: A Plea for Lean Software (1995)

#33

Post by linkleton »

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…

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

Re: A Plea for Lean Software (1995)

#34

Post by mirekrusin »

lp4vn wrote: post #20
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 tea…

On the bright side remote development means you can work 1-2h per day and make management clapping their hands in happiness.

Re: A Plea for Lean Software (1995)

#36

Post by dale_glass »

vidarh wrote: post #29
dale_glass wrote: post #25

Earlier quoted context omitted.

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.

As somebody who actually works on a pretty large program, no, I'm absolutely not going to use your 700 LOC TTF renderer. I'm going to use the 128K LOC FreeType.

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.

Re: A Plea for Lean Software (1995)

#37

Post by saagarjha »

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…

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

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.

Re: A Plea for Lean Software (1995)

#38

Post by vidarh »

jillesvangurp wrote: post #26
vidarh wrote: post #16

Earlier quoted context omitted.

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 tha…

Next to nothing of what VS code does depends on it running in a browser other than to the extent VS Code has made it so.

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.

Re: A Plea for Lean Software (1995)

#39

Post by saagarjha »

bigstrat2003 wrote: post #31
jillesvangurp wrote: post #26

Earlier quoted context omitted.

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 tha…

My time is free. I'm not going to see a dime for any time I save by using this tool or that tool on my computer. Hardware, on the other hand, is not free, so I prefer to sacrifice time for being able to use less expensive hardware (within reason). 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 s…

If your time is free I think you're devaluing yourself ;)

Re: A Plea for Lean Software (1995)

#40

Post by mirekrusin »

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…

People take holidays, get sick and change jobs - having 1-3 ppl team means you'll hit brick wall that will hurt sooner or later, more so if at least one of devs was really good.
Post reply on HN