Most active commenters
  • panick21_(6)
  • pjmlp(4)
  • lispm(4)

←back to thread

107 points wmlive | 27 comments | | HN request time: 1.088s | source | bottom
1. panick21_ ◴[] No.42121263[source]
This is very narrow history. Basically a history that excludes everything that isn't Jobs walk to glory and perfection and domination. Ignore many important points, problems, accidents, alternatives and so on.

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.

replies(7): >>42128948 #>>42128971 #>>42129049 #>>42129288 #>>42129449 #>>42129700 #>>42130118 #
2. WillAdams ◴[] No.42128948[source]
What current development environment and language would you like to put forward as a successor to/alternative of NeXTstep?

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?

replies(1): >>42135869 #
3. wtallis ◴[] No.42128971[source]
If you're going to bring Sun and NeWS into the conversation, you ought to also mention how after NeWS failed, Sun tried adopting OpenStep for Solaris.
replies(1): >>42134447 #
4. ab5tract ◴[] No.42129049[source]
No offense but this comes off as an equally narrow accounting of the historical record.
replies(1): >>42134393 #
5. KerrAvon ◴[] No.42129288[source]
I actually used the Apple Dylan environment. IIRC, it required 48MB RAM -- yes, M -- to launch, which was extremely an extremely large amount at the time -- as in, you probably needed to buy more RAM to run it -- and was itself written in Macintosh Common Lisp instead of self-hosting. UI development? Thing could barely run on a contemporary Mac. Every efficiency claim that was made for it was unproven. Maybe it could have been great, but it certainly needed at least a couple of years more bake time. The NeXT runtime existed and its performance characteristics were understood.

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.

replies(1): >>42140797 #
6. nullpoint420 ◴[] No.42129449[source]
I think it's stretching the truth a little to say that Apple "had a very nice system for UI development on Dylan." The Dylan Eulogy site itself claims they hadn't even finished their Interface Builder [1] by the time it was canceled, which NeXT already had 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....

[5] https://opendylan.org/history/apple-dylan/eulogy.html

replies(2): >>42130728 #>>42134431 #
7. chasil ◴[] No.42129700[source]
Just imagine if NeXT had been based on the Acorn Archimedes platform, instead of M68k.

There would be no Java on Android, for sure.

replies(1): >>42130776 #
8. bluedino ◴[] No.42130118[source]
Mac OS development introduced me to Objective-C. Quirky, but I grew to like it. I think it was the first time I 'got' object-oriented programming. I had done Windows programming before and while it was 'fine', writing Mac OS GUI code was so nice. Probably a credit to the frameworks as much as the language, though.

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?

replies(3): >>42131511 #>>42134514 #>>42136341 #
9. pjmlp ◴[] No.42130728[source]
The platform which Dylan was originally designed for, the Newton had no C to begin with.

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.

replies(1): >>42140698 #
10. pjmlp ◴[] No.42130776[source]
As someone that knows Java since it exists, I fail to see the connection.

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.

replies(1): >>42151624 #
11. icedchai ◴[] No.42131511[source]
I did a bunch of iOS development for about 4 years. I found Objective-C way more productive than C++.
12. panick21_ ◴[] No.42134393[source]
I didn't publish a long article claiming to go into the 'deep history', I just added a few points. I initially had a longer comment but it go unwieldy.
13. panick21_ ◴[] No.42134431[source]
I guess it would have been better to say, Apple was working on a nice system for Dylan.

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.

14. panick21_ ◴[] No.42134447[source]
Sadly Sun kind of went of the deep end did itself no favors on the desktop. There is a reason they turned primarily into a server vendor. You could also run Xerox Cedar on Sun machines at the time.
replies(1): >>42145491 #
15. panick21_ ◴[] No.42134514[source]
I'm not saying taking Objective-C was wrong.

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.

16. WillAdams ◴[] No.42135869[source]
A further example, TeXview.app was a very nice interface for editing TeX documents on NeXTstep, and has since been succeeded by TeXshop.app on Mac OS X and arguably even surpassed (it has many more features, and I can't recall any which are missing).

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?

17. jhbadger ◴[] No.42136341[source]
>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).

https://en.wikipedia.org/wiki/Clascal

18. lispm ◴[] No.42140698{3}[source]
> The platform which Dylan was originally designed for, the Newton had no C to begin with.

These platforms had no development tools. The firmware and software runtimes were created outside. I would guess that there definitely C was involved for much of the firmware and that an on device Dylan runtime had C and assembler code.

replies(1): >>42145510 #
19. lispm ◴[] No.42140797[source]
> UI development?

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.

20. pjmlp ◴[] No.42145491{3}[source]
It was the research into systems like Xerox Cedar, among others, that turned me into a believer of systems programming with automatic resource management languages.

Most of these systems failed not due to technical limitations, rather by poor management decisions that ended up killing their adoption.

Likewise in the UNIX world, my favourite ones are the ones that went out of their way to not be yet another UNIX V6 clone with X, like IRIX, NeWS and NeXTSTEP.

