Hacker News Reader

Comment by sneak | Hacker News Reader

The overton window of "acceptable program size" has shifted so many times as technology advances, surely you can recognize that your own personal attachments to a given SI suffix are irrelevant?

Our ancestors would argue that a 1MB application was bloated. Our children will complain about 1000GB bundles.

The programs, of course, do vastly different things as the realm of what is possible with technology inexorably advances.

Comparing a complete bundle for an advanced graphical application framework with a TUI application is apples to oranges, and the curmudgeons who are shaking their collective canes at the kids on their lawn are actually technically competent and can recognize this if they choose.

There are legitimate technical criticisms to doing things with JS and Electron and whatnot; but "the bundle is hundreds of megabytes" isn't that.

View on HN

This attitude is exactly why Wirth's law is a thing - software is getting slower, faster than hardware is getting faster. That is not in all metrics, of course, but in some - like typically in response latency to user inputs.

This slowness costs users so many hairs pulled out. Programmers who think that "this is acceptable" lack the awareness that they haven't even tested the software under only slightly unusual conditions which is when everything is already crawling to a halt.

When that "bundle" is 1000MB while technically there is no reason it should be more than ~1MB, many operations that you might want to do as a developer / trying-outer of the bundle take 1000x longer (no shit). Not unlikely, in some cases that even applies to runtime performance.

Why in the world would you accept that when it takes only a little discipline to get it down to a "reasonable" overhead of say, 10x???

Alacrity would like a word. In my experience, software is generally getting faster these days, after a period of UI latencies getting worse for a while.

Not all software is getting slower faster than hardware is getting faster.

It has always been possible to write slow software.

Or consider that the startup time of OSes still hasn't changed much. It was much faster for a while when SSDs came around, and Windows generally has become faster with their not-quite-shut-down technique. But normal bootups, around 30-60 secs on normal machines, 25 years ago and still now.

And the important point is: it _is_ annoying, an actual bootup in 5 seconds is easily possible from a technical perspective, and would much improve the user experience.

Take systemd, I remember it brought a lot of startup time improvements for a while, or at least promised them. I don't follow Linux very much these days, but when I do a standard installation of a popular distro - sloooow startup. Last I looked I had an issue with tons of virtual serial devices created serially, took probably 10 seconds alone.

Parkinson's law at work.

It's funny, while I've never tried Alacritty (and I'm not likely given the posts I'm reading about it around here), I'm still stuck with xterm, which in some ways has a terrible UX. But it's the fastest I've used, has the most correct VT-100 emulation (or at least programs do work), and it has by far the crispest fonts - if you're using bitmap fonts, which most modern terminals don't support anymore.

But to your actual point, of course you can write software that runs not slower, or even runs much faster, than the software of 30 years ago that ran on machines of the time. The exception proves the rule (while I feel it's always been so obvious that there was never a proof needed).

Also, Casey Muratori would like to have a word. https://www.youtube.com/watch?v=GC-0tCy4P1U

> Our ancestors would argue that a 1MB application was bloated.

And no one listened, so now -- despite our computers being thousands of times faster -- basic applications are hundreds of times slower to open. And we're junking a bunch of "old" machines that are considered too slow even though they're technically capable of performing rapid operations at levels our brains can barely comprehend.

Just because that window shifts over time doesn't mean that we need to push our boundaries for acceptable program size, nor is it an excuse not to optimize our software. This kind of mindset is how we end up with terminal emulators that take more than 500ms to launch, and how we end up with systems that take on unconscionable amounts of bloat. I use Konsole as my terminal, which is a 50kb binary. If your replacement is orders of magnitude larger than my current option, it had better brew my coffee and have bacon ready by the time I wake up every morning. Instead, all we got was a lousy authy sync.

Konsole is not actually 50kb, you need to include the libraries it imports to do an apples to apples comparison. What is going on here is tabby is the equivalent of statically linked + a virtual machine OS called a browser, while konsole is not. To properly compare the two, you need to compare source code size, as if you downloaded tabby and ran it an browser. To really compare them properly, you'd also need to make the typescript compiled into equivalent JS VM assembly. There you'll find them probably to be significantly closer in size

>Konsole is not actually 50kb, you need to include the libraries it imports to do an apples to apples comparison.

No, we really don't, because these libraries are available to other programs as well, whereas a huge packaged application is availabe to nothing than itself.

Konsole itself could probably be considered bloated. You can easily write a super functional and performant terminal emulator in 50-100K by only using the external dependencies that are absolutely required - i.e. on Linux, the POSIX/Linux syscall interface and Xlib. You shouldn't even need libc, but AFAIK on Linux it's extremely hard to not use it, for stupid reasons.

> To really compare them properly, you'd also need to make the typescript compiled into equivalent JS VM assembly.

That's like saying, to compare Usain Bolt and myself in terms of sprinting performance, you should consider the fact that I'm chubby for a fair comparison.

http://st.suckless.org

More text? :-)

(I know of the suckless community and of st in particular (I've never tried it)).

Correct, shipping the equivalent of an entire full-featured GUI OS just to provide a terminal emulator is crazy.

Sharing libraries with other apps is a feature.

See, this is what I mean by a legitimate criticism. I agree that a new version of a critical tool like this should do a bit more than have tabs and sync.

"It is 250MB" alone isn't.

>Our children will complain about 1000GB bundles.

Our children will still complain about a 10MB application, if it does something that could be done by a 500KB solution.

>Comparing a complete bundle for an advanced graphical application framework with a TUI application is apples to oranges,

And what do I need a "advanced graphical application framework" for if the intended use case is displaying text in a grid?

> Our ancestors would argue that a 1MB application was bloated.

They still do, thank you very much.

Reply on news.ycombinator.com