It is a truth universally acknowledged, that a computer scientist in possession of a good idea, must be in want of a catchy phrase to frame it. It appears that ‘language orientated programming’ (originally defined by Martin Ward) is such a phrase, but I’d like to look a little beyond the phrase to get a glimpse of the underlying idea.
Essentially the idea is to allow certain aspects of a program to be expressed via small Domain Specific Languages (DSLs). A DSL should allow a certain concept to be expressed succinctly and naturally - in other words writing something intended for that DSL should be easier in the DSL than writing the same thing in a General Purpose Language (GPL).
Most of us are familiar with DSLs through programs like make which bite off a small problem domain and (hopefully) provide a good solution for it. Such DSLs tend to be somewhat stand alone though - one cannot integrate the DSL into a main program very easily. This often leads to bizarre kludges when we wish to integrate two languages - perhaps the classic example is the horror of embedding SQL commands as strings within a program. This obviously means that each SQL command thus can only be parsed and so on at runtime - more than bad enough. But it also means that the SQL command is like a foreign body - it can only interact with the rest of the program through what is typically a verbose and heavyweight interface.
Language Orientated Programming is in some senses new name for an old concept - the LISP community have been doing a limited form of language orientated programming for years via their macro system. However LISP restricts the concrete syntax you can use to express new DSLs and, if we’re being frank, LISP is an almost impossible language to sell in the modern computing world and I don’t see that ever changing. The downside to this is that part of me feels that whilst computer scientists of 30 years were doing language orientated programming reasonably often, their modern counterparts have largely abandoned the idea because no modern languages provide any support.
So I have been witnessing (not without some personal interest I should add) the gradual emergence of a number of ideas that I believe will be critical to Language Orientated Programming emerge over the past year or so. Sergey Dmitriev’s article is in many ways a good introduction to the area, although not without a noticeable bias against textual syntaxes. My ex-colleagues at King’s and York - Tony Clark and Andy Evans - have made a splash in a short space of time with their company Xactium and the XMF tool which is mainly targeted towards the modelling community. Speaking personally I feel there are a number of other pieces to the puzzle that have largely been unheralded. For example, I believe that Template Haskell has shown how a macro-like system which exceeds even LISPs in power can be naturally built into a modern, syntactically rich language - previously this was a significant problem that largely scuppered the homogeneous development of embedded DSLs. One of the next pieces in the puzzle is how best to allow the syntax of a language to be extended. I, for one, have implemented a slightly hacky (but serviceable for the time being) system into Converge; systems such as MetaBorg may well point a more sophisticated way ahead.
So where is this going to lead us? Going back to the SQL example, users might soon find themselves able to intersperse normal SQL code with Java code in a fashion similar to the following:
Vector<Employee> employees_salary_band(int salary_point) { int b_id; b_id = $<SQL>:SELECT band_id FROM salary_band WHERE start_point < salary_point AND end_point > $<salary_point>; return $<SQL>:SELECT * FROM employees WHERE salary_band = $<b_id>; }
In an example like this, note that each SQL statement can be validated and optimized at compile-time, and that SQL and Java variables can be naturally interchanged. This is a very simple example and only scratches the surface of what can be done. One of my current projects has been to implement an entire rule-based transformation language within Converge and I can honestly say that the result has exceeded my expectations. I think that Language Orientated Programming will hopefully lead to both large and small DSLs becoming more practical propositions.
Whilst I am not yet prepared to join in some of the inevitable hyperbole on the subject, I think this is a genuinely interesting subject that might eventually come into the mainstream. In short: watch this space.