On Nov 17th I crashed the LL1: Lightweight Languages Workshop and found a small technical conference packed with experts politely containing flaming over language wars (not really, they were all quite polite).

It was called by Greg Sullivan and Mike Salib at MIT to share information about the design and implementation of "task specific" languages, or languages that are easy to acquire, learn, and use.  But it was also a venue for indy languages, and to transfer research in programming languages over the last 20 years (lisp, scheme) to those who are actually implementing them (perl, python, javascript, etc.).

I only sat through the beginning and end of this conference and missed some interesting discussions, but here are my notes. Hopefully Dr. Dobb's will post the recorded sessions soon?

First up was Olin Shivers on Lambda, the Ultimate Little Language. The broad point is that a syntactically extensible language like Scheme is the perfect little language to base other languages on. His example was the Unix shell. While the shell has a language in itself and is able to glue, through pipes and redirects, a bunch of other little languages (awk, sed, grep, wc, etc.), it is all rather busted and prone to errors.

The problem with gluing other languages in the unix shell style is idiosyncratic nature, where each tool has their own bizarre syntax (white space in make anyone?), the basic linguistic elements are constantly re-invented and re-implemented, and there is an arms length interconnection between the tools.

With Scheme, the alternative approach, these little languages could be embedded in a syntactically extensible, well designed general language, add only the task specific elements, inherit the general programming glue, and leverage existing work.

The embedding methodology: functionally decompose the system, embed grammar in common sexp framework, capture control and environment structure as macros, and provide cross coupling in Scheme. As he said "everyone is a compiler writer".  He made his point well by walking us through his implementation of AWK in Scheme, and showing it used in scsh, the Scheme shell he developed.

Somehow it's seemed too easy to make his point given that he presumed everybody would adopt a common syntax and underlying semantics. Some asked, "was it reasonable to expect unification at the syntax level and different semantics in it?" And, "don't forget performance, other languages (Prolog) optimize just one thing really well and get much better speed".

Off line he said that "people do have issues with Scheme", "it's hard to do static analysis in Scheme", and that in the end, to develop a language or tool like scsh requires to pull a Larry Wall and take a year off to develop it. Academics can't afford to do this.

So this line of thinking, while beautiful, seemed dead on arrival because the very people that could seed a community with better tools and languages couldn't take the time or get organized to make sure their tools were adopted. While the Microsofts of the world (wait, there is only one such company!) would know how to compete and get their tools adopted instead.

The MIT camp vs. the New Jersey camp

Next up was the panel on Worse is Better. Each panelist made their two-minute statement and then it was a free for all.

First up was Simon Cozens: Worse is better - it allows for bugs, correctness can be considered harmful. In the case of Perl 5: "if worse is better, worst is beautiful". The "worse" approach breeds flexibility, but also unmaintainability; only 4 people understand the Perl regex engine. And he closed by asking "why is doing the right thing opposed to doing the fast thing?". (Also check his summary of LL1.)

Dan Winreb tilted towards the MIT camp by pointing out that in the end we pay more for using today's languages in the long run; e.g. we still have CERT advisories for buffer overflow bugs. Sometimes we ignore using hybrid languages. We need to break the silence of the l people!

Jeremy Hylton reviewed the Python design philosophy (from it's humor page):

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren't special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one-- and preferably only one --obvious way to do it.
• Although that way may not be obvious at first unless you're Dutch.
• Now is better than never.
• Although never is often better than *right* now.
• If the implementation is hard to explain, it's a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea -- let's do more of those!

Dan Winreb's view that language choice is just a cost benefit tradeoff. The first mover advantage has some truths to it, but not all, otherwise we would all be programming in FORTRAN (the implication being that introducing new languages is clearly possible). The network effects of language adoption are more important. Introducing a new language is a combination of opportunity and luck.

Guy Steele's position was that slightly worse is better. What was important was "Growing a Language", planning for a language design as a process, designing a growth track. (Someone said) "A data structure is a stupid programming language", and he gave TeX as an example: for the longest time Knuth wanted to maintain it as a markup language, but then some more constructs got in there and someone was able to program Tic-Tac-Toe in TeX! The Guy Steele corollary to this is that a programming language is a very dangerous data structure, and gave viruses and worms as examples. There may be some limits that we want to impose on ourselves.

And unfortunately I had to cut out here ... so I missed the brawl, although I heard it was rather civil. I only resurfaced at the end of Waldermar Horwat was concluding his talk on the design of JavaScript 2.0 . The interesting work for me was his extended typed lambda calculus in Common Lisp to specify the language. Someone asked why JS was not implemented in itself, an obvious ribbing, but Waldemar explained that there are some feedback loops between the lexer and the parser to deal with regular expressions that didn't make that possible.

Jonathan Bachrach, with Eric Kidd, introduced their Proto programming language. The design philosophy builds on his experiences with Dylan, which was a reaction to the evolution of Lisp. One of his conclusions was that complexity is dangerous to your health, it will bite you at every turn; you want to minimize the number of moving parts. I liked his design principle that major portions of the language should be documented in 10 pages and implemented in 10K LOC (lines of code); you have to think harder to make things smaller and you can get some real gems in the process. A pre OO language with multimethods nominally aimed at the music domain that will eventually target C--

David Simmons covered SmallScript. He seemed to have much respect from this community for his development of VM's over the last 10 years, but I learned much more from him off-line. His language seemed to be the only one targeting .NET, for which he had good things to say.

Paul Graham introduced his three-week-old language ARC. You should just look at his slides on his great talk. His principle was to design a language for good programmers. If it works out, developers will just see it as the luxury good that everybody wants and they will want it, but we'll see.

The final panel on What's Next? closed the workshop. Jonathan was not convinced that lisp + macros is it. Constraint languages will grow; Prolog won't be the last one. "Let's write the interpreter and get the compiler for free", and "why are we stuck with emacs?". Paul Graham thought performance and speed matters on servers so there is new turf for new languages, but the more people you rope in the worse it gets. Olin Shivers liked that little languages allow you to restrict the power of expressiveness, which allows you to make it more tractable.

The pictures above are from the ice-cream-from-liquid-nitrogen party afterwards. That's my rough capture of a great day in languages. I hope to hear more on the topic.