Comment by nullpoint420
1 year ago
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....
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.
> 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.
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.
5 replies →
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.