21. pjmlp ◴[] No.42145510{4}[source]
Assembler for sure, as even today it is unavoidable in low level firmware coding, at the time Apple was a Object Pascal/C++ shop, usually the C like APIs were extern "C" in many of the toolbox APIs implementation.
replies(1): >>42145978 #
22. lispm ◴[] No.42145978{5}[source]
The MCL kernel was written in C.
replies(1): >>42149391 #
23. mikelevins ◴[] No.42149391{6}[source]
The discussion has various conflations, omissions, and errors. It's been a long time since Dylan on the Newton was what I worked on every day, and my memory is no doubt faulty, but I'll do my best to correct a few things.

"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."

This one is misleading in a couple of respects. First, there was more than one Dylan development system at Apple: Leibniz for the Newton and Apple Dylan for the Mac (I think it was called "Hula" internally, but I may be wrong about which project got that name). Both were written in Common Lisp using MCL, but they were distinct projects with different goals. Neither had tools like NeXT Interface builder. The Lisp-based application builder that rivaled (and in my view surpassed) Interface Builder was SK8, which was unrelated to Dylan. SK8 was also written with MCL.

Dylan was not canceled because Steve Jobs returned with Nextstep. The cancellation happened several years before Steve came back and was part of Apple's normal product and project churn.

"Apple Dylan seems incredibly limiting and opinionated for no reason."

It didn't seem that way to me, but that's about all I can say to a vague subjective impression of this kind.

"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."

There weren't really any successful applications made using Dylan, if you mean shipping products. It never got that far along.

There were projects written with Dylan that were successful on technical merit, but never shipped for reasons that had nothing to do with their technical quality. For example, the final review of bauhaus told us that we had met and exceeded every metric of success, but Apple management just didn't want to ship a Lisp OS for Newton, full stop.

But yes, Nextstep was dogfooded to a degree that Dylan was not, and it was much farther along than Dylan ever was.

"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."

This characterization is misleading in a few ways. I wouldn't say the teams were fighting, and I wouldn't say the Dylan team was ahead, except in maybe a couple of narrow areas.

Initially all Newton development was done in Dylan (called "Ralph" at that time), except for work on the microkernel, which was C++, and the 7 "bottleneck" graphics routines from QuickDraw, which were C.

The Newton team did substantial work on the software system in Dylan, and it worked, but there were some objections. Larry Tesler objected that it was too much like a desktop OS and needed to be redesigned for a handheld device with touch input. Meanwhile, some discussion took place with John Sculley during one of his trips to Japan and when he came back he ordered Larry to move main system development to C++. Larry did so, but reserved a small group of programmers (of which I was one) to continue experimenting with Dylan to see what we might accomplish.

We accomplished too much: we ended up making a whole second OS in Dylan. That's not what Apple management wanted, and they canceled our effort. That was no surprise to me; what surprised me was how long they tolerated our experiment before pulling the plug.

Then again, Apple in those days was a sort of constellation of skunkworks projects. Apple engineers would go off in random directions when not under threat of looming deadlines, and cook up all sorts of wacky things, and it was sort of tolerated because sometimes those wacky projects turned into things that made money.

"> The platform which Dylan was originally designed for, the Newton had no C to begin with. These platforms had no development tools. The firmware and software runtimes were created outside. I would guess that there definitely C was involved for much of the firmware and that an on device Dylan runtime had C and assembler code."

I don't know of a Newton platform for which C tools did not exist.

The Newton originally targeted the AT&T Hobbit (https://en.wikipedia.org/wiki/AT%26T_Hobbit), which was a RISC chip designed to run C efficiently. By the time I was recruited the boards were using ARM chips, but the Newton microkernel was already written in C++. Perhaps there was a time when a Newton existed without a supporting C compiler, but I never saw it.

Now it might be that you meant that no C compiler or development tools ran on Newton hardware, and that much is true. The Dylan development didn't run on the Newton hardware, either. All dev tools ran on Macs and cross-compiled to the ARM platform.

replies(3): >>42150062 #>>42150454 #>>42171105 #
24. lispm ◴[] No.42150062{7}[source]
Thanks, Mikel, for the explanations!
25. nullpoint420 ◴[] No.42150454{7}[source]
Thank you, Mike for clarifying all of this and providing us with a first-person account of the events described.

I do want to apologize - I meant no disrespect in regard to the technical achievements of the Dylan team. In fact, I share the view that the Dylan project was ahead of its time in many aspects.

26. chasil ◴[] No.42151624{3}[source]
Wow, that's expensive.

There is no way that Steve Jobs could have talked Furber & Wilson into this.

http://www.shawcomputing.net/resources/next/hardware/ns31_co...

27. panick21_ ◴[] No.42171105{7}[source]
Hi, thanks for your comment. My comment about Dylan was because I had talked to somebody who used Dylan for Mac development and said it was a nice way to develop Mac application.

I didn't want to suggest it was as far along as NextStep Objective C based system.

That same person also suggested that Post Jobs, with the move to next this was gone. But it seems that development was canceled even earlier.

I didn't know about SK8, I will look more into that.