ADVERTISEMENT

Viewpoint

By Scott T Boyd, Editor-at-Large

When I first saw Dylan, years ago when I was still at Apple, I dropped everything and ran out to get documentation. Wow! Even with a Lispy syntax, the language grabbed my interest. The rumor (yes, even people inside Apple often wonder what’s really going on) was that Dylan was being developed for the Newton, but some big hoo-haa happened. Nevertheless, only two years later the Dylan team gave a powerful presentation to a standing-room only crowd at WWDC. The room stayed filled to overflowing for the duration, and the audience sat in rapt attention. Dylan clearly had the right stuff.

From its inception, Macintosh offered a Pascal interface to a machine built with 68K assembly language. Over time C got its foot in the door, then forced its way all the way in. It didn’t matter that C programmers (and compiler writers) had to go out of their way to conform to Pascal calling conventions. Maybe C programmers always expected life to be a little harder. Pascal retreated to second-class citizen status about the same time that C++ appeared on the scene. Again, it didn’t matter that C++ builds took hours, nor that debugging tools were initially completely inadequate. C and C++ clearly won the battle for market share. Pascal holdouts developed a double frustration (as if it wasn’t bad enough that they were developing for a machine with only a tiny fraction of the overall market share).

As one of those frustrated Pascal programmers, I did the only sensible thing - I turned to 68K assembly language. No sense in using it to do simple things, though. After all, a bunch of my C++ NuFinder friends were getting lots of hours in on the video games. I couldn’t let them get too much practice without getting in some of my own, so I put 68K assembly language to its best possible use - building Macintosh system software. That often took hours, just like NuFinder!

So along comes Dylan. What grabbed me? I don’t even know where to begin. I don’t think the ephemeral garbage collector did it, nor did the clean exception model. I raised my eyebrow at the direct dispatching of events and the resulting elimination of the need for almost all conditional expressions. Those paled in comparison, though, to the dynamic, interactive programming environment.

What does that mean? You can execute your program, halt it when it misbehaves, fix some code, and resume execution! “But wait!” you say. “How can this be? Where’s my video game practice time in this process?” Wasn’t there supposed to be a big compile time followed by an excruciatingly-long link time? Oh, sure, Metrowerks and Symantec have knocked that time down considerably, but there’s still time for a good cup of ’jo in a small project build, or even a full game of CyberBall while building something the size of Cyberdog.

I hesitate to even mention that I once programmed in BASIC. After all, how serious can a language be when you don’t even have to deal with a compiler or a linker? What I do remember was how productive I felt in the interactive environment. I could write code, run it, test it, and write some more, all in the span of a few seconds. I didn’t realize how much I missed that experience until I saw Dylan. Ease-of-use? The Macintosh experience brought to the developer’s doorstep?

Of course, it was too good to be true. The demo was great, the team was stellar, and Apple couldn’t deliver. After untold millions of dollars and tens of thousands of hours of work, Apple disbanded the Cambridge team and sent them packing (and just about the time that Dylan implementations were showing up other platforms, too!). Bummer!

I’ve been waiting for a Dylan-like experience for years. Is it time? Although I know that I’ll hear the old “common sense” harangues about performance and footprint, I’ll say it anyway. Yes. Times are a-changin’, and common sense warrants reconsideration from time to time. I’ll measure acceptable performance by two standards. First, does my performance increase? I don’t care how fast a compiler can consume thousands of lines of C code, a compiler that incrementally compiles code during a “Save” beats it every time. Second, do my applications compare favorably with best-selling software on footprint and speed? Sure, I remember the days when we slaved to fit a system and an application onto a single 400K floppy, but larger floppies (how big a floppy is the Internet anyway?), compression, and machines bigger than the minicomputers of less than a decade ago changed all the rules.

I’ll leave you with this thought: Mike Lockwood, former Dylan frameworks engineer, said to me during a demo back in ’94, “One of these has to succeed. I don’t really care which, as long as one of them does.” The other one? QKS’ SmalltalkAgents. See for yourself at <http://www.qks.com/>

Top 10 Again

We’ve now heard more from Apple about the MacHack Top Ten. I must commend the author of this response for overcoming many of the criticisms I voiced here last month. While not really saying much, this latest response leaves less room for caustic comment. Check out Apple’s latest at <http://www.machack.com/>.

Food For Thought

Ask Yahoo <http://www.yahoo.com/> about languages and you’ll see numbers like this: C++ - 109 matches, Visual Basic - 86 matches, Java - 68 matches, Smalltalk - 21 matches, AppleScript - 8 matches, HyperTalk - 1 match.