This is what Microsoft was serving up [1].
This is what NeXT accomplished. [2]
EDIT: OTOH, The Tektronix AI Workstations had already been on sale for a while by that point and had not been all that successful. They ran Smalltalk on top of a UNIX-like OS, not directly on the HW.
Oh, yes, it was tight. But it was eminently usable (including Project and Interface Builder) with 20MB of RAM.
Heck, I think XClock is challenged to run in 20MB today.
I thought some of this was wrong but it turns out the BeBox lore is leaking into my NeXT memories. Wikipedia says it was a 60830@25MHz.
The power of Objective-C?
Sort of. I kind of like objective-C in that it gets more fundamentals right than it gets wrong - better than fucking reimplementing Java and then hoping with years and millions of dollars it will perform acceptably - it’s quite sad given how naive ObjC is at it’s core. But iPhone probably would have been successful even with plain C or C++ with a decent library.
Smartphones and PDAs like Palm and PocketPC arguably did relatively more with much less - (this is not to diminish the UX achievement or advancement of iPhone so please put the pitchforks down).
iPhone OS actually could multitask with jailbreaking, though you quickly discovered the limitations of that amount of RAM.
The power of AOT compiled languages instead of plain interpreter.
Apparently the original Android as it was bought by Google, was planned to use JavaScript, then they pivoted into Java, and it took decades until they got any kind of good AOT/JIT story (starting with Android 5).
On the other hand going with a basic Assembly interpreter for Dalvik, when Nokia and Sony-Ericson already had JIT compilers for Symbian, while claming Android was better, no comments.
Likewise when comparing Symbian Series 60 3rd edition phones with Android.
By the time they ditched the MO-drive as the default, NeXT already had a bad taste in people's mouths, esp. at the introductory price of US$6.5K.
Assuming you mean the 'xclock' binary you'd find in Xorg installations, it seems to use about 8MB of RES memory. But keep in mind that it drags in a bunch of libraries (objdump shows Xaw, Xmu, Xt, X11, Xrender, Xft, xkbfile and the math and C libraries as direct dependencies) and those drag their own (ldd shows 26 libraries) and all of that stuff add to the memory overhead for their own purposes even if at the end xclock didn't use them. Chances are an xclock reimplementation that talked the X11 protocol directly, used only the minimum functionality needed to display the clock lines and was statically linked to some minimal C library without any external dependencies would use much less memory.
Though even that would probably feel as too much memory since a lot of the memory used by a program in a Linux system relies a lot on what is already there - including the hardware and kernel drivers.
(which is also why these articles comparing memory usage between various desktops tend to make zero sense as they measure the entire system memory usage, the largest part of which is outside the control of the desktop environment in the first place and in most cases will vary between different computers even with the same distro)
For being something to brag against, you used XEmacs, I guess. Or X-compiled Emacs, in order to be a "big" accomplishment. UXTerm+Emacs under the CLI was "big", but manageable; the X build (even the Athena or Lucid one) wasn't a light thing at all.
On the other hand, modern OSes do a pretty good job of hiding resource abuse with excellent memory management.
"NeXT meeting strategy"
Or for a bigger overview,
https://news.ycombinator.com/item?id=34449912
However you're right, it is one of the best mixtures from both worlds.
Xerox PARC did port their environments into UNIX, Mesa/Cedar, Interlisp and Smalltalk, but it was already too late to make a difference.
It still kills me that Adobe reneged on their promise of a free Display PostScript license, thus killing Rhapsody and "Yellow Box" for Windows (and it's still hilarious to me that that colour was named for Bill Gate's rude response when asked if Microsoft would develop software for NeXT, "Develop for it? I'll p** on it."
Check his interview on "ADSP: The Podcast",
https://adspthepodcast.com/2021/05/21/Episode-26.html
https://adspthepodcast.com/2021/05/28/Episode-27.html
https://adspthepodcast.com/2021/06/04/Episode-28.html
As for Rhapsody and "Yellow Box" for Windows dying, not sure if it would make a difference, OpenSTEP also did not work out that well, not even for Sun, other than being an influence to Java and Java EE (originally an Objective- C framework).
By the way, my graduation thesis was porting an OpenGL based particle engine from Objective-C/NeXTSTEP into C++/Windows 95, because the university department was getting rid of their Cubes, at this time there were no hopes for NeXT.
The notable NeXT code considerations at Adobe are:
- they lost the source code to Glenn Reid's nifty "TouchType.app" - they couldn't be bothered to revive the NeXT source code for Altsys Virtuoso which Macromedia Freehand was based on
A UNIX ecosystem built on top of Mach.
Both macOS and iOS continue to use a BSD-derived POSIX compatibility layer on top of a Mach microkernel - just like NeXTSTEP did.
Originally it was meant to be the foundation computing layer for a campus full of devices.
I think it gets even better if you integrate Smalltalk and Unix, nee, Plan 9, rather than using one as the foundation. Let's call it "Plan A from Userspace".
Start with a universal hierarchical namespace that subsumes memory, disk, and the network, integrated into the programming language[1]. But then don't do POSIX byte-oriented API, but rather a composable REST-like object-oriented API[2]. Add a variant of pipes/filters that doesn't just extend from bytes to (flat) objects, but can also handle hierarchies and polymorphism efficiently[3]. Combine them all: http://objective.st/Publications/
[1] Polymorphic identifiers: uniform resource access in objective-smalltalk https://dl.acm.org/doi/10.1145/2508168.2508169
[2] Storage Combinators https://dl.acm.org/doi/10.1145/3359591.3359729
[3] Standard object out: streaming objects with polymorphic write streams https://dl.acm.org/doi/10.1145/3359619.3359748?cid=813164912...
You're missing the bit about integrating the two.
This sorta happened at Apple (and IBM and Motorola) with the OpenDoc/Taligent initiatives. With the return of the Jedi however, Master Steve axed OpenDoc at Apple, to much chagrin of those involved.
Some of that hostility became internet famous, I am sure most of you have seen the video from the conference back then.
https://www.youtube.com/watch?v=oeqPrUmVz-o#:~:text=I%20thin....
It is interesting how (in the video) Steve explains the decision: the Smalltalk way doesn't fit into an overall cohesive vision that allows you to serve the majority of people.
I think he got it right. The Mac/Win ways of Apps is the right way to slice and dice these issues. I do use Emacs every day. I do feel the Smalltalk way and I like it. But it's not the "right" way; just not.
The best concepts of integrating a terminal/shell CLI driven environment with a GUI and together with on-the-fly manipulation of ENV variables and objects based on those was actualized by the Amiga. Unfortunately Commodore went bankrupt.
Of course, there’s also the Unix foundation of NeXTstep, which importance cannot be understated, especially during the rise of the Unix workstation in the 1980s and the 1990s. This gave NeXTstep (and later Mac OS X) a user base who could take advantage of PARC-inspired environments while at the same time being able to take advantage of the vast Unix ecosystem.
Yes, the Xerox PARC and Unix philosophies are different and sometimes contradictory. However, it’s impressive how NeXT was able to bridge these worlds; the execution was great, and once again macOS serves as a living legacy.
As an aside, personally I’m curious about an alternative timeline where NeXT decided to go all-in on Smalltalk, building a “Smalltalk OS” with no Unix foundation, similar in philosophy to the Lisp machines of the era. There was certainly research going on in the 1980s to improve the speed of Smalltalk; part of this was continued with the development of Self by David Ungar and other researchers. NeXT probably still would’ve had the same market challenges, and the lack of a Unix foundation may have further hurt adoption. But from a purely technical standpoint a polished Smalltalk desktop would be amazing to see and use.