Live data from Hacker News

Did we lose our way in making efficient software?

rufatmammadli.medium.com

61–70 of 515 posts

Re: Did we lose our way in making efficient software?

#61

In the early 90s, I believe MS Word came on a few floppy disks and the main executable was 2MB. It ran fine on a 16Mhz 386 with a total of 2MB RAM (let that sink in!) It did pretty much everything it does now, only lacked a grammar checker. (WordPerfect had one.) Now we measure things in GB units. 1000X bigger, but what was gained? We not only lost the way, we don’t even know the destination any more.

Our docker file for running some ML code at work is 6GiB. That does not include the model files. What the fuck, Nvidia? Am I downloading thousands of permutations of generated code for things I’ll never use?

If you look at the build, yea, it includes everything and kitchen sink. No one cares to parse it down because in most cases, the big GPU servers running this have plenty of hard disk space and since it's a long running container image in most cases, the pull time isn't considered big enough problem for most people to fix.

Prime example of "Hardware is cheap and inefficiencies be damned"

Re: Did we lose our way in making efficient software?

#62
post #8

I think about this a lot, and the conclusion I've come to is that the market (simply meaning the popularity) rewards features and intuitive UI above everything else. I think we've been on this trajectory for some time: getting users with less and less actual computer literacy to do more and more with computers.

I do wish fast and responsive UI was included in what’s rewarded

Re: Did we lose our way in making efficient software?

#63
post #5

Yes because we promote blog posts on “idiomatic ruby” and “premature optimization is the root of all evil”. “Performance is less important than dev time”. We used to have developers who took less time and wrote better code.

I dont agree, there is way more help in terms of writing efficient code today than there was back in time, ive seen horrible code from that time which would not have been produced today.

What we don't teach or reward today is the behaviors and engineering process to write high quality code.

A surprising number of inexperienced developers do the following: "once I get any working solution I should immediately open a PR" and let the senior engineers tell them what's wrong with it.

When the big money leaves this field I hope there will be more pressure for people to adopt good engineering practices. I love to work with folks who put good effort into trying to make high quality changes. Personal initiative and ethics are how high quality software gets written.

Re: Did we lose our way in making efficient software?

#64

My opinion about this is that yes, we lost our way, and the reason is very simple, it is because we could. It was the path of least resistance, so we took it. Software has been freeriding on hardware improvements for a few decades, especially on web and desktop apps. Moore's law has been a blessing and a curse. The software you use today was written by people who learned their craft while this free-ride was still ful…

The thing that makes me crazy is that the thing that we do on computers are basically the same each year, yet software are more and more heavy. For example just in 2010 a Linux distribution with a DE just started did consume 100Mb of RAM, an optimized version 60Mb of RAM. I remember it perfectly. I had 2Gb of RAM and did not have even a swap partition.

Now just a decade later, a computer with less than 8Gb of RAM is unusable. A computer with 8Gb of RAM is barely usable. Each new software uses Electron and consumes roughly 1Gb of RAM minimum! Browsers consume a ton of RAM, basically everything consumes an absurd amount of memory.

Not talking about Windows, I don't even know how people can use it. Every time I help my mother with the computer is so slow, and we talk about a recent PC with an i5 and 8Gb of RAM. It takes ages to startup, software takes ages to launch, it takes 1 hour if you need to do updates. How can people use these system and not complain? I would throw my computer out of the window if it takes more than a minute to boot up, even Windows 98 was faster!

Re: Did we lose our way in making efficient software?

#65

In the early 90s, I believe MS Word came on a few floppy disks and the main executable was 2MB. It ran fine on a 16Mhz 386 with a total of 2MB RAM (let that sink in!) It did pretty much everything it does now, only lacked a grammar checker. (WordPerfect had one.) Now we measure things in GB units. 1000X bigger, but what was gained? We not only lost the way, we don’t even know the destination any more.

> Now we measure things in GB units. 1000X bigger, but what was gained? Functionality and graphics. For instance 'dict.words' alone on Linux is 4.8MB. Arial Unicode is a 20MB-ish font. The icon for an application I work on is 400K. The Google Crashpad handler for handling crashes is somewhere around several MB. A 4K true color display is 138 times larger than 640x480x16 colors.

Let's ask the question differently: what problems were solved?

With your examples, it could be:

- introduce global spell checker.

- have emoji?

- fix blurry icons?

