One of the things that really disappoints me about computing is how GUI development is such a horrid treadmill of constant reinvention and total reboots with no overall cumulative progress. The Web is just now reinventing things with React and components that were perfected in several different desktop systems at different times. Something about UI development makes long term reuse and depth building impossible.
I think one factor is that good UI and UX is nearly always proprietary, so these great platforms get built but then ultimately die when the market moves on.
There's nothing dead about this UI platform. It got a new theme in 2001 and is still going strong today. The colors have shifted over the years and the scroll bars switched sides and have mostly faded away, but it only takes a glance at the code to see that it's the same platform at heart.
You no longer have window-independent focus. You cannot bind hotkeys to windowing events. You cannot toggle through all windows via alt-tab, you can't set focus-follows-mouse.
Source: I've been use WindowMaker (a NeXTstep clone) for 20 years.
I really don't see how some tweaks to window manager behavior to make it more accessible to Mac and Windows users are more fundamental and massive than the aforementioned change to scrollbar behavior to make it more accessible to Mac and Windows users. They were all noticeable, for sure, but from a technological perspective they were all quite minor.
Plus, I'm not sure how many of the things you mention are even changes relative to genuine NeXTSTEP rather than just differences from WindowMaker's imperfect emulation of it. Focus-follows-mouse was an X11 thing WindowMaker shoehorned into its NeXT-like environment; genuine NeXTSTEP was click-to-focus, though it could be hacked to emulate focus-follows-mouse: https://ftp.nice.ch/peanuts/GeneralData/Usenet/news/1994/_Mi...
You probably know this, but it's the same stuff -- I would wager a hunk of the original interface builder code written for the NeXT machine runs on your Mac today when you use the interface builder part of xcode (though I haven't looked recently). You probably know this too, but all those classes that begin with the "NS" prefix come from "NeXT Step" -- same stuff, just updated.
It seems likely to me that all these dev tools from 1991 have something to do with why there are > 1M iPhone apps today. That and the enormous market attracting developers...
What was in the Next box CPU wise? You would need Rosetta or something like it to run the old binaries... though it would be awesome if someone implemented this (in fact... bring back rosetta, ffs!)
The original NeXT was Motorola 68030; but performance got decent after they added the 68040 running at either 25Mhz or 33Mhz (which was called the NeXT Mono Turbo if the display was mono or Turbo Color if 4096 colors display).
Interface Builder remained nearly unchanged all the way up until Project Builder turned into Xcode and shortly after IB got blended in. Here's a screenshot from IB under OS X 10.2:
https://cl.ly/0J1g1p1m0T3C
I personally liked the two being separate applications. IB is still great today, but it (and Xcode) slowed down noticeably when the two combined.
It was so much easier to fire up interface builder and build something to play around with ideas than the all-in-one Xcode must define a project of today.
I think anytime I have to create a project in any software, it adds a wall of ceremony that just keep adding more layers. It's the difference between QuickTime Pro and iMovie for editing.
I had almost forgotten about the horrendous horizontal pinstripes in early OS X. Looking back it's hard to understand why people drooled over the early OS X UI.
It wasn't ironic, at these "earlier" times it was common to use significantly stronger computers to develop for the "smaller targets": in 1975 Altair Basic, the first product of (then called) Micro-Soft, which had to run on the 8080 computer with only 4 kilobytes of memory was developed on the PDP-10 computer owned by Harvard University:
Also, the original Lucasfilm Commodore 64 games, such as Maniac Mansion, were cross-compiled on UNIX workstations, transferred over the network and uploaded to running C64s — way back in 1987! (Source: The Thimbleweed Park podcasts [0], which I highly recommend.)
Three years earlier, the development for the 1984 game "Match Point" for ZX Spectrum (the graphics in the video is original, the sound is fake by the youtube video producer):
For one of my summer jobs in college, this is around 2005, I had to port an old NeXTSTEP phone system to Mac OS X. I was amazed at how easy this was, considering it was just taking Carbon to Cocoa, and amazed at how ahead of its time NeXTStep's APIs were. Project Builder (XCode) and Interface Builder were created on these machines. Then bought by Steve@Apple.
Carbon was the name for the cleaned up, sanitized version of the old Classic Macintosh APIs that was compatible with OS X[1]: https://en.wikipedia.org/wiki/Carbon_(API)
I've heard that purchase described as "Jobs buying Apple for $-429mm" :)
I still remember reading reviews of the NeXT OS as a child, wishing I had the hardware to run it (from memory I was still running a PC at the time - an original IBM PC, which was considered a dinosaur even then).
Have you tried some of the newer magically-handles-everything frameworks like Meteor? Yes, it may not suit every project and I too use the more traditional tools for a lot of my work.
But when I do use Meteor for a project, I feel exactly like the NeXT developer in this video.
I mean he knew it was a video for NeXT, so I don't know what else he would have expected.
Though I would say I don't think he was portrayed badly in this video, the point was not that he was a problem, the point was that NeXT's application development environment is better.
What I found interesting, up until the Tiff issue, they were basically on par. The Sun programmer said his code would basically work with anything except tiff. The NeXT people probably knew this was a limitation of a specific library he was using and threw it in to make it less fair.
> At this point, we threw the programmers an unexpected but not unrealistic curve.
> Like a typical user, we asked them to add a feature not in the original spec. In this case, a button would recall all the trouble logs for a particular customer.
> Using NeXT Step, the NeXT programmer completed the task in about 20 minutes.
> [NeXT progammer discussing some details]
> The sun programmer also estimated a time of 20 minutes, but it took about 45 before he was ready to test his version.
This was about 20 hours in, which means that since they started on Wed, 30 October 1991 and assuming maximum 8-hour days, they have missed Halloween and would be at least halfway into Friday. The video states that the programmers finished on Sat, 2 November.
The video goes on to state that the NeXT system enabled the NeXT programmer to add a number of features such as system fonts and button icons "for free", which goes to show that the video's intended audience are managers and executives of software development teams who would of course want faster development, ad hoc requests, and cost-free features.
I personally would have been tempted to (╯°□°)╯︵ ┻━┻ once they announced a planned "unexpected" feature request because rather than train users and customers to frontload requirements in order to benefit from the design decisions that would be made as a result, the video encourages customers to believe their out-of-spec requests will be more quickly accommodated if only their programmers were using object-oriented NeXT Step.
25 years later, we know the truth about how easy it is to shoehorn in 11th-hour feature requests when using object-oriented code.
EDIT: link to specified timecode; formatting; additional detail about date code was written.
> than train users and customers to frontload requirements in order to benefit from the design decisions
No matter how much training we give customers, the very best they can do is give us the reasonably foreseeable requirements. That was maybe possible for a couple of decades when our main job as an industry was to take well-evolved paper processes and put them on a computer. Even then, though, people were getting better results by shipping every few days in response to observing actual user experience.
I don't think trying to frontload requirements works anymore, though. Startups are effectively machines for learning. We can't predict what learning will happen; if we could, we wouldn't be learning. And those startups are creating change for everybody else, making it impossible to know what competitive challenges might arise tomorrow.
So I think it's time for us to stop pretending we can get everybody else to freeze the world just because it's more convenient for a particular set of design techniques.
> 25 years later, we know the truth about how easy it is to shoehorn in 11th-hour feature requests when using object-oriented code.
I was a NeXT programmer back then. 25 years later, it is much easier to add feature requests to OO codebases. The three big differences: automated testing is common and easy; refactoring a design is a well-understood process; and you can deploy to millions of people with zero additional cost or work beyond committing and pushing to master. Which in turn means that the whole notion of "11th hour" is dissolving. Which hour is the 11th if you're releasing a few times per day?
Yours are all excellent points, especially in contexts that are close to or approaching continuous integration.
However, many shops still release annually, quarterly, and bi-monthly. Also many shops don't have smooth sprints, their development processes being somewhere between Agile and Waterfall. I've worked in two such shops.
I'm not naysaying you, just adding that I think your insights apply to a different model of development than the one I'm thinking about in my previous comment.
I don't understand this part. You said you're assuming 8-hour work days. AFAIK, it's not at all common to take Halloween off from work. So what's the point of mentioning that day?
Just that there are so few secular holidays in the US work context and Halloween is one of those non-holidays (like Cinco de Mayo in California) where people in the US will make an extra effort to spend time with friends and family.
The main problem is that managers and users - lacking a mental model of the software - have no idea what's an easy problem and what's a hard problem (that would take lots of engineering). Thid creates unrealistic expectations.
The problem is people think that just because it's easy for them, it's easy for a computer. Obligatory xkcd[0]. "What!? I can clearly tell that's a bird! You mean to tell me that you can't make a computer do the same?"
Exactly. The important thing about this video in retrospect is that NeXT had completely misidentified a viable market (workstation hardware for customer service representatives) and the competition within that market (Sun).
Meanwhile, in another universe from this video, 1991 was the same year that Visual Basic was released. The rest is history there.
Ultimately, the plan of having NeXT's tools on dedicated hardware paid off.. but it took another 20 years for it to happen, and the target hardware was consumer hardware costing 1/50th of what's shown here.
You can't ignore how NeXT was somewhat constrained by not being able to compete head-on with Apple without incurring serious legal expenses. They got sued once right out of the gate and would certainly have been sued more if they started to cause real trouble.
Sun and SGI had a significant head start over NeXT. By the time NeXT shipped hardware, they were moving off 68k onto SPARC and MIPS respectively, building on successful and established product lines with the kind of hardware differentiation that NeXT didn't have the capital for. That's why NeXT had to change direction and make software such a major part of their strategy; they couldn't just re-play the same strategies that Sun and SGI got off the ground with, because those niches were now pretty well occupied.
Maybe not $15k but developers frequently have much more powerful (and thereby more expensive machines) than the users who use those apps. Many of the developer machines at work have 16 to 24 gb of ram, SSDs and very fast CPUs. Our customers on the the hand might be running machines with a non SSD drive and 4gb of ram (or less??).
Pretty sure that the Sun workstations and NeXT workstations were about the same price at that time. NeXT might have even been cheaper if you go off list price, although Sun had huge discounts off their published prices for education and large corporate customers.
So IBM Thinkpad 700C priced $4,350 was a cheap thing? With 'a beautiful 10.5-inch active-matrix color LCD - the largest screen available on any notebook computer at the time'.
Does anyone know what kind of database the NeXT version of the application probably used? Plain text files? .plist files? A relational database? Something else?
I think one factor is that good UI and UX is nearly always proprietary, so these great platforms get built but then ultimately die when the market moves on.