The technology really was great. Their understanding of object orientation was superior. The developer tools were wonderful. The user experience was generally a delight. We could develop custom software in a fraction of the time of people using the tools of the day. NeXT had a true vision of the future.
However, what they didn't have was much understanding of economics. The only reason that NeXT wasn't a complete commercial failure was that Apple's board wanted Steve Jobs back. If not, Apple might instead have bought out Be. And if Apple had succeeded in developing their own next-gen OS, both NeXT and Be might be minor footnotes these days. Even prior to the deus ex machina buyout, NeXT was on a slow and steady path to failure. They'd gone from an integrated hardware vendor to an OS-on-other-hardware vendor to a dev-tools-on-other-OSes vendor, and it's not clear that would have worked either. Once the acquisition was announced, they promised to take care of the people who had stuck with them and then did jack.
I took a few lessons away from my time with NeXT. 1) Just because I thought something was technically superior didn't mean it was commercially viable. 2) Being too far ahead of the market is worse than being behind it. 3) Never trust a "visionary leader" to look out for you, no matter what he says. He's in it for himself and the vision; the little people are expendable.
But you're definitely right that it made using other stuff painful. I stopped doing GUI development altogether rather than shift to Windows, which was incomparably awful by comparison.
Thanks for sharing though!
I suppose it may be that technical excellence has never been economically viable, and NeXT survived as long as it did only by fluke.
I suppose it may be that technical excellence
has never been economically viable
1. It's generally orthogonal to economic viability
2. ...unless you have such a lack of technical excellence that it actively sinks the company because you can't execute at all
I think Google search would like to have a word with you.
You can have the best product on the market and fail, and you can have a terrible one, yet succeed. Google has as much business acumen as they do technical chops, and that's why they are such a success. Same with MS and Apple.
Edit: I guess if we want to limit it to cool technologies that are directly monetizable, the ford motor company of the early 20th century (or maybe Tesla) is a better example? It's just as silly a statement either way.
There is a ton of shit software out there that makes buckets of money, and lots of well designed, well executed products never make it off the ground. So you can't just focus on good engineering and expect clients to line up out there door.
All the vision and all the software quality in the world won't make you competitive in the 90s UNIX workstation market if your machines are underpowered, and we were used to garbage software anyway. Chasing the "personal workstation"/PC market also would never work. DOS/Windows was far too strong and the Macintosh deep in a niche. It's very unfortunate.
I looked very seriously at Unix machines around the time NeXT came out, having been converted to that religion in college. NeXT started at around US$6500, and that was with the optical disk only. The equivalent-ish Sun box (Sun 3/80) started at around US$15k with disk as I recall and went up in price really fast if you wanted more memory/disk/etc. About the cost of a new Honda Accord at the time. And the Sparcstations were out at much higher performance (and price...I seem to recall around US$22k for a usable config).
On the other hand, you could get a nicely decked out 386/33 for maybe half the cost of the NeXT, or a 486 for a grand or so more. And it ran tons of software, even if it was garbage. Even Unix.
1st NeXT Computer 1988: Motorola 68030/25Mhz w/68882 FPU, 64MB RAM max. MIPS: 4
Sun Workstation 1988 Sun-4 line: Spac @ 16-33Mhz, 32-768MB RAM MIPS: 7-114
Now having used both, the desktop and usability on the NeXT was so much better.
You could buy a NeXTstation for $4995 on the open market, and considerably less with an educational discount.
You could buy a Sun Sparcstation 1, which was released a bit earlier and ran a RISC 20 MHz processor but it was $9,000.
If I recall correctly, SGI workstations like the SGI Indigo at the time started at somewhere around $7500 and depending on configuration could be nearly $40k. The SGI Indy, which was the low end SGI machine, was faster and priced at an identical $4995 - but it wasn’t released until mid 1993.
The first Macs to use the 68040 weren’t released until mid 1992. And they also cost $7,000+.
I am unaware of a machine that was available in 1990 for under $5,000 that had more horsepower. If you can point me to one I’ll gladly concede. But at the time I was actually a NeXT campus consultant, which meant I was selling them and knew the specs of both the NeXT products and the major competitors, and I’m not aware of one. Certainly by 1992 the Mac and high end PCs were catching up, albeit both with vastly inferior operating systems.
That was a long time ago and I could well be wrong. But if so I want to see evidence.
I'm pretty sure Sun offered huge academic discounts. I never saw NeXT at any of the local universities... It was mostly Sun and DEC.
But the comparable machines of the time like the Mac IIfx or the Sun boxes of the time had similar or higher prices.
The NeXT hardware was never really competitive in either market except certain niches. E.g., all our clients were in financial trading, because they were willing to pay a huge premium for rapid app development for financial traders.
What NeXT brought was a GUI editor that allowed you to drag a button from a palette and onto a window (or view). You could then change the text on the button by double clicking on it and renaming the default text. You also got to determine where and how large the button was in relation to the rest of the window.
Most GUI builders could do this, so what was special about Interface Builder?
Two things stood out. First, you could specify how the button reacted to window resizing. There was a “springs and struts” layout mechanism that allowed you to say which parts were fixed offsets and which were variable. You could also say if the button would resize, and if so, in the X or Y or both directions.
The second thing was the ability to connect the button to an action. By Ctrl clicking and dragging, you could wire up the default action to a “selector” — in effect, a virtual method call, on the owner of the button. This owner would be populated at startup, typically the application (controller). So you could have your code with the responder and another team build the UI, and they would join together at runtime.
You could also use properties generated by code as well - you could connect the button’s field to an object’s property (aka an outlet) so that changing the code changed the UI.
The fact that you could drag and drop connections from UI to code, and from code to UI, as well as building a responsive UI, was really what stood out.
This still lives on in Xcode today; IB and PB begat Xcode and IB which begat Xcode. The “nib” format - Next Interface Builder - was a binary format file containing the descriptive state of the Ui and the wiring requirements, which was renamed “xib” when XML became all the rage is the same thing. The fact that IB has been subsumed into Xcode still hides the fact that is what’s happening under the covers.
I think it’s important to realise that this was in an age when Windows 3.1 was all the rage, and we had only just got out of 256 colour VGA while Next station had 16 million.
Nowadays with everyone doing MVC programming with the web, it doesn’t seem so important. But then there was a time when no one wrote unit tests because it was seen as pointless; but it is from these seeds that ideas become mainstream.
[1] https://paulhammant.com/2013/03/28/interface-builders-altern...
I can't remember where I read this, but the basic notion was that the Mac was easy to use but hard to program, limiting its adoption. Jobs learned a lesson in that he wanted his NeXT machine to be easy to use and easy to program.
As you say, it might all seem a bit tatty now. The web has raised the game of interface creation quite a bit. But this was in the late 1980s, where a lot of what they did was revolutionary.
Unfortunately I can’t go back and edit the original post to fix. Thanks for correcting me!
https://en.wikipedia.org/wiki/History_of_Delphi_(software)
Visual Basic came out in 1991, by which time Nextstep was already at version 2.1
So yes, these things existed, but after Next had demonstrated them.
And having dealt with GUI builders with special formats and coding implication related to objects sending special events, I'd much rather just write plain code in one language in a text editor than wrestle with a limited WYSIWYG tool.
Mithril's brilliance is assuming the UI is dirty if you have touched it in some way (mouse click, keystroke, etc.) and always rerendering after the event is handled (except if you want to optimize that). That leads to UI code which is much easier to reason about than arbitrary networks of dependencies like older UI toolkits emphasized. That style of UI development feels a lot more like, say, programming a continually-rerendering video game in for OpenGL than programming a dependency-based UI for VisualWorks/NeXTSTEP/Delphi/VB/etc..
More on all that by me: https://github.com/pdfernhout/choose-mithril "tl;dr: Choose Mithril whenever you can for JavaScript UI development because Mithril is overall easier to use, understand, debug, refactor, and maintain than most other JavaScript-based UI systems. That ease of use is due to Mithril's design emphasis on appropriate simplicity – including by leveraging the power of JavaScript to define UIs instead of using an adhoc templating system. Mithril helps you focus on the essential complexity of UI development instead of making you struggle with the accidental complexity introduced by problematically-designed tools. Many popular tools emphasize ease-of-use through looking familiar in a few narrow situations instead of emphasizing overall end-to-end simplicity which -- after a short learning curve for Mithril -- leads to greater overall ease-of-use in most situations."
And I say that even having been an official NeXTSTEP developer once upon a time -- after I gave Steve Jobs my business card when I met him after he gave a talk at Princeton and he got me into the developer program (after my paperwork to join that developer program had previously apparently been ignored with its aspiration to build a system where any piece of data could be linked to any other piece of data). Even reading through all the glorious NeXT developer info, I never felt I could afford the NeXT hardware though as much as I wanted it (the short warranty gave me pause too) -- so my career as an independent software developer went in different directions. After reading the article and comments here, I can wish I had just thought to go work for NeXT instead of wanting to be a customer...
After watching DHH's video and reading the Rails book, it reminded me so much of my previous experience with NeXT technology that I had no other choice but to go with Rails.
The dynamism of Ruby had a lot in common with ObjC's runtime. And reading about ActiveRecord at that time I also had the feeling that its authors had worked with EOF before.
All in all, NeXT built great stuff. I still own a NeXTstation Color that I got in 1992 (one of these days I should try to turn it on again). And it's a testament to the quality of that software that some pieces that I'm still running today, like Apple Mail, trace back almost directly to tools I started using back then (NeXTMail).
I think it's because both of them were so influenced by smalltalk, more than ObjC influencing ruby necessarily. But not sure.
But I'm still very curious if AR's creators knew EOF, yeah. I haven't found DHH mentioning it; not sure if there might be forgotten other person/people central to original AR architecture.
WebObjects itself was nice in many many ways (I think it's encapsulation of form handling is far better than anything anyone's managed in Rails)... but made a fundamental mistake in trying to keep a fundamentally stateful architecture and apply it to the web by putting what was effectively an opaque state ID in every single URL. This was a basically bad design for the web (although also provided for forementioned good encapsulation of form handling. :) ).
But yeah, the sense I get in my career is that we spend a lot of time trying to reinvent something that already existed, and getting close to being as good as it... then collectively moving on to the next language/platform and doing it again. With not a lot of progress. Up to and through the 90s, it seemed like there was actual progress in software design and architecture at the high-level, the level of affordances for developers to efficiently create reliable maintainable software, but it seems to me have stalled -- perhaps in favor of huge advances in more low-level stuff, better/different languages/language paradigms, etc.
The closest I got to experience inner workings of NeXT software is observing the boot log of Mac OS (which you can see if you boot it with Qemu/Clover). I haven't seen so many triple exclamation marks in a while. That somehow didn't leave the impression of carefully and intentionally designed software.
In any event, the boot log is not something I had occasion to pay attention to in NeXTStep, I couldn't speak to it.
During my Software Engineering degree I learned the difference between a Library and a Framework, but it wasn't until actually using the WebObjects Framework that the light bulb went off in my head. It was a pleasure to work with, and clearly very, VERY well thought out.
EOF was great, and every time I made a new NSArray() it brought a smile to my face.
> Since the transition of WebObjects to Java in 2000, the functionality of many of Apple's Java Foundation classes is replicated in Sun's own JDK. However, they persist largely for reasons of backwards-compatibility and developers are free to use whichever frameworks they prefer.
Doesn't stop tons of people from hating it :)
If it is Entity Framework Core, then what swayed you about it over other ORM's you experienced?
But what I want to talk about instead is:
> Like EOF, our database layer that still puts Ruby-on-Rails to shame.
I spent a couple years programming with EOF (the "Enteprise Object Framework", an ORM), and many more recent years programming with ActiveRecord. EOF had a few features that ActiveRecord still doesn't that I miss (like properly functioning multi-table inheritance; and lazy "eager loading" triggered on first access for all associations; Rails 6.1 has a welcome feature to RAISE on n+1 behavior, but why not just lazily trigger the efficient load instead, which is probably no harder to implement? Maybe nobody thought of it, having not used EOF?).
But I wouldn't actually say it still puts ActiveRecord "to shame". ActiveRecord is very similar to EOF in design, by 2020 nearly as mature, with 80-90% of the features.
Yeah, it's striking that ~20 years later we can say AR is mostly as good as EOF haha (and doesn't have anything of note that EOF didn't already have, it hasnt' superceded it in any ways). It's internal architecture isn't quite as elegant. But it really is nearly as good as EOF, it's deficiencies compared to EOF aren't large enough to be particularly shameful, in my experience/opinion, it's in the ballpark!
AR is so similar to EOF that I have always wondered if some of it's designers had experience with EOF.