OOPSLA day 1 (JOT repost)

OOPSLA proper starts today. William Cook gave a mercifully short introduction and then we were straight into the first ever SPLASH invited talk, on evolving software by Stephanie Forrest. After the break, I attended the Onward! research paper stream, then after lunch an OOPSLA session, and the panel in the last session.


Registration-Based Language Abstractions - Samuel Davis

Samuel presented a method for adding language constructs to a language. These constructs are outside of the language, but also outside of the source code, so each programmer can have their own personal version of a programming language and the tool will present code using the right constructs. It seems like a very sophisticated macro system to me, but with better tool support (I don't mean this in a derogatory way, the system is obviously more powerful and useful than macros, I just mean it as a simile).


I attended, enjoyed and found interesting two talks - Pinocchio: Bringing Reflection to Life with First-class Interpreters presented by Toon Verwaest, and Lime: A Java-Compatible and Synthesizable Language for Heterogeneous Architectures presented by Joshua Auerbach. I'm afraid I can't say much about either of them, but they were good talks and I'll try to read both papers.


From OO to FPGA: Fitting Round Objects into Square Hardware? - Jens Palsberg

A talk on compiling high-level languages to FPGAs, the challenge is to compile a standard OO program to an FPGA. Currently code written in a small subset of C can be compiled to FPGAs, but hand-coded FPGA code is better (faster, less area, smaller energy consumption). The general technique presented is to compile from Virgil to C and then to FPGAs. Unfortunately, the C subset is so small (no pointers, etc.) that objects cannot be compiled in the usual way.

The authors used a mix of existing compilation techniques with some new ideas of their own. Essentially they compile objects to sparse integer arrays, but must then expend a lot of effort in compressing these tables.

They have experimental results which show slightly better performance for their tool chain than for the hand-tuned version (for the non-oo case). In the OO case, it is harder to compare (no-one else has done it), but by interpreting performance results from CPU execution, they reason that their tool gives good results here too.

An interesting challenge which emerged in the questions, is producing an intermediate language for compilation to FPGAs that preserves parallelisation, as opposed to C which 'flattens' away any parallel code into sequential code.


Panel - Manifesto: a New Educational Programming Language

For the last session of the day, I attended the panel session on a proposed new programming language, aimed at first year university students. The language is called Grace (http://gracelang.org), it is proposed to be a community effort, with a semi-open development process and this panel was an effort to get the community behind it. Grace will be a general purpose (as opposed to domain specific) language, designed for novices (so no fancy type system), and deigned for programming in the small (so no fancy module system). It will not be industrial strength, therefore it will not need to be backward compatible, and should have low overhead for small programs (no "public static void main").

The proposers argued that the time is right: Java will be good for the next few years, but is getting big and a bit long in the tooth. Alex Buckley (Java "theologist", also on the panel, but not associated with Grace) did not disagree, but did say that Java would have a lot of the features discussed in a few years time (which means it might not look so old but will be even bigger).

The proposers (James Noble, Andrew Black, and Kim Bruce) have ambitious goals: Grace should be multi-platform, multi-paradigm (it should support teaching with or without objects, with or without types, in a functional or procedural style), it should be useful for teaching first and second years how to program, and for data structures courses. With Smalltalk never far below the surface, it was declared that everything would be an object, although it was not stated what was meant by "everything". The proposers proposed that Grace have a powerful extension/library system for adding in things like concurrency, basically because we don't know the best way to do concurrency right now. This seems a big ask, one thing the concurrency community mostly agress on is that concurrency cannot be added on afterwards, it must be holistically baked in.

It sounds to me like a great idea - an academic, community based teaching language should be much better suited for purpose than a professional programming language. But, to be honest, the session did not have very much buzz. The panel itself was obviously excited about the project, the audience less so. There were no great questions from the floor, or any really exciting debate. The lengthiest discussion was about the relative merits of the PLT group's book/language/curriculumn. On the other hand no one really disagreed that there was a gap in the market for such a language. I'm interested to find out if the proposers got encouraging words after the session. (Disclaimer: I skipped the last half hour to attend a research talk, so the session might have lit up then and I would have missed it.)

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.

FOOL (JOT repost)

First day of the conference I attended the FOOL workshop. This used to be one of my favourite workshops, it always seemed to have high quality, interesting papers. It used to be held at POPL, but was cancelled last year. It has now been resurrected at OOPSLA and looks to be just as good as it's ever been. The following talks were the highlights for me.

DeepFJig - Modular composition of nested classes - Marco Servetto

FJig is a formalisation of the Jigsaw language, which focuses on mixins and 'class' composition. This work extends FJig with an extension to nested classes. I believe that virtual nested classes are the most significant change to the OO paradigm currently being proposed. Being able to abstract and inherit at the level of class families, rather than just individual classes, solves an awful lot of problems with the usual class model. Thus, I'm happy to see another take on the idea.

From what I gathered, DeepFJig only supports 'static' nesting of classes, this makes the type system simple (no path dependent types, or exact types required), but at the expense of a lot of the benefits of virtual classes. The interesting thing here is that by combining nested classes with the mixin composition operators found in FJig, you get a great deal of expressivity - Marco showed how to encode generics (in a virtual types style) and aspects (yes, aspects, as in AOP). This latter probably means that the language is too expressive for some software engineering purposes, but it wasn't clear from the talk how much you can sabotage classes, as you can usually do when using aspects.


Lightweight Nested Inheritance in Layer Decomposition - Tetsuo Kamina

Another nested classes paper, this time extending the 'Lightweight Nested Inheritance' (J&) concept. LNI uses paths of class names and exact class names to identify types. This work extends that with generics so that types can be more precisely specified. However, it seems that you only bite back some of the expressivity lost when compared with systems such as VC and Tribe (which have dependent path types). So, it is a slightly more heavyweight lightweight version of nested class types. The interesting aspect is that type variables can be used as type constructors for path types (but not generics types, i.e., X.C is OK, but X is not). I guess that if you assume that you are going to have generics in such a language anyway, then getting this extra expressivity is nice. However, I am not entirely convinced that the result is much more lightweight than the path dependent approach.


Mojojojo - More Ownership for Multiple Owners - Paley Li

Paley presented work he has done with James Noble and I on Multiple Ownership type systems. Multiple Ownership was proposed at OOPSLA '07, but the formalisation was unwieldy. This work presents a simpler, more elegant, and more powerful formalisation of the Multiple Ownership concept.

Traditional ownership types systems give each object a single owner, this organises the heap into a tree, which is great for reasoning about programs. Unfortunately, real programs rarely fall nicely into a runtime tree structure, so more flexible ways to organise the heap are required. Multiple Ownership allows each object to be owned by multiple owners, thus organising the heap into a DAG.

Mojojojo (if you don't get the name, Google for the Powerpuff Girls) adds a powerful system of constraints over the structure of the heap, generics, existential quantification, and a host of small improvements to the formal system, resulting in something a lot nicer than MOJO. Paley gave a great talk, and I recommend you all read the paper (totally unbiased opinion, of course :-) ).


Interoperability in a Scripted World: Putting Inheritance & Prototypes Together - Kathryn E. Gray

More work on integrating typed and untyped languages, which seems to be very fashionable right now. This work focuses on making Java and Javascript work together, rather than focusing on type checking. The most interesting bit is making prototyping and inheritance work together in the same world.

I'm sorry I cannot write more about this paper, because it sounds really interesting, but I was a bit distracted at the beginning of the talk, and never quite got back into the flow. I'll be reading the paper later though...


Adding Pattern Matching to Existing Object-Oriented Languages - Changhee Park

Changhee talked about adding pattern matching to Fortress (which reminds me to check on what is happening with Fortress nowadays). In fact one of the more interesting bits of the talk was the generalisation - the requirements on a language such that it can support pattern matching in the way described.

The general idea of the work is to support ADT-style decomposition of types by subtype using a typecase expression and function parameters and decomposition of objects into its fields, similarly to how tuples are decomposed in Python etc. What I thought was missing was a discussion of whether or not you would actually want to do this: you are breaking object-based encapsulation, which most languages avoid.

Registration

Things are looking up at registration: registration was very quick and efficient, the conference pack was pretty streamlined - no conference bag and not too much spam, which is great - I dislike the amount of waste most conferences generate. There is wifi in the lobby and conference rooms (yay!), and the gift was the cutest set of rainbow mini highlighters, which is a nice change from a USB stick, although not as practical.

Looking through the program is pretty exciting, there seems to be a lot of good-sounding papers and invited talks. The organisers also seem to have managed the scheduling well - despite three concurrent sessions at most times, there is not a single clash between talks I'd like to attend; Thursday's invited talk does seem to clash with lunch, however, not sure how well that is going to work out.

First Impressions of Reno and OOPSLA/SPLASH (JOT repost)

Hi, I'm Nick Cameron, a post-doc at Victoria University of Wellington. I'm going to be covering the SPLASH/OOPSLA conference for the JOT blog.

It should be an interesting year for OOPSLA: it has undergone re-branding from OOPSLA to SPLASH (a re-arrangement of the OOPSLA letters, minus OO (because who programs with objects any more?), and appended with "for Humanity" (cringe)). The research paper selection process has changed too, they introduced `white-ball' papers (each member of the PC can select one paper to be accepted without argument), and there were slightly more papers accepted than in previous years (including mine, so I can't really complain; Thursday afternoon, if you're interested). The payment structure has changed too: you have to register and pay for individual workshops, I can't comprehend why - the best thing about workshops is wandering between them.

Anyway, after twenty-odd hours on a plane from NZ, we started our descent into Reno, we got a birds-eye view of the Nugget (the conference venue and hotel) as we came in - sandwiched between the expressway and a railway yard, it did not look good. Reno airport was like a gateway into hell, slot machines everywhere and a backdrop of billboards for "gentleman's clubs".

The conference venue is almost comically grim. The main floor is a sea of slot machines and haggard looking people. There are a lot of cowboy hats around, and not in an ironic way. No-one looks happy to be here, mostly people look desperate, or just plain chewed up. People smoke a lot, indoors, which seems a bit odd in 2010. There is a patched motorcycle gang drinking in the lobby (seriously, this is not an exaggeration).

If I had to describe Sparks, and the Nugget, in a word, it would be "grim". I don't think I have ever been so disappointed in the location of a conference. I hope (and expect) the conference itself to be excellent, it will have to be to justify enduring this place for a week. On the bright side lots of interesting people are arriving, and the free wifi at Starbucks has become a natural hub...

OOPSLA report

I'm at the OOPSLA/SPALSH confernce in the charming city of Reno, NV. The highlight so far has been shooting high powered firearms in the desert next to a decomposing horse corpse. I am blogging the event for JOT (link coming soon), but I'll repost my reports here.