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.
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.
> Functionality and graphics.
And massive amounts of telemetry.
But now functionality is moving to the cloud, we'll just be stuck with gigabytes for graphics and telemetry.
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?
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 a LOT of memory. Every window is present in RAM even if not being looked at so that when you switch to it you never see it paint.
* Stability. Windows 9x tried to be frugal by keeping a copy of everything in system32. That was called "DLL hell". So the current standard is that the app just packages every framework, so you may have a half dozen copies of Qt easily.
> Do we need GBs instead of MBs for that? Why?
Well, let me look at my AppImage:
3.8 GB total.
2.3 GB of dependencies. 2.1 GB is libnode, 128 MB is Qt Webengine.
1.4 GB application. 126 MB of JavaScript and UI images. The rest is mostly code.
But that the "cost" to do so, isn't what's technically required to improve it. You can achieve all these improvements, solve all these problems, probably without much more resource usage. Or negligible added resource usage.
Therefore my conclusion is that the reason e.g. slack usage x1000 what my old IRC or Jabber cliënt used, isn't technical. It's a deliberate choice made for reasons of budget, time to market or another trade-off.
I'm certain that Slack could build a client that does all what slack does, in a client that's hundred(s) of times snappier, smaller, less CPU and memory using. But probably not with their current pace, budget, team or wages.
That was never not the case.
Jabber makes a big usage of XML, which back in the day was very much seen as overkill. It requires a pretty complex parser, and increases the amount of data considerably.
They could have gone with a much more compact binary protocol with ID/length/value pairs, where there's not even field names, but say, a 16 bit integer where IDs are allocated from a central registry.
Even going back to DOS, you could shrink a program with measures like outputting "Error #5" instead of "File not found", and require the user to look up the code in a manual.
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 Linux too.
For some programs, that hasn't changed. I use OneNote heavily to write some sort of personal info database I always look up when I forget something or need to reproduce a command verbatim quickly. The act of writing it and organizing the data also heavily reinforces my ability to memorize thing in my mind in and of itself too. So I'm quite fond of that little program.
When I tried to use it while learning Chinese I ended up having to turn off the spelling/grammar correction. It just can't function with two languages in the same notebook. All the Chinese text had the red squiggly lines warning you of a mistake and I found no way to enable the support for more than one language. You must select /one/ language for the spell checker in that program.
Or disable the spellchecker, which is what I did in the end.
I see that a lot with JavaScript apps. When they replace native, they often fail in details. Where e.g. my native text areas can handle multiple languages when spell checking. But where that diy or spellchuck.js npm version cannot.
For example, if disk space is abundant and very cheap, and optimizing software to use as little as disk space as possible is relatively more expensive than throwing more disk space at the problem, you shouldn't be surprised that software starts using more disk space than necessary, because what's being optimized is software development costs.
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.
There are ways to optimize those things, though, which developers might not be bothering with anymore. The Design Patterns book used a word processor as the example when explaining the flyweight pattern for efficiently representing lots of objects. OLE objects like WordArt support different states[0] and don't necessarily have to be active at all times.
[0] https://learn.microsoft.com/en-us/windows/win32/com/object-s...
Having used that version of Word when it was the latest one, I can say the current ones have quite some added functionality (lots of very tiny things, and a few bigger ones), but I'm totally sure the same could be done with 10x less memory usage if MS would care about it. But there's no incentive to do it. Computers are faster and have lots of memory, and we don't depend on floppy disks any more. It would just cost them more money. Not saying that this is a good thing (I think the opposite, especially that I start thinking that software bloat might have a non-neglectable environmental impact), but as long as nobody complains strong enough (or as long as the EU doesn't come out with an anti-softare-bloat law... seems just a dream but who knows), that wont change. And I can clearly remember I had the same bloat-software feeling when I tried Office 2000 or XP, compared to Office 97, so there's nothing so new here.
As a final note, I've recently seen the source code of MS Word for Windows 1.0 on a GitHub repo (MS released it, see original release on Computer History Museum: https://computerhistory.org/blog/microsoft-word-for-windows-...). It was pure C, with even very large parts of code written in assembly! But the code is really ugly... totally incomparable to current C or C++ coding standards, patterns and language capabilities.
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
Prime example of "Hardware is cheap and inefficiencies be damned"
It only takes longer to use while finding what I want among the bloated set of other things added.
Hah! Good one. It's unfortunate, but true.