- being able to search through crash logs?

- not having to switch between windows.

Do we need GBs instead of MBs for that? Why? Was that problem not fixed already? Could we not fix it in a way that didn't demand magnitudes more resources?

I'm asking, because I highly doubt that there's a technical reason that requires an improved piece of software or a solved problem,to require magnitudes more resources.

Sure, slack is far superior in UX to IRC. But could we really not get that UX without bloatware hogging my CPU, taking hundreds of MBs installation size and often biting off significant chunks of my memory? Is that truly, technically impossible?

Re: Did we lose our way in making efficient software?

#66

In the early 90s, I believe MS Word came on a few floppy disks and the main executable was 2MB. It ran fine on a 16Mhz 386 with a total of 2MB RAM (let that sink in!) It did pretty much everything it does now, only lacked a grammar checker. (WordPerfect had one.) Now we measure things in GB units. 1000X bigger, but what was gained? We not only lost the way, we don’t even know the destination any more.

A while ago someone dropped off an old PowerBook Duo for disposal - I had to fire up Word 5.1 just for nostalgia reasons

I saw it described once that software is like a gas - it expanded to take up the space we now have

You see it with live distros too. They used to be 700MB to fit on a CD-R, but now it's getting rare to find one that'll fit on a 2GB USB; although yay for 'minimal' gaining ground

Re: Did we lose our way in making efficient software?

#67

In the early 90s, I believe MS Word came on a few floppy disks and the main executable was 2MB. It ran fine on a 16Mhz 386 with a total of 2MB RAM (let that sink in!) It did pretty much everything it does now, only lacked a grammar checker. (WordPerfect had one.) Now we measure things in GB units. 1000X bigger, but what was gained? We not only lost the way, we don’t even know the destination any more.

> Now we measure things in GB units. 1000X bigger, but what was gained? Functionality and graphics. For instance 'dict.words' alone on Linux is 4.8MB. Arial Unicode is a 20MB-ish font. The icon for an application I work on is 400K. The Google Crashpad handler for handling crashes is somewhere around several MB. A 4K true color display is 138 times larger than 640x480x16 colors.

While plenty of software is overly fat, you hit the nail on the head.

A Word document isn't just text and some formatting sigils. Editing isn't just appending bytes to the end of a file descriptor.

It's a huge memory structure that has to hold an edit history so undo and track changes works, the spelling and grammar checker needs to live entirely in RAM since it runs in realtime as you edit, and the application itself has thousands of not millions of allocated objects for everything from UI elements to WordArt. The rendering engine needs to potentially hold a dozen fonts in memory for not just the system but any specified but not immediately used fonts from the base document template.

It's not like Google Docs is any lighter on RAM than Word. Features require memory. Fast features are usually going to require more memory.

People can use AbiWord if they want a much slimmer word processor. They could also just use nano and Markdown if they wanted even slimmer. But a lot of people want document sharing over the Internet with track changes, grammar checking, and the ability to drag in and edit an Excel spreadsheet.

The features used in native software follow a bathtub curve. But not just one but several. No two groups necessarily use the same sets of advanced/uncommon features.

Re: Did we lose our way in making efficient software?

#68
I wonder if it's the big software vendors who have lost their way, rather than the average software developer. We have companies like Microsoft and Adobe moving to Web based applications not because they are better but because it's easier for them to enforce licensing restrictions and push people into subscriptions. As the various App stores erode the profits of software developers any tool that will make it faster to add features, even if they are buggy, becomes compelling.

Re: Did we lose our way in making efficient software?

#69

There is perhaps some irony in the fact that this blog was posted to Medium, which serves 10.88 MB for a 265-word article.

And browsers are larger that some operating systems. And talk about a closed off ecosystem ... WASM is still crippled and JS/HTML/CSS is your only real viable option for web development.

The web feels like 2005 again. Only thing is, this time the popups are embedded in the page...

Re: Did we lose our way in making efficient software?

#70

We recently moved an old page from plain html and everything generates by the backend to react and we had a drop down take several seconds to open with a thousand or so items in it. Was like 100ms to open the entire page before. It was suggested to only display the first 100 items and let the user type in 3 characters until it started rendering. Unfortunately this is the reality for many these days. Of course instead…

Yup. Common. With all the performance blogs focused on time to first paint and the like, React introduced a whole new category that looks a lot like this
Post reply on HN