NeXT used 'Display Postscript' a display server that was basically a inferior copy of Sun's NeWS system. This was later changed because NeXT was to small and Adobe didn't want to support Display Postscript anymore. Sun of course killed NeWS because they wanted to be a 'standard'. Next didn't care about standards. They had less applications then CDE Unix, and far lower deployment in the 90s.
Objective C is one of many language that you could use to build UI libraries on top of some display system. Objective C wasn't the best or inherently better then many others. Objective C adoption by Next was kind of a historical accident based on office location.
Having something VM based for UI development isn't actually that much of an issue, when the hardware manufacture delivers the OS with the VM included. And usually it his the hardware manufacture that delivers the OS. And VM bases system can be integrated well with the core OS, object oriented or not. And that VM are inherently to slow is also questionable, specially for UI apps that can use C libraries and the Display Server for the most performance relevant stuff.
Apple itself had a very nice system for UI development on Dylan that was arguable better in many way then the Next system. But when Steve Jobs came and they had Next, that wasn't developed anymore.
What Jobs showed of in the late 90s wasn't exactly revolutionary stuff. But Jobs always presents everything as revolutionary.
IPhone development in 2010 working the same as Next development in 1990 is a sign of 'failure', not of success.
Some notable applications done in it:
- Altsys Virtuoso --- this became Macromedia Freehand
- Lotus Improv --- cloned to become Quantrix Financial Modeler
- Doom notably was developed on NeXTstep and the WAD/level editor was never ported (though alternatives were later developed)
- Glenn Reid's PasteUp and TouchType --- two of the nicest apps for working with documents and type I ever had occasion to use
and a number of ports were done quite quickly and were arguably the best ever versions --- WordPerfect for NeXTstep was done in six weeks and FrameMaker on the NeXT stands out for an interface which I missed when using it on Mac or Windows.
In particular, I'd really like to have a successor to/replacement for Touchtype.app (and if that could be grown into a replacement for Macromedia Freehand, that would be great) --- what tool would allow developing this easily, and making press-ready files which perfectly match what is seen on-screen?
Graphical/integrated .tex editing environments are a frequently encountered application type, and there seems to be at least one for pretty much every programming environment --- I'm not aware of a graphical which has feature parity with TeXview.app and which is similarly consistent with its interface (it did win an Apple Design Award back in the day) --- if that's the case, then how can it be that developing with InterfaceBuilder and Objective-C and the NS-objects was so bad? If that's not the case, what development platform would you like to put forward which should have an even better TeX environment?
Virtual memory was a huge issue for UI development with a retained-mode system like DPS; thrashing window contents is very not fun if you want a responsive UI. Apple spent years optimizing VM for this purpose after the NeXT purchase.
The interface builder was written in Dylan and running inside the Dylan runtime.
The early use of Dylan (actually its precursor language Ralph) was to develop software on a Mac for an external device, like tablets and handheld computers. The development system was an external mainboard attached to a Mac. Apple released eventually a first device with ARM 610 20Mhz CPU, 640Kb RAM and 4MB ROM as a product. A few of the early internal development environments were written in Lisp on the Mac, using a lot of memory (precious and expensive megabytes!).
> Apple Dylan environment
That was a prototype of the Apple Dylan environment, later released as a technical preview. It was also never a product. Apple at that time often developed software prototypes and the released product was then recoded as a more efficient tool. The technical preview was for the Mac and for develop software for the Mac.
What other choice did NeXT have?
C++ was invented about the time NeXT started. Microsoft didn't even release MFC until 1992.
C...yikes.
Pascal. Would Steve had went along with that?
I don't see why he couldn't have. It's a far more elegant language and it and other Wirth languages like Oberon have inspired several current programming languages. The standard programming language of the Lisa and Mac was Pascal, and Apple even added object oriented features to it as Clascal (earlier than Wirth's Oberon and not compatible with it).
There were many alternatives.
Pascal is language family. Xerox did Pascal like Cedar at around the same time. Thing Modula-2 existed. Next could have done something along those lines. I'm sure there were commercial versions of that kind of stuff floating around.
Smalltalk was a big family at the time. Lisp OO system were already common. There were lots of commercial version of that they could have licensed.
Sun with NeWS had a very extended PostScript that basically allowed you to write most of the application in it.
There was a lot of stuff going on back then already. History always hides how much stuff was actually happening. Sadly most of it isn't open source, so tons of great stuff goes into a historical blackhole.
My point is, with the amount of money Next was able to raise and invest in these systems, they could have gone a number of different ways. They made a reasonable discussion at the time.
As a side note, Apple Dylan seems incredibly limiting and opinionated for no reason. I find it interesting the website lamenting its death only shows screenshots [2][3][4] of the "advanced" editor, rather than any successful applications made using Dylan.
Also, how can I incrementally migrate Dylan into existing codebases, which were most likely C, at the time? Does it have an FFI? Also, most software engineers mental models at the time were imperative, and they expected them to learn the intricacies of functional programming and object-oriented at the same time?
That's not even to mention the logistics about running it:
> Keeping your source code in a fully version-tracked, object-oriented database with full metadata is an idea whose time has long since arrived, yet most of us still spend our time editing text files. Apple Dylan could export and import code from text files, but once you’ve used an IDE that takes advantage of fine-grained object storage of your source, you’ll never want to go back. [5]
Does this mean I'd need to shape my entire source control system around Apple Dylan? How would diffs and collaboration work? To use my source control system would I have to "export" it to plaintext every time? Text-based AppKit and Obj-C fit right into existing source control systems of the day.
Also Obj-C and AppKit was already dogfooded heavily within NeXT. The system UI was built using it, as well as all the apps that shipped with the system. You can't say that about Dylan and MacOS 9.
[1] https://opendylan.org/history/apple-dylan/screenshots/misc.h...
[2] https://opendylan.org/history/apple-dylan/screenshots/browse...
[3] https://opendylan.org/history/apple-dylan/screenshots/dynami...
[4] https://opendylan.org/history/apple-dylan/screenshots/index....
There were two teams fighting for delivering the OS, one using Dylan, other using C++, eventually the C++ team won the internal politics, even though the Dylan one was relatively ahead.
Newton was programmed in NewtonScript, prototype based OOP.
Eventually the SDK allowed for C++ native extensions, and on the later version of the OS, before Newton was killed, there was already a basic JIT in place.
NextStep had seen more development and existed earlier and was used more, that much is clear.
I am not saying they made the wrong discussion sticking with it at Post-Jobs Apple.
My broader point was just that the article leaves out a lot of other stuff happening at the same time.
There would be no Java on Android, for sure.
Additionally, as someone that ported a visualisation framework from NeXTSTEP to Windows, the Acorn would never be able to run NeXTSTEP.
NeXTSTEP was ridiculously expensive for a reason, in terms of hardware capabilities for the time.
Side note... I feel similarly about the Java to Kotlin transition. Sooo much better. Although, I don't hate Java NEARLY as much as Obj-C.
It is magical the way I can just use the C libraries with all the dynamic goodness Obj-C.
It's really kind of a bummer that we don't have well-known examples of "skinnable" programming languages already. The closest we get are the ones that let you choose your set of keywords for different locales in case you don't want to work with an English-based PL and those block based languages that let you manipulate them as blocks or edit the textual form. I firmly believe that PL skinning would really benefit so many otherwise worthwhile languages that get short-shrift because of negative reactions to the surface-level details. I'm referring in particular languages like those in the Pascal family. (You could also conceive of e.g. a skin for Golang that doesn't have leading caps be the determiner for whether a function is public or not. There are lots of applications for this, and the variations are a non-issue when you have an ecosystem with strong norms about applying a code formatter (like gofmt), which can dictate the format of the canonical on-disk representation.)
For collaborative projects on the other hand, it can become a handful to maintain if everybody contributing isn't staying on top of hygiene with null checks, type checks, etc. Swift helps to keep all of that under control.
Also, you're 100% right. The square brackets are what immediately repulsed me and continued to befuddle me even after years of experience with it. Also, everything just feels "backwards" to me if that makes any sense. Coming from Java/C#/JavaScript everything just seemed unintuitive to me at all times. Also, I think this was heavily compounded by using xCode which (at the time) was incredibly laggy. So, I'd mess up the Obj-C syntax and the IDE wouldn't tell me for what felt like forever. Often I'd make a change and hit "play" before the syntax highlighting caught up and that always felt infuriating.
I last used xCode about 4 years ago and it was still an issue then (even with swift).
Maybe one it they will rewrite the Objective-C, who knows.
Kotlin transition is a Google thing, outside Android barely anyone notices that it exists.
That’s not true.
I started with Objective-C and loved it but I imagine that wouldn’t have been the case if I started with Swift.
I think that one of the tragedies of older programming languages is that they survive long enough for people to forget the technical - and technological - constraints that influenced their design. Swift is great, but there are reasons why there weren't any Swift-like languages being developed in or around 1984.
Similar feelings about Java. It is definitely not my favorite programming language. (I suppose Kotlin isn't either, but it's in the top n.) But it's hard for me to actually hate it. Java walked so that Kotlin could run.
Even the Object Pascal to C++ transition at Apple was mostly caused by increased UNIX adoption, and Apple programmers wanting to offer similar experiences, thus MPW was born.
Same on other platforms, until C and C++ eventually won everywhere, at least until several new kids decided to challenge them in various fronts.
One that you seldom see nowadays, outside games, is pure GUI frameworks using C or C++.
He isn’t famous for being a programmer, but he could do it, and he certainly understood it.
And Jobs kept most of the money ($4,750), gave Woz $350 and went off to India to achieve enlightenment.
- Oral History of Blaine Garst [PDF]: https://archive.computerhistory.org/resources/access/text/20...
- Oral History of Blaine Garst [Video]: https://www.youtube.com/watch?v=qtEIq7fe_KQ
- Oral History of Steve Naroff [PDF]: https://archive.computerhistory.org/resources/access/text/20...
- Oral History of Steve Naroff [Video]: https://www.youtube.com/watch?v=ljx0Zh7eidE
Not listed here, but also available, is the oral history of Brad Cox and the later Objective-C paper authored by Naroff, Cox, Hsu (the author of the linked blog post) for HOPL IV. Someone else will have to dig up the links.
You can also find interviews by other NeXTSteppers on the CHM site like Avi Tevanian and others. I think the Naroff one is best.
[1] https://www.labouseur.com/courses/erlang/history-of-erlang-a....
[1] https://www.mikeash.com/pyblog/objc_msgsends-new-prototype.h...
To be honest, as someone who was into SGI computers as a kid, accepting the reality I would NEVER be able to own one, I hoped one day I would get to use or try one in the workplace. Of course, by then, technology had moved and these expensive machines are now affordable, simple a Windows PC with a good graphics card!
Getting back to NeXT, I heard "Next" thrown about when reading up on ID Software (Doom, Quake, etc) but never really appreciated what this was until later on. When I finally spent the time to understand that this "Next" was a computer, I started to appreciate how cool it was especially back in 1990! It made me appreciate how far ahead they were with programming/development tools. I mean.. Visual Studio finally caught up with productivity.. like.. 10 years later!
It is great to see the history of NeXT continue -- not just being "merged" into Apple but with OpenSTEP and others.
It also makes me appreciate less known programming languages that, one day, could become "mainstream" at any point. Hardly anyone knew much about Objective-C but became a popular tool for Apple developers with OSX. Thats why I always have a grin when people mock a less known language because "hardly anyone uses it" or "hardly anyone knows about it" -- that could change, you know.
Interface Builder is nice, I remember trying to develop GUIs on Amiga with intuition.library and wished that there was a drag and drop program to build the source code. Running NeXTSTEP 3.3 on Virtual Box and trying to get it running on my early 2000s laptop :)
If folks had guess what turnaroud NeXT would go through, most likely my thesis would have been something else.
We’re well into the 2020s and I’d say those problems have pretty much remained unsolved. ;)
https://www.youtube.com/watch?v=UGhfB-NICzg
A sun vs next rapid development challenge.
