Channels ▼
RSS

The MIT Lightweight Languages Workshop


Feb02: The MIT Lightweight Languages Workshop

Eugene is a freelance programmer and writer, and founder of the Open Hyperdocument System Launch Community (http://www.eekim.com/ohs/). He can be contacted at eekim@eekim.com.


Organized by the Dynamic Languages Group at the Massachusetts Institute of Technology's Artificial Intelligence Lab and cosponsored by Dr. Dobb's Journal, the primary purpose of the Lightweight Languages Workshop was to bring together programming language implementors from industry and programming language researchers from academia, put them all in the same room, and spark some lively discussion. Just to see how lively those discussions would be, Eugene Eric Kim attended the workshop and filed this report. Additionally, DDJ is webcasting portions of the workshop via our TechNetCast service at http://www.ddj.com/technetcast/.

— Editors


Several months ago, in the hallowed halls of MIT's legendary Artificial Intelligence Lab, researchers Greg Sullivan and Mike Salib were practicing a time-honored academic tradition — complaining.

Why, they asked, are mainstream languages so conservative? Why had interesting and useful research in areas such as garbage collection only recently crept into mainstream languages? And why, they sulked, don't language designers listen to academics? For that matter, why do designers struggle to add features such as lexical scoping and closures after the fact, when they should have designed these features into their languages from the start?

To satisfy their curiosity and encourage collaboration between different language communities, Sullivan and Salib organized the Lightweight Languages Workshop (http://ll1.mit.edu/), held at MIT's AI Lab. Approximately 80 people attended the workshop, and although several languages — from Scheme and Dylan to Perl and Python — were represented, Lisp T-shirts were the dominant apparel. While the presentations were deeply technical, the discussions were as much about philosophy as about computer science.

Is Worse Better?

In many ways, Richard Gabriel's notion of "Worse Is Better" versus "The Right Thing" was the dominant theme of the workshop. In 1990, Gabriel wrote an essay (http://www.dreamsongs.com/WorseIsBetter.html) that described two approaches to software development. His thesis was that software should start small and evolve according to the needs of its users. Although the result might not be necessarily pretty, it has greater odds of surviving and even flourishing.

Guy Steele, Dan Weinreb, Jeremy Hylton, Ken Anderson, and Simon Cozens.

The first panel discussion was devoted entirely to Gabriel's thesis. Panelists included legendary language guru Guy Steele, Symbolics cofounder Dan Weinreb, Python developer Jeremy Hylton, language developer Ken Anderson, and Perl developer Simon Cozens.

All of the panelists seemed to agree on the categories in which their respective languages fell. Both Cozens and Hylton, for example, willingly classified Perl and Python as "Worse Is Better" languages. All of the panelists also agreed that tool availability and timing played as much of a role in a language's success as the language itself. And most of them seemed to agree with Gabriel's overall premise.

Weinreb was the sole exception. He challenged the dichotomy between "The Right Thing" and "Worse Is Better," noting that designers and users had different value systems, and that what designers consider "right" may not have any relevance to what the user wants or needs.

Weinreb also posed the question, "What constitutes release 1.0?" In other words, should a language be judged for its incompleteness, when over time, those omissions may go away? He pointed out that Java 1.0 did not include features he felt were important, such as generics, but that they are currently being added to the language. Had Sun postponed release 1.0 until those features were implemented, Java might have missed its opportunity for success. As it stands, features like generics are currently being added back into the language.

Programmers as Language Designers

A point echoed throughout the day was that all programmers are actually language designers, regardless of whether they are aware of it. Defining new functions, for instance, is equivalent to expanding a language's vocabulary, and as a result, programmers face many of the same issues as language designers. What constitutes a good function name? How long should the name be?

On a deeper level, one of the defining attributes of lightweight languages is that they are dynamic. Several presenters observed that programmers should take advantage of the compiler that comes built-in for them in most dynamic languages.

Olin Shivers, a professor of computer science at Georgia Tech and author of scsh (Scheme shell; http://www.swiss.ai.mit.edu/ftpdir/scsh/), made a cogent argument for embedding "little languages" — task-specific notations such as awk and yacc — into lightweight languages, namely, Scheme.

Little language designers usually develop useful syntax for the task at hand, then often find themselves reinventing basic linguistic elements such as control statements. Shivers demonstrated how Scheme macros let designers add new syntax to Scheme while obviating the need to reinvent basic constructs by embedding an awk library into Scheme. He also contrasted his strategy for little language design with the UNIX approach, noting that embedding multiple little languages into Scheme allowed all of these languages to access data structures directly.

Shriram Krishnamurthi.

Shriram Krishnamurthi also evangelized the ability to redefine Scheme's syntax using macros. In one of the most engaging and spirited talks of the day, Krishnamurthi talked about the work his group — PLT, a research effort spanning several universities (http://www.plt-scheme.org/) — was doing with the Scheme language. He first explained how Scheme could be just as practical a language as Perl or Python, mentioning PLT's work on integrated development environments, debuggers, documentation, and libraries.

Krishnamurthi then explained why he thought Scheme was beautiful. He presented a toy example of recognizing patterns in a stream of characters, showed the finite state machine that solved this problem, and then explained several different ways to implement the state machine. The punchline was that the state machine could be implemented in Scheme almost exactly as written, using a little careful thought and Scheme macros.






Picking on Perl

Dan Sugalski.

Most of the talks were relatively uncontroversial. However, during the Simon Cozens and Dan Sugalski presentation on Perl 6, the clash of cultures quickly became apparent. Cozens and Sugalski gave an excellent summary of Perl 6's run-time engine, but their interaction with the audience was awkward, and the ensuing discussion, although reasoned, was heated.

Several attendees noted during the talk that the Perl community seemed to be reinventing the wheel in areas such as virtual-machine implementations and garbage collection. At times, the feedback included some not-so-subtle barbs. To their credit, Cozens and Sugalski accepted this feedback gracefully, requesting URLs so that they could examine the appropriate papers themselves.

Unfortunately, they occasionally inadvertently incited the crowd with their flippant remarks. Sugalski, for example, explained that Perl's run-time engine needed to support a number of high-level programming concepts, and he showed a slide that listed some of them. When coming across "continuations" on his slide, he said, "Let's skip that. I don't really understand them." Gasps were heard throughout the room, as Sugalski's blunt confession seemed to be proof that "Worse Is Better" communities were indeed ignorant of computer science.

Sugalski also stated that, for academics, "Perl is not very interesting." Although several members of the audience nodded in agreement, it was an unfortunate claim to make, because it was clear that neither Sugalski nor Cozens really knew what academics were interested in.

Jeremy Hylton and Waldemar Horwat received considerably less heat than their Perl peers, even though their respective languages — Python and JavaScript — were also acknowledged as "Worse Is Better" languages. Perhaps not coincidentally, both are MIT graduates and both related easily to the audience. Hylton talked about his efforts to fix scoping issues in Python, while Horwat described how JavaScript dealt with different class versions using namespaces. Horwat also demonstrated a Common LISP engine for specifying, verifying, and documenting JavaScript semantics.

Joe Marshall's talk on REBOL, while well received, was a classic case of "The Right Thing." Marshall, the main implementor of the first version of REBOL (see "The REBOL Scripting Language," by Carl Sassenrath, DDJ, July 2000) explained that the language has very little syntax, which makes it difficult to implement tail recursion. He then described how he solved the problem. When asked why he designed REBOL the way he did, Marshall responded, "I like writing languages." Marshall also added that many of the features in the first version of REBOL were omitted in the second, including his tail-recursion implementation.

Other Languages

The afternoon's talks consisted of Jonathan Bachrach on Proto, Christopher Barber on Curl, and David Simmons on SmallScript (http://www.smallscript.net/). Bachrach was one of the developers of Dylan (see "The Dylan Programming Language," by Tamme D. Bowen and Kelly M. Hall, DDJ Special Issue on Alternative Programming Languages, 1994), and his goal for Proto is to develop a research and teaching vehicle specifically targeted towards real-time systems. Curl is a Lisp-like language for developing client-side web content (see "The Curl Programming Environment," by Friedger Müffke, DDJ, September 2001). Barber focused his discussion on Curl's component model. Simmons described his SmallScript language, a subset of Smalltalk whose run time relies entirely on JITs.

Paul Graham.

Paul Graham softened the mood at the end of the day with an entertaining and insightful presentation on Arc (http://www.paulgraham.com/paulgraham/arc.html). Graham founded Viaweb — which was acquired by Yahoo! and became Yahoo! Stores — and he had written much of the software in Lisp. He observed that the advent of server-side applications freed programmers to use whatever languages they wished. He also observed that there hadn't been a new dialect of Lisp since the mid 1980s, and that the present seemed as good a time as any to develop one.

Graham is developing Arc specifically for web development, and one of his requirements is that the language be fast. One of his colleagues had remarked that with Lisp, it was hard to tell whether the code was expensive. Graham responded that this was really the role of a profiler, not the language itself. However, to be complete, Arc would have to have a profiler, echoing the earlier workshop sentiments about the importance of tools.

Confessing that he had only been working on the language for about two weeks and that all features were subject to change, Graham proceeded to present what did exist. A number of Arc's features were aesthetic. For example, inspired by Perl's brevity, he chose to shorten some of Lisp's function names, such as "lambda" to "fn."

The Future

The workshop closed with a panel discussion on the future of lightweight languages. Panelists included Bruce Lewis (creator of the BRL2 reporting language), Sugalski, Graham, Bachrach, and Shivers. Shivers expounded on a number of topics, ranging from the robustness of software to the importance of engineering. He then stated that little languages would play an important role in all of these topics. Although little languages are restricted in power, they make up for that by being easier to analyze. Hence, they can be used to build more robust systems.

Jonathan Bachrach, one of the key developers of Dylan and of the new language Proto (http://www.ai.mit.edu/~jrb/proto/), presented a laundry list of items he wanted to see addressed in the future. Several of his items stood out because they suggested that innovation was possible where many had stopped looking. He told the audience that the Lisp macro system is not the last story, that Prolog is not the end-all-and-be-all of constraint-based languages, and that there needs to be something better for writing code than emacs.

The workshop was intense and productive. However, examined in light of Sullivan and Salib's hope for cross fertilization of ideas, one thing was glaringly apparent — collaboration requires communication, and communication requires cultural understanding. Unfortunately, the latter is lacking, as was evident during the Perl talk.

Cozens and Sugalski are well respected in the Perl community, but the quality of interaction would have been much different had someone better versed in functional languages — such as Perl creator Larry Wall — attended. At the same time, the two were unfairly, if indirectly, attacked for not being part of the community predominantly represented at the workshop.

Members of "Worse Is Better" communities need to do a better job of utilizing and contributing to the academic system for disseminating knowledge. At the same time, members of "The Right Thing" community need to understand that there is in fact much to be learned from other languages, despite the lack of S-expressions and parenthetical syntax.

Fortunately, the will to collaborate is clearly shared, and the workshop did much to facilitate this by simply bringing these researchers together in one room. Many of the most interesting discussions occurred between presentations, during lunch, and after the workshop over liquid nitrogen ice cream, and they continue even now on the workshop's mailing lists.

DDJ


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video