[greggman3]

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.

[userbinator]

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.

[arexxbifs]

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.

[arexxbifs]

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.

[userbinator]

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.