Dec 95 Viewpoint
- Jan 95 Viewpoint
- Feb 95 Viewpoint
- Mar 95 Viewpoint
- Apr 95 Viewpoint
- May 95 Viewpoint
- Jun 95 Viewpoint
- Jul 95 Viewpoint
- Aug 95 Viewpoint
- Sep 95 Viewpoint
- Oct 95 Viewpoint
- Nov 95 Viewpoint
Volume Number: 11
Issue Number: 12
Column Tag: Viewpoint
Viewpoint fl
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
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
Food For Thought
Ask Yahoo
C++ - 109 matches, Visual Basic - 86 matches, Java - 68 matches, Smalltalk - 21
matches, AppleScript - 8 matches, HyperTalk - 1 match.