NEMADA News

Dave Pomerantz

In contrast to our low September turnout, a record number of MacApp'ers struggled through the twisting streets of East Cambridge to hear John Hotchkiss of Apple's Advanced Technology Group (ATG) describe the purpose and power of Dylan, Apple's forthcoming object-oriented dynamic language (OODL). We were rewarded with a free copy of the Dylan manual and an uplifting discussion of how much easier our lives will be with instant compiles and links, free from the worries of memory management.

You have your doubts? Naturally. We all do. But let's give these guys a chance and see where they're headed.

Dylan began with the acquisition of Coral Software, which became ATG East. Coral was marketing Macintosh Common Lisp, and Apple asked them to continue to support MCL and simultaneously develop a new dynamic language with all the programmer power and convenience of Lisp and Smalltalk but with the performance required for production applications.

Even better than C++?

We all live with the need for a better development environment. We suffer with twenty-minute edit-compile cycles on even the fastest Macs, complex languages that take years to master, uncontrolled pointers that can zap any spot in memory, and wasted time searching for memory leaks. Our managers may treat software like so much clay, but we know that our hostile development environment hardens software to concrete within months. It's the purpose of Dylan to keep software soft.

John explained these significant advantages of Dylan over C++ or Object Pascal:

• Dynamic Type Safety. Type-checking is done at compile time, where possible, like C++ and Pascal. But it can also be done dynamically when type information is only available at run-time.
• Automatic Memory Management. Memory allocation is hidden from the programmer, occurring as needed to create new objects. Objects that are no longer referenced are disposed automatically.
• Dynamic Linking. Only affected methods are recompiled and relinked, effectively eliminating compile-time. It may even be possible to make changes while debugging, for example, you could fix a method while stopped at a breakpoint between calls to that method.
• Dynamic Subclassing: This is really the same as dynamic linking, but I've separated it because of its enormous implications. You can ship an extension to your application that subclasses your existing application. You can ship an integrated application in distinct pieces (priced separately) that link together at the customer site. Corporate programmers or VARs could greatly customize your application without having access to your source code. Dinker can do this too, but not as well and not as an integral part of the language.
• Reflectivity: This is not an optics term. It means all objects can identify themselves. You can traverse memory and identify each object. Dylan uses reflectivity to guarantee type safety at run-time.
• Meta-Objects: Classes and methods themselves will be first-class objects that can be manipulated by the language. This sounds both powerful and dangerous, but I'm too much a novice to understand the implications.
• Libraries: A crucial part of your development environment will be the supporting class libraries that are not part of the language. There will be libraries for supporting numerics and collections.

But is it fast?

The twelve people listening had plenty of questions and concerns, many about Dylan's viability as a production language. To achieve good performance, the Dylan environment will produce a runtime executable that seems (to this observer) similar in concept to the way Component Software "extrudes" an executable, stripping away unnecessary flexibility. In Dylan you can selectively eliminate dynamic typing, reflectivity, dynamic linking, dynamic subclassing, and runtime redefinition for specified parts of later date. Unfortunately, that loss of flexibility is a necessary price for performance.

But is it fast? John believes that Dylan programs will have a 15% performance penalty over equivalent C++ programs. In my view, that's an acceptable price. I wish MacApp charged a mere 15% penalty. We have yet to see, however, if John's assertion is true.

So now I have to learn LISP?

Dylan is still being defined, and the people at ATG East are considering putting an ALGOL-like syntax on top of Dylan. The purists will scream, but it will make Dylan more acceptable to the blue-collar, beer-guzzling coders like you and me. ATG takes seriously their job of appealing to us. They will consider this project a failure if Dylan is yet another intriguing academic language that fails to gain a popular appeal.

Can I use MacApp or Bedrock?

How Dylan will connect to an application framework is still unknown. Bedrock would probably appear as a class library to Dylan even though Bedrock will be written in C++, much as you can access MacApp 3.0 from Object Pascal.

John made it clear that as object-oriented programmers, MacApp'ers are their natural constituency. Dylan is not yet available and Apple is not saying when it will be available, but they're publishing a manual and for now at least, the manual is free. Send a message to "dylan-manual-request@cambridge.apple.com". Look the manual over and send your comments to "info-dylan-request@cambridge.apple.com".

Organizational Business

Bill Clinton was not the only one elected to a leadership position this fall. Russ Brenner was confirmed as Chairman of NEMADA, Heeren Pathak was elected Vice-Chairman, and I retained my duty to entertain you in this column. All candidates ran unopposed.

Our November meeting was canceled, but in December we may be hosting Jeff Alger of SBM fame. I've attended Jeff's lectures in the past and I know him to be an exciting and outspoken speaker with a tremendous knowledge of OOP issues. See you at the next meeting.