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

Did we lose our way in making efficient software?

rufatmammadli.medium.com

Post reply on HN
Print view View original

211–220 of 515 posts

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

#211

Post by Animats »

apantel wrote: post #131
claytonwramsey wrote: post #23

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.

The ads are the real content from Medium’s perspective. The article is actually the medium by which the real content is delivered, like a train carrying dark passengers. The article is not what Medium cares about delivering to your browser, but the ads. And delivering the ads requires a lot of complexity.

The article is an ad: "*** provides uptime monitoring and flow-based monitoring for APIs."

This is an important subject, thus it's one for which clickbait is generated.

Size is a problem. I look at my Rust compiles scroll by, and wonder "why is that in there?". I managed to get tokio out, which took some effort. The whole "zbus" system was pulled in because the program asks if the user is in "dark mode". That brought in the "event-listener" system.

Lately, "bash" in a Linux console has become much slower about echoing characters. Did someone stick in spell check, or a LLM for autocomplete, or something?

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

#212

Post by metalspoon »

constantcrying wrote: post #149

Again and again people complain about this. But it remains a fact that essentially nobody actually wants this. Developers certainly like to have their completely integrated, connected and universal computing platform (the web). And users do not seem to particularly care about performance as long as it is good enough . And that is exactly the standard that is set, software is allowed to be so bad that it doesn't reall…

The blog is flawed. 33MB is likely no problem for the web. It's just that Google Docs devs haven't cared about that size probably because hardly anybody creates a huge doc on their platform. Or maybe his dad created a complicated doc file that G Doc failed to parse.

That's different from us devs losing efficiency from our deployment platform.

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

#213

Post by flenserboy »

alerighi wrote: post #64
stephc_int13 wrote: post #20

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…

Think also about all the finished stand-alone applications which have been discarded because of replacement APIs, or because they were written in assembly. We had near-perfect (limited feature-wise from a 3-decade view, of course) word processors, spreadsheets, and single-user databases in the late 80s/early 90s which were, except for many specific use-case additions, complete & only in need of regular maintenance & quality-of-life updates were there a way to keep them current. They were in many cases far better quality & documented than almost any similar applications you can get your hands on today; so many work-years done in parallel, repeated, & lost. If there wouldn't be software sourcing & document interchange issues, it would be tempting to do all my actual office-style work on a virtual mid-90s system & move things over to the host system when printing or sending data.

Addition: consider also how few resources these applications used, & how they, if they were able to run natively on contemporary systems, would have minuscule system demands compared to their present equivalents with only somewhat less capability.

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

#214

Post by skydhash »

trgn wrote: post #198
SkyPuncher wrote: post #171

Earlier quoted context omitted.

Yep. The most successful startup I worked at had a SPA that downloaded 5MB bundle and preloaded a bunch of data. Took nearly 10 seconds to startup. Nobody complained about that. In fact, few people complained about a few portions of the app that had abysmal performance. It often wasn’t until 60 second load times that customers started complaining. They still raved and raved about that software because it solved an ex…

Startup time of an SPA is meaningless when it's for the sort of app you open once in the morning and then use during the rest of the day. It's a single startup-hit, and the user suffers it in between closing the tabs from the previous day and fiddling with some emails. Doesn't matter it is 10-20 seconds. The problem with the long startup is that it tends to cloud any discussion on performance. Code loading and parsin…

