Dynamic Languages Symposium (DLS) (JOT repost)

Today (now yesterday) I will mainly be attending the DLS, with intermissions at PLATEAU.

Almost unbelievably, the wifi works really well. It's been a while since I've been at a conference with really good wifi, but the Nugget seems to have cracked it, fingers crossed that it'll last.


Invited talk - Smalltalk Virtual Machines to JavaScript Engines: Perspectives on Mainstreaming Dynamic Languages - Allen Wirfs-Brock

The theme of this talk is how to get dynamic languages into the mainstream. The talk started well with some interesting general points on implementing dynamic languages, and ended well with some observations on the current generations of Javascript interpreters, but most of the talk was a retrospective of Smalltalk.

An early point was that performance is important for dynamic language take up. As much as language designers and programming guides state that design (of the language or program) must come first, if a language's runtime performance is not good enough for a given task, it will not be used. Another early point was that virtual machine implementors got blinded by the metaphor - a VM is not a machine, it is a language implementation, and must be coded like one.

Allen gave an impressive Smalltalk demo, running Smalltalk from 1984 on a machine of the day, which practically ran on steam. It was an interactive graphical demo and the performance was very impressive (in fact, the computer was pretty high powered for the time, but it was impressive nonetheless).

More of Allen's observations: holistic design gives high performance, tweaks to an existing VM will not get you very far (therefore, he is not a fan of trying to extend the JVM to dynamic languages); optimising fast paths is fine, but don't let the exceptional paths get too slow, it is probably these that makes the language special; methodologies are required to enable language adoption.

Most of the Smalltalk stuff was fairly typical, but the analysis of its death was more interesting: Smalltalk was going guns blazing in '95, but was effectively dead by '97. His analysis was that Smalltalk was a fad, never a mainstream language (which sounds right to me, not that it was bad language mind, but its influence in academic language research seems much higher than its influence in real life). One reason for this demise is that the 'Smalltalk people' expended way too much energy on GUI systems that nobody actually used, and not enough energy on real problems.

Another interesting analysis was on why Java succeeded, reasons given included: familiar syntax, conventional tools, the network effect, etc. It seems to me that people always try to find excuses for Java's success (although those points are obviously true); maybe Java was actually a good language that fit the needs of the time better than other languages?

A slight tangent was that Java is essentially a manually dynamically typed language; that is, casts are manual dynamic typing.

We then got back into the good stuff. Javascript was assumed to be inherently slow, then V8 (Google) showed that Javascript could be fast. Fast Javascript is important for the web, which means computing in general nowadays. You only need to look at the competition between browsers to see that Javascript performance is important. This reminded me that I think that Javascript engines are possibly the coolest and most interesting language engineering happening at the moment, and sadly it is not happening in academia (Allen suggested we need a research browser, which would be nice, but seems unlikely to come about).

Some of Allen's observations on Javascript VMs: most teams are still on their first or second tries (earlier in the talk, Allen stated that it takes three goes to get good at VMs) - things are going to get much better; performance is still low compared to Smalltalk in '95(!); Sunspider is not a great benchmark and is holding back proper evaluation and development; Javascript is harder to make fast than Smalltalk (because it is more dynamic), new ideas are needed to get more speed; Allen wandered why all the Javascript VMs use so much memory; the Javascript engine needs to be part of an holistic browser design to get good performance; Javascript seems to be the mainstream; Javascript performance is at the beginning, not the end.

The talk ended by reminding us that ambient/ubiquitous computing is here, and suggested that dynamic languages were going to be part of that era. He didn't explain why, however.


Meanwhile, at PLATEAU - GoHotDraw: Evaluating the Go Programming Language with Design Patterns - Frank Schmager

Frank Schmager presented work he has done with James Noble and I on evaluating the Go programming language using design patterns. This is a novel idea for evaluating programming languages, and hopefully a new tool in the language evaluation toolbox. Apparently he gave a very good talk, go Frank! (sorry for that pun)


PLATEAU invited talk - The Fitness Function for Programming Languages: A Matter of Taste? - Gilad Bracha

For the second session, I attended Gilad Bracha's invited talk at PLATEAU. Gilad always gives interesting and entertaining talks, and this was no exception.

"There are two kinds of languages - those that everyone complains about and those that aren't used"
--- Bjorn Stroustrup

Gilad's talk was about how to judge a language. He argued that there was more to a language's success than popularity, that in fifty years time we will look back and certain languages will be admired, and others won't. Furthermore, success is really mostly down to the network effect (or the sheep effect, as Gilad called it); and that the most successful languages follow the Swiss Army Knife approach (aka the kitchen sink approach aka the postmodern approach) to language design, which generally, it is agreed, is not elegant or 'great'. So is it possible to define what makes a language great? Or is it just a matter of taste?

There were a couple of tangents on parser combinators and first-class pattern matching in Newspeak (Gilad's language project).

Some criteria for greatness (or lack of it) were suggested: how much syntactic overhead is there in the language (such as unnecessary brackets, semicolons), does the language force attention on the irrelevant (e.g., on the low level in a non-systems language), how compositional is the language. Gilad asked if languages can be judged as theories (where programs are models of the theory), criteria here were consistency, comprehensiveness, and predictive value (which for languages means how hard is it to write a given program).

An interesting observation was that the most common actions in a language have no syntax (or actually no syntactic overhead), e.g., function application in functional languages, method call in Smalltalk.

Another observation on evaluating languages is that we often try to measure how hard a language is to learn. Gilad argued that ease of learning is not an indicator of greatness. He uses Newton's calculus as an allegory - it is widely hated for being difficult to learn, but is truly a great contribution to science.

Finally, Gilad stated that good aesthetics makes good software, that strict criteria for evaluating a language are not ideal, and that quality is more important than market share.

There was a big debate in the question session afterwards, covering how to judge a language, how to review programming language papers and the review process in general, cognitive theories, and even maths vs. art.


Proxies: Design Principles for Robust Object-oriented Intercession APIs - Tom Van Cutsem

Back at the DLS, Tom talked about implementing intercession (that is, intercepting method calls) in Javascript. Unlike some scripting languages, this is surprisingly difficult in Javascript. He described a technique to do it using proxy objects.


Contracts for First-Class Classes - T. Stephen Strickland

The last talk of the day was on contracts in Racket, specifically on and using first-class classes. (By the way, Racket is the new name for PLT Scheme, I assumed I was the only one who didn't realise this, but a few other people admitted their confusion later. Why did they change the name?) Not being a Lisp fan, I found the examples very hard to read - too many brackets! Anyway, Stephen (or T?) described Eiffel-style contracts (pre- and post-conditions). These can be added using first-class classes (in the same way that methods can be added to classes). He showed that object contracts were still required in some circumstances (as well as class contracts), and showed how these were implemented using class contracts on new classes and proxies to make the old and new classes work together.