January 93 - NEMADA News
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.