alt Hacker NewsTake a look at what was possible in the late 1980s with 8 MB of RAM: https://infinitemac.org/1989/NeXTStep%201.0
You can run NeXTStep in your browser by clicking above link. A couple of weeks ago you could run Framemaker as well. I was blown away by what Framemaker of the late 1980s could do. Today's Microsoft Word can't hold a candle to Framemaker of the late 1980s!
Edit: Here's how you start FrameMaker:
In Finder go to NextDeveloper > Demos > FrameMaker.app
Then open demo document and browse the pages of the demo document. Prepare to be blown away. You could do that in 1989 with like 64 MB of RAM??
In the last 37 years the industry has gone backwards. Microsoft Word has been stagnant due to no competition for the last few decades.
Replies
That fat thing wouldn't fit on my 360k floppy!
I think back then, due to the scarcity of RAM and HDD, developers, especially elite developers working for Apple/Microsoft/Borland/whatever really went for the last mile to squeeze as much performance as they could -- or, at least they spent way more time on this comparing to modern day developers -- even for the same applications (e.g. some native Windows programs on Win 2000 v.s. the re-written programs on Win 11).
Nowadays businesses simply don't care. They already achieved the feudal-ish bastion they have dreamed about, and there is no "business value" to spend too much time on it, unless ofc if it is something performance related, like A.I. or Supercomputing.
On the other hand, hardware today is 100X more complicated than the NeXTStep/Intel i486 days. Greybeards starting from the 70s/80s can gradually adapt to the complexity, while newcomers simply have to swim or die -- there is no "training" because any training on a toy computer or a toy OS is useless comparing to the massive architecture and complexity we face today.
I don't know. I wish the evolution of hardware is slower, but it's going to get to the point anyway. I recently completed the MIT xv6 labs and thought I was good enough to hack the kernel a bit, so I took another Linux device driver class, and OMG the complexity is unfathomable -- even the Makefile and KBuild stuffs are way way beyond my understanding. But hey, if I started from Linux 0.95, or maybe even Linux 1.0, I'd have much elss trouble to drill into a subsystem, and gradually adapt. That's why I think I need to give myself a year or two of training to scroll back to maybe Linux 0.95, and focus on just a simpler device driver (e.g. keyboard), and read EVERY evolution. There is no other way for commoners like us.
Here's a screenshot of FrameMaker I just took: https://imgur.com/a/CG8kZk8
Look at the fancy page layout that was possible in the late 1980s. Can Word do this today?
There were also
- TeXview.app which at least inspired the award-winning TeXshop.app
- Altsys Virtuoso which became Macromedia Freehand (having been created as a successor to Freehand 3) --- these days one can use Cenon https://cenon.info/ (but it's nowhere near as nice/featureful)
- WriteNow.app --- while this was also a Mac application, the NeXT implementation was my favourite --- WN was probably the last major commercial app written in Assembly (~100,000 lines)
Still sad my NeXT Cube stopped booting up....
Well, ackchyually, the first releases of FrameMaker were created on Sun 3/50 workstations with 4MB of (unexpandable, soldered-in) RAM on a 16Mhz 68020. Most customers had the same model, and could work on modestly-sized documents with ease.
But it's not a lot of space for documents of hundreds of pages, so typical customers who were using FrameMaker to write user manuals for their products had to use "book" files to tie together individually edited chapter files. Then, once in a while you'd have to push the "generate" button on the book to get all the page numbers consistent between chapters, all the cross-references updated, and generate the updated Table Of Contents, Index, etc. You're welcome.
But there's a potential degenerate case where Chapter 1 might have a forward reference to Chapter 2 ("see page 209"), but due to some editing in Chapter 2, the referenced material now on page 210. Well, in some fonts, "209" is wider than "210" (since "1" can be skinny). So, during the Generate operation, the reference becomes "see page 210". But there's some tiny chance that this skinnier text changes the including paragraph to have one less line, so there's some tinier chance that Chapter 1 takes one less page, so Chapter 2 starts one page earlier, and now the referenced material is back on page 209. So now we're in a loop.
This was such an unlikely edge case that nobody else noticed that it even existed, much less that it was detected. I didn't bother with a fancy error message; it would just give a little one-word popup: "Degenerate". Years later, mild panic ensues when a customer calls in, irate that the software is calling them a degenerate. (And it wasn't even a real example, just some other bug that triggered it.)