by Larry Tesler
In the mid-1980s, a number of researchers in Apples Advanced Technology Group (ATG) discovered that exploration of their software ideas was increasingly constrained by languages and tools. They migrated a significant number of projects from Object Pascal, C, and C++ to Smalltalk, Lisp, and various knowledge-engineering environments.
Soon management became concerned that technologies developed in these unrelated environments would not be able to play together. Boldly, we proposed adoption of a single dynamic programming environment throughout the group. The goal was acknowledged, but we soon found that none of the environments we were using could meet every need. For some projects, Common Lisp was too big. For others, Smalltalk-80s simplicity was limiting. And of course, there were forcefully stated differences in personal preference.
Humbled, we decided to search outside the company for an environment that satisfied all requirementsat least technical considerations, if not matters of taste. We encountered some interesting languages, including Eiffel, Self, Beta, and OakLisp, to name just a few, but we could find no environment that met our requirements.
Reluctantly, we entertained the thought of designing yet another language. We envisioned a language that would:
combine the best aspects of Lisp and Smalltalk
provide static language users an attractive dynamic alternative
be practical on small machines
provide high dynamism during rapid prototyping and development
provide tools to achieve commercial performance in production code
During this exercise, we were approached by an Apple engineering group seeking an object-oriented dynamic language for a contemplated product. Instead of developing a language just for research, we agreed that ATG would strive to create a system practical for delivery of commercial applications.
After some analysis, we concluded that a language that would meet all our requirements would be more like Lisp than Smalltalk, except that, like Smalltalk, it would be objects all the way down. By providing alternate syntaxes atop the extremely neutral base of Lisp, we believed we could present a familiar face not only to Lisp programmers, but also to those accustomed to other syntaxes, including Smalltalks.
We felt we could not design a good language without concurrently implementing it. But we did not have the skills in house to implement the kind of language we envisioned. Around that time we were approached by Massachusetts-based Coral Software, Inc., which was seeking to be acquired. Coral had created a popular Common Lisp implementation distinguished by its small memory footprint, very usable speed, interesting object system, and thorough integration into the Macintosh. A few months later, we acquired the assets of the company, hired most of the staff, and created ATG East in Cambridge.
We asked the new group to accept two challenges: (1) continue to develop their Common Lisp implementation, adding CLOS, ephemeral garbage collection, and other features; and (2) develop a new language and environment meeting the aforementioned requirements. They accepted both challenges. The first led to the very popular product known as Macintosh Common Lisp (MCL) 2.0. The second led to Dylan.
Dylan is not yet a frozen language. Debates about proposed improvements continue. But enough of Dylan has been designed, implemented, and experienced that now is the time to take it public and benefit from the wisdom of a wider programming community. We welcome your comments.
Next chapter: Preface