Dylan (originally called Ralph) was basically Scheme plus a subset of CLOS. It also had some features meant to make it easier to generate small, fast artifacts--for example, it had a module system, and separately-compiled libraries, and a concept of "sealing" by which you could promise the compiler that certain things in the library would not change at runtime, so that certain kinds of optimizations could safely be performed.
Lisp and Smalltalk were indeed used by a bunch of people at Apple at that time, mostly in the Advanced Technology Group. In fact, the reason Dylan existed was that ATG was looking for a Lisp-like or Smalltalk-like language they could use for prototyping. There was a perception that anything produced by ATG would probably have to be rewritten from scratch in C, and that created a barrier to adoption. ATG wanted to be able to produce artifacts that the rest of the company would be comfortable shipping in products, without giving up the advantages of Lisp and Smalltalk. Dylan was designed to those requirements.
It was designed by Apple Cambridge, which was populated by programmers from Coral Software. Coral had created Coral Common Lisp, which later became Macintosh Common Lisp, and, still later, evolved into Clozure Common Lisp. Coral Lisp was very small for a Common Lisp implementation and fast. It had great support for the Mac Toolbox, all of which undoubtedly influenced Apple's decision to buy Coral.
Newton used the new language to write the initial OS for its novel mobile computer platform, but John Scully told them to knock it off and rewrite it in C++. There's all sorts of gossipy stuff about that sequence of events, but I don't know enough facts to tell those stories. The switch to C++ wasn't because Dylan software couldn't run in 640K, though; it ran fine. I had it running on Newton hardware every day for a couple of years.
Alan Kay was around Apple then, and seemed to be interested in pretty much everything.
Larry Tesler was in charge of the Newton group when I joined. After Scully told Larry to make the Newton team rewrite their OS in C++, Larry asked me and a couple of other Lisp hackers to "see what we could do" with Dylan on the Newton. We wrote an OS. It worked pretty well, but Apple was always going to ship the C++ OS that Scully ordered.
Larry joined our team as a programmer for the first six weeks. I found him great to work with. He had a six-week sabbatical coming when Scully ordered the rewrite, so Larry took his sabbatical with us, writing code for our experimental Lisp OS.
Apple built a bunch of other interesting stuff in Lisp, including SK8. SK8 was a radical application builder that has been described as "HyperCard on Steroids". It was much more flexible and powerful than either HyperCard or Interface Builder, but Apple never figured out what to do with it. Heck, Apple couldn't figure out what to do with HyperCard, either.
I know my comment doesn’t add much value to the conversation, but I’d be remiss if I didn’t say thank you for taking the time to respond here and below with such interesting history.
I was able to find this userguide [1], which is from 1994. It's very interesting. Since the project seems to have gone on until 1997 I imagine this doesn't represent the later versions, but perhaps they weren't documented like this.
If you read all the way through the section about creating a Concentration game, you can sort of get an idea of what it could do. It doesn't really give you a very good feel for what it was like, though. Nobody used SK8 in the sort of stilted one-action-at-a-time-in-sequence way that the the tutorial describes; that's an artifact of technical writing. You have to write it that way in order to clearly explain each step and each tool used without misleading ambiguities.
In actual use, it was more like working with HyperCard or a Mac drawing program. The difference from HyperCard was that you weren't limited to five predefined graphical widgets and only strings for representing data. You could build arbitrary data structures and assemble arbitrary widgets interactively from graphical primitives.
You might be able to find a copy of the SK8 Technology release by googling for something like "SK8 Apple technology release". The Wikipedia article has two links that purport to offer the SK8 sources, though neither link seems to be working this morning.
I think Rainer (lispm) at some point posted a link to an archive of the SK8 technology release; maybe he still knows where it is. Good luck running it, though. You'll need a very faithful emulation of a specific range of Mac System releases on a specific set of 68K or PPC hardware.
The Wikipedia article also has a screenshot of the SK8 environment:
The weird look of the windows was intentional. It provided visual distinction from the normal Mac user interface. SK8 projects often involved creating normal Mac interface elements, and n true Lispy fashion, absolutely everything in the SK8 environment could be cracked open and edited, including SK8's own UI, so SK8's windows were made to look very different from normal Mac windows so you could easily tell them apart while workingon a project.
That weird look is interesting in itself. It was achieved by writing WDEFs in Lisp. A WDEF was a code resource in the old (pre-OSX) mac system, used for rendering windows on the screen. You could customize the apperance of a program's windows by supplying WDEF resources that the program used to render its windows.
WDEFs were usually written in assembler or, in latter years, C. With Macintosh Common Lisp, though, you could write them in Lisp. In fact, you could write them in a mix of Lisp and assembler, using MCL's built-in interactive assembler.
(Approximately the first time I met him, Dave Vronay, who wrote much of SK8's graphical infrastructure, waxed eloquent about how wonderful it was to have an interactive assembler that could wrap machine code in convenient higher-level code. He had previously hacked on arcade games.)
Since you are someone who seems to have been in on this in the heyday, I'll share my story with you (I think it is, in a way, telling).
In short: I was a Hypercard kid. It's strange to look back on it this way, but the early/mid 90s seems like a completely different kind of computing. It was in that period where I first started seriously using computers, writing my first stacks probably at about 9 or 10 years old. I was inspired by all of the compelling stackware and, as you might guess, Myst, which was a pretty big deal at the time.
Back then I saw Hypercard as "serious" for the following reasons:
- You made "programs" that looked like the rest of the system (OS), and hence were the "real thing";
- You could make games in it yourself, but so could professionals, so it had to be "serious"
- It was not just for doing one thing, but most possible things
What happened as the years went on was that the outside world continuously told me that Hypercard was, in fact, not the real thing; it was not "real programming." Materially this became even more clear as the software was left to die on the vine by Apple. One of the reasons I did not pursue CS in college (and I'm very happy I didn't) is because I didn't like all this C++ stuff that the other kids claimed was "real programming" -- if that was the real thing, I didn't want any part of it ("how in the world do you make a button with that?").
Only in recent years have I started to read up on PARC, Alan Kay, and some of the genesis of the ideas about personal computing systems. I've realized that my younger, initial instinct was probably correct: Hypercard was more like "real computing" than anything else I've encountered. It's a shame that what I expected to happen back then didn't come to pass -- that the whole future Mac OS, as presented to the user, would be a kind of Hypercard (inspectable, adjustable, open to limitless tinkering and creation, and able to be learned by interactive live examples).
I hadn't heard of SK8 until this exchange. It is very heartening to see that the grown-ups were thinking along the same lines. On the other hand, it's easy to become crestfallen at the state of computing today by comparison.
HyperCard was pretty great, and it rapidly developed a devoted community. It had some fairly severe limitations (only about five built-in widgets and a scripting language in which the only data structure was text strings), but people still managed to make a lot of cool stuff with it--sometimes by writing extensions called XFCNs and XCMDs, generally in C.
SK8 removed HyoerCard's limitations, but it never really made it out of ATG. Well, there were a few technology-sharing projects with universities and industry.
But Apple's management had no idea what to do with HyperCard, much less SK8. They couldn't figure out what marketing category to put it in or how to charge for it. Heck, the only reason it existed at all was because of a promise they had made to Bill Atkinson to try to keep him from leaving.
I hear you about the current state of computing. I do miss the tools I was regularly working with in the early 90s.
As I said, he was really great to work with. He wrote the initial draft of the simple frame language that bauhaus used for "intelligent assistance". He was a capable Lisp hacker, and a big fan of Lisp and Smalltalk. He's also just one of the nicest people I've ever met.
He left Apple some time around when Steve Jobs returned. I don't know why why he left, but I wouldn't be surprised if Steve had something to do with it.
I worked for Steve at NeXT for a little while, and he came and sat in my office one day and went on at length about everything that was wrong with Apple in his view. Prominent on his list were the Advanced Technology Group and the Human Interface Group. Larry was involved one way or another with both of those institutions, and Steve wasted no time getting rid of them when he took over again.
I think firing the Human Interface Group was a mistake, too. I think the usability of Apple's products has suffered, and so has the usability of technology products in general.
How do you feel about it? I had a bunch of Newton MessagePad and the 2100 model was especially great.
The MessagePad UI was not in color and was less animated than something like the early released iPhone or iPad. Okay, probably hardware limitations of the time: screen price, lower power draw, less powerful graphics processing, ...
I always found the UI model of the iPhone (and iPad) limited to what the Newton MessagePad did. It is still boring in the main OS screens. Was it to reach mass market? was it a conscious choice? or was it the non-dynamic programming system introduced with the iPhone, which limits the experience?
I liked the Newton products, and used them for a while. I thought the MessagePad was an awkward size, though; too big to fit in a pocket, but too small to have a good-sized screen. It would have been better if it were either smaller, like the Palm Pilot, or larger, like the unreleased Senior and Cadillac prototypes (I had a couple of those and liked them quite a bit).
Hardware limitations did have an important effect on them. Pretty much everything you see on the shipping Newton was a compromise between trying to give the device enough power and capacity to be interesting and trying to keep it small and cheap enough for people to buy. We didn't hit the sweet spot.
Yeah, iOS gave up a lot of flexibility and capability as compared to Newton, but Steve was never going to reuse a failed product conceived under someone else's leadership, and anyway, he chose to abandon the whole idea of a device for creating stuff and went with a device for consuming.
Lisp and Smalltalk were indeed used by a bunch of people at Apple at that time, mostly in the Advanced Technology Group. In fact, the reason Dylan existed was that ATG was looking for a Lisp-like or Smalltalk-like language they could use for prototyping. There was a perception that anything produced by ATG would probably have to be rewritten from scratch in C, and that created a barrier to adoption. ATG wanted to be able to produce artifacts that the rest of the company would be comfortable shipping in products, without giving up the advantages of Lisp and Smalltalk. Dylan was designed to those requirements.
It was designed by Apple Cambridge, which was populated by programmers from Coral Software. Coral had created Coral Common Lisp, which later became Macintosh Common Lisp, and, still later, evolved into Clozure Common Lisp. Coral Lisp was very small for a Common Lisp implementation and fast. It had great support for the Mac Toolbox, all of which undoubtedly influenced Apple's decision to buy Coral.
Newton used the new language to write the initial OS for its novel mobile computer platform, but John Scully told them to knock it off and rewrite it in C++. There's all sorts of gossipy stuff about that sequence of events, but I don't know enough facts to tell those stories. The switch to C++ wasn't because Dylan software couldn't run in 640K, though; it ran fine. I had it running on Newton hardware every day for a couple of years.
Alan Kay was around Apple then, and seemed to be interested in pretty much everything.
Larry Tesler was in charge of the Newton group when I joined. After Scully told Larry to make the Newton team rewrite their OS in C++, Larry asked me and a couple of other Lisp hackers to "see what we could do" with Dylan on the Newton. We wrote an OS. It worked pretty well, but Apple was always going to ship the C++ OS that Scully ordered.
Larry joined our team as a programmer for the first six weeks. I found him great to work with. He had a six-week sabbatical coming when Scully ordered the rewrite, so Larry took his sabbatical with us, writing code for our experimental Lisp OS.
Apple built a bunch of other interesting stuff in Lisp, including SK8. SK8 was a radical application builder that has been described as "HyperCard on Steroids". It was much more flexible and powerful than either HyperCard or Interface Builder, but Apple never figured out what to do with it. Heck, Apple couldn't figure out what to do with HyperCard, either.