Hacker News Reader

Comment by arexxbifs | Hacker News Reader

> About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage.

That would be in 1970, but my guess is that "ed" would be a hard sell today.

There is plenty of bloat to go around these days and I think we could do a lot more to address that. But we've all got too much skin in the web game to own up to the embarrassing fact that a chat program that's basically IRC with pictures feels like glue on a 2.4 GHz, multi-core CPU.

With that out of the way, we shouldn't get silly, either. Every actually useful feature added will increase complexity and resource usage. I like split-window, code-folding, auto-indented, word-completing, syntax highlighted multiple document editing more than I like saving a few fractions of a percent of my hard drive space.

View on HN

That text editor quote really bugs me. Sure my Atari 800 had a word processor that came on a 8k cartridge. I couldn't type Chinese, Japanese, Korean, Russian, Arabic into. I could only type ASCII. Just the ability to do that alone would likely entail many many megabytes of code.

For one, there is no text based system like those old machines that handles all that so I have to switch to graphics. Just the font alone for all of those languages will be multi-mega bytes and I'll need multi-megabytes more for space to rasterize some portion of those fonts. Rasterising just 4 or 5 glyphs is more work than that entire 8k word processor had to do on its 40x24 text screen.

Then for each language I'll need multi-megabytes for handling the input methods. The input methods are complex and will likely need a windowing system to display their various options and UX so add more code for that.

The point being that we need the complexity. That 8k editor wasn't useful in the same sense as our stuff today. I don't know a good analogy. It's like complaining that people use CNC machines today and at one point got by with a hammer and chisel. I'm not going back.

Just the ability to do that alone would likely entail many many megabytes of code.

Just the font alone for all of those languages will be multi-mega bytes and I'll need multi-megabytes more for space to rasterize some portion of those fonts.

Then for each language I'll need multi-megabytes for handling the input methods.

Those statements clearly show your lack of awareness of what things were really like 40 years ago. They had CJK input and output(https://en.wikipedia.org/wiki/Cangjie_input_method was invented in 1976, for example) on the systems of the time, and that certainly did not entail "megabytes of code".

What it did entail, however, was a certain amount of skill, creativity, and an appreciation for efficiency and detail that lead to being able to do it with the hardware of the time, skills which are unfortunately a rarity today. Instead, we are drowning in a sea of programmers who think the simplest of tasks somehow requires orders of magnitude more resources than were available decades ago, when the reality is that there existed software at the time able to do those tasks perfectly well and at a decent speed.

The point being that we need the complexity.

The point is precisely that we don't.

While parent's "many many megabytes" might be an overstatement, today's editors are expected to display any number of languages and alphabets simultaneously, using user-configurable, scalable, variable-width fonts that render in a variety of different resolutions with sub-pixel smoothing. Things like that add to the complexity of both the OS and the application itself.

I think actual bloat is better measured by comparing the size and speed of a program with a few of its previous versions and look at the number of new features. Outlook strikes me as a suitable candidate: I can't think of anyone using it any differently today than say 10 years ago.

I even think comparing with something that is 20 years old today is more interesting than comparing a 1995 IDE to a line editor written for teletypes.

Outlook strikes me as a suitable candidate

The web version of Outlook is a great example --- on a computer only a year old, it often lags on every keypress when writing an email.

YouTube's redesign ("Polymer") is another example, where the new site is much slower than before, despite not really increasing in features.

> more than I like saving a few fractions of a percent of my hard drive space.

Hard disk space is seldom the actual issue. Instead, it's bandwidth used (too expensive to download over a mobile connection, or maybe not even feasible to download over a low-quality connection), or memory requirements (can't reliably use slack + spreadsheet + photoshop at the same time), or power consumption (laptop out of battery in 1 hour).

Do you like split-window, code-folding, etc etc so much that you can't download it while traveling in a rural area, have to close it so you can run Photoshop, and have to carry a spare battery so you can use it for the entirety of a 3-hour plane ride?

> bandwidth

Why would I download a text editor every time I wanted to use it? Even VS Code is stored locally, ready to be used off-line. But let's not pick an Electron app for _everything_ we want to do: last time I checked, Notepad++ does all of what I listed, and more.

> memory requirements

Yes, this can be a problem and is a sure sign of bloat. Meanwhile, I think we're bad at picking our software: why do we just sit back and accept stuff like this? I've got 8 gigs of RAM in my dirt cheap home laptop and I can run Gimp, GNumeric, Firefox and watch a movie at the same time just fine, with plenty of RAM left to spare. For professional use, requirements are and have always been higher: hence the $15k workstations of yesteryear.

I think we're doing a bad job at promoting that the use of native software would likely have the outcome of higher productivity and lower hardware costs, because that would probably mean we're putting our own cushy web coding jobs on the line, too.

> battery life

There are still some hard limits we have to take into account. Even if I for some reason did have to work with both programming and Photoshop on a 3 hour plane ride (I luckily do not), I don't think the answer to my problems would be to switch to "ed".

>> bandwidth

>Why would I download a text editor every time I wanted to use it?

To give a serious answer: The web is literally that. And I suspect the success of the web is in a major way due to Windows' lack of streamlined package manager, as the installation ("loading") of a webpage is about a second, whereas the install time of an average Windows program involved potentially several minutes and clicking "next" several times.

Fast install times helps with discoverability - if you can click a link and "install" a browser in under a second, it becomes pretty trivial to try out ten browsers in under two minutes and encourages experimenting. Plus, you'll have reasonable expectation that you won't have to spend time cleaning up the cruft left by unwanted IDEs you don't plan to use.

Also, the install time issue also applies to updates. Web pages mostly don't have an "updating..." loading popup like e.g. Steam has every time there's an update.

Note: I am NOT advocating we all switch to web browsers. I AM advocating that we try to make our package managers a couple of orders of magnitude faster.

I am very seldom in a situation where I must download my IDE while traveling in a rural area, run it with Photoshop simultaneously, or use it for the entirety of a 3-hour plane ride.

While multi-hundred-megabyte text editors consuming double digit CPU to render some text are definitely a sign of inefficiencies _somewhere_, I value any marginal productivity benefits from these additional features over (possibly significant!) usability in very resource constrained situations.

Maybe ed would be a difficult sell today, but vi came out in 1976, the essence of which is still in use.

What we'd recognize as vi was first called "ex" - and since it was more featureful than ed, it was also a larger program [0]

The essence of BSD is also still in use, but I'm willing to bet that once this essence - much like that of ex - has been expanded into something we'd consider a capable system today, it's also going to require a lot more resources.

[0] https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/ex/RE...

Reply on news.ycombinator.com