Most of my current applications have been opened since the computer booted (11 days ago). Where I'm drawing the line is wasting resources and time while I'm using them. As you said, mostly about user interactions and scrolling because UI is bound to IO for some reason. I remember all the big software taking time to startup (Adobe's, Autodesk's, even Microsoft Office's), but once they do, it was pretty smooth unless you launch that computer/gpu intensive operation. But now, things like Slack causes the computer fan to scream.

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

#215

Post by skydhash »

jwells89 wrote: post #169
constantcrying wrote: post #159

Earlier quoted context omitted.

Certainly there has been almost no pushback. I don't think most users really care for native applications, what they like to see is clicking on something and having it work instantly, web apps deliver that.

I think an overwhelming majority of users aren’t technical enough or well enough versed in UI/UX to be able to put a finger on the frustrations they experience with software, and this is something that’s important to remember when considering complaints coming from a more technically-inclined minority — even if only a small number of techy folks are unhappy, these frustrations likely exist in the larger userbase too…

> I think an overwhelming majority of users aren’t technical enough or well enough versed in UI/UX to be able to put a finger on the frustrations they experience with software

They're ok with it because they don't know it could be better. A spinner every 2 minutes? 12 minutes to open slack? They accept it as fact of life until a better software comes in, and now they're wondering why they haven't come across something like this sooner.

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

#216

Post by metalspoon »

mike_hearn wrote: post #111
vnuge wrote: post #95

Earlier quoted context omitted.

> It was the path of least resistance, so we took it. Well said. I believe many of the "hard" issues in software were not "solved" but worked around. IMO containers are a perfect example. Polyglot application distribution was not solved, it was bypassed with container engines. There are tools to work AROUND this issue, I ship build scrips that install compilers and tools on user's machines if they want but that can't…

It's very platform specific. MacOS has had "containers" since switching to NeXTStep with OS X in 2001. An .app bundle is essentially a container from the software distribution PoV. Windows was late to the party but they have it now with the MSIX system. It's really only Linux where you have to ship a complete copy of the OS (sans kernel) to even reliably boot up a web server. A lot of that is due to coordination prob…

I think flatpak is closer to .app bundles. So, the argument is a little unfair.

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

#217

Post by eternityforest »

nocman wrote: post #163
eternityforest wrote: post #140

We did lose the way, and then we found it again. Not everything has caught up yet but a lot has. Moore's law kept going, and software started getting a little bit faster, which was enough to stop undoing the gains made by hardware, and now things are back to mostly snappy. Occasionally you'll get a 30mb file that's slow... but subjectively things sure seem better than 10 years ago when you couldn't even think about o…

> and now things are back to mostly snappy. This is the inverse of my experience. There are few applications that have a UI that I would refer to as 'snappy'. In fact, I am trying to come up with a single example, and atm I can't even think of one .

All mainstream apps are vast on recent Android phones. Most everything on recent Ubuntu is fast.

Most mobile sites in general are fast, maybe not "2kb of HTML" fast, but fast enough I don't notice or think about performance when browsing.

Although, I suspect a lot of programmers can think faster than average and seem to be bothered more by small delays than the rest of us, since they're able to do things like figure out a Vim keystroke sequence instantly.

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

#218

Post by foresto »

Maxatar wrote: post #204
silverquiet wrote: post #42

Earlier quoted context omitted.

I work at a place that ships an app to both Apple and Microsoft Desktops (we could even do Linux is there was ever any demand for it). We use this old thing called Java which still seems to work. I don't develop it though so I guess I don't have to worry about too much of my resume getting caught up with unfashionable languages (let's face the facts about what most tech these days is trying to advance - promotions -…

Java apps are not native on either macOS or Windows.

Nor Linux.

The only Java desktop app I've ever used (on any platform) without frustration was Slay the Spire, and it only passes because it's a game and doesn't require desktop integration of any kind.

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

#219

Post by vnuge »

snoman wrote: post #202
vnuge wrote: post #104

Earlier quoted context omitted.

I think I would prefer 2005 web again. I'd probably be able to see more of the internet. I use heavy DNS filtering, no javascript on untrusted sites, no cookies, no fonts, VPN and so on. With cloudflare blocking me I basically can't see the majority of websites.

Oh don’t worry. Once dns-over-https becomes standard, you won’t be able to do any dns filtering anymore.

Why not? I can still mitm DOH now? I try to use DOH for everything I have. I did recently switch to self hosted recursive resolution.

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

#220

Post by skydhash »

goalieca wrote: post #128
dale_glass wrote: post #78

Earlier quoted context omitted.

> Let's ask the question differently: what problems were solved? A few more: * Seamless internationalization. If you're a native English speaker you probably never experienced the "fun" of dealing with French and Russian in the same text document. Pre-Unicode supported English + one other language, if that other language wasn't too weird. * Lots of tiny life quality improvements. Eg, not seeing windows repaint costs…

I don’t know about nextstep but macOS had all this stuff when I first used it 20+ years ago. It featured compositing rendering, had the apps, supported ppc/x64 in an app image, had a microkernel. I even remember it got an emulator for running ppc code on an x64. The newest macOS still needs more memory and suffer bloat but 8GB is still perfectly useable if you avoid google chrome. 8GB is also perfectly usable for Lin…

My SO's laptop is an intel MBA with 8GB of ram. Everything's fine until Google Chrome starts (some work tools). Even if the cpu is not as efficient as the m-series, it runs quite well, even with the tropical weather. But launch Chrome and you have a toaster.
Post reply on HN