I was always jealous of the stories about programmers in the 80s who wrote games in insanely small amounts of RAM. I kind of want that same kind of challenge needed to be overcome in my lifetime.
Oh and for some reason their language and APIs are OO despite the fairly tight memory limitations, and despite not having any real need to do that (nor enough memory to really take advantage of any OO features even if you wanted to). So you've really got to watch (haha) yourself.
I tell you what, though: having a declarative UI where "declarative" is "now draw text at coords [some coords]. Then draw a square of dimensions [dimensions] at coords [other coords]" is a fucking refreshing break from webdev. Even more so than regular mobile dev. There's simply no room on the devices for much screwing about. You've got your lifecycle methods and some calls that draw things. You can listen for button presses. That's about it as far as the UI goes.
I started learning to code as a kid in the 80s on 8-bit machines. Seemed like there was rapid progress in the availability of CPU power, RAM, etc., up until the early 2000s and then things seemed to... slow down.
Which is about the time everybody started to focus hard on horizontal scalability.
Google Docs isn't the product. It's free. You're the product. And it only needs to be good enough to keep competitors from creating something so great that it removes their first-mover advantage. It's clear that Google has given up developing new features for it.
[ADDED: And as other have mentioned while the collaborative editing of Google Docs doesn't scale all that well, it's a great remote collaboration tool. Never want to go back to sending docs around.]
I actually never much cared for WordPerfect with all its formatting codes and so forth. I was actually a bigger fan of early DOS-based Microsoft Word at the time.
We never went past 64 bits because it's enough bits to address memory for the foreseeable future, and applications needing more are rare. It's mostly cryptography.
My first paid job was in the late 80's. I had to do something about a system that was basically a lot of menus written in Oracle Forms running in terminals on SCO Unix or maybe Xenix.
I was unbearable slow. Users had to wait 5+ seconds every time they pressed a key. And it was a nightmare to try to optimize it. But then I scrapped it and rewrote the whole thing using plain C and curses and system() calls to do the actual work. Hard-coding the menu hierarchy structure which nobody was changing anyway. That made the system very fast. The company was very surprised that navigating menus could be so fast.
Constraint based creativity needed!
Also, you still worry about small amounts at Google scale:
> “It’s pretty slow,” Jeff said. He leaned forward, still relaxed. “So that one was a hundred twenty kilobytes,” Sanjay said, “and it was, like, eight seconds.” “A hundred twenty thousand stack calls,” Jeff said, “not kilobytes.” [...] In a sense, they had been occupied by minutiae. Their code, however, is executed at Google’s scale. The kilobits and microseconds they worry over are multiplied as much as a billionfold in data centers around the world. – https://www.newyorker.com/magazine/2018/12/10/the-friendship...
If you are in a startup where you rather worry about product-market fit, of course such minutiae is not relevant (yet).
P.S. Please don't shoot the messenger, I'm just linking it.