Lang.NET, DSL DevCon Highlights

Intentional Software has forged a silver bullet. It’s terribly difficult not to go into that in great depth (I will shortly), but for now, I simply don’t want to bury the lede.

OK, so other than that what was interesting?

There are several categories that need to be talked about:

  • Platforms (how do we support languages in VMs?)
  • Tools (how we make the creation of languages easier / faster?)
  • Techniques
  • Experiences & Patterns

I had the intuition that Lang.NET would be about the first two topics and DSL DevCon would focus on the latter, but it turned out fuzzier than that. Lang.NET was a smaller group and probably a little more academic but the real difference between the conferences was structural. Lang.NET had 30-minute talks and 15-minute lightning talks. DSL DevCon had 45-minute talks. I think the Lang.NET structure was widely perceived as better.

“Domain-Specific Languages” has been a term of art for 30 years and if you’re reading this blog, you presumably have an interest in higher-level discussions of productivity and industry direction, so I’ll take it as read that “language issues are important, interesting, and have an impact on productivity.”

If you’ve been reading this blog or my column for any amount of time, you know that I’ve been predicting DSLs as the next big buzzword / buzzphrase for quite some time. Eventually I had to be right. So I quite expected a full-court press articulating a model covering all four of the above categories; I expected to hear something like this:


But I didn’t hear that or any alternative development process model (other than from Intentional Software), and that’s my number one takeaway:

The DSL marketing wave is dangerously ahead of the pedagogical wave.

Highlights in the various categories


Lars Bak on implementation of the V8 JavaScript engine was dynamite. Concrete, informed, impressive. (Not incidentally, I think Harry Pierson, Chris Sells, and Microsoft should be given great credit for bringing in people from Google, Sun, and the Linux community and encouraging a collegial atmosphere.)

Paul Vick gave two talks on Oslo, but I think his first had more on the “platform-y” aspects of Oslo. The vocabulary of Oslo was covered and questions from the audience (I hope they’re in the video) pressed on the question of “runtime projection onto the DLR” (which, it turns out, is “what we’re talking about when we’re talking about DSLs”).


There were many talks about tools. I think everyone wished that Jeffrey Snover talked longer than 15 minutes about Powershell. The videos for DSL DevCon aren’t up yet but when they are, Update: Here they are, don’t miss Gilad Bracha on NewSpeak. Among the many excellent talks, Guillaume Laforge on Groovy had a few particularly memorable points.


The technique talks almost all had the same theme: functional programming. Pattern-matching this, parser combinator that. This was usually not separated from a specific tool (not surprisingly, we heard much of F#), and I think that lack of distinction was unfortunate.

The standout “technique” talk was Erik Meijer on reactive programming. For all the functional love in the room, only Meijer and Philip Wadler gave talks structured around proofs. Wadler’s talk was very good, but Meijer sketched a proof while throwing coins and calling out above the rolling laughter of the audience. We walk in the garden of his turpulence.

Experience & Patterns

There were several talks that sounded like they might be about techniques or experience (“the implementation of X”), but they turned out to be about the tool or the domain itself (“X does this and that”). Matthew Wilson on Bootstrapping Perl 6 onto .NET didn’t make that mistake, nor did Paul Cowan when discussing the Horn Package Manager implemented in Boo (it took him a few minutes to get to the good stuff).

Amanda Laucher’s experience optimizing an insurance application was actually the only talk that I felt was centered on process issues! (And there, it seemed the main issue was object-functional mindsets, not the “language-y” issue of deferring the specification of intent.)

For the first several slides of the Brad Cross / Ted Neward “Functional vs. Dynamic DSL Smackdown” I thought we had finally gotten to the core process issues: defining terms, contrasting approaches, and then asking not “in which is it possible?” (Both. But everyone who’s been paying attention knew that before last week.) but “which has a chance of succeeding in the real world?” Unfortunately, the talk got bogged down in technical specifics.

Final thoughts

Lang.NET is my favorite conference of the year. I pay for it out of my own pocket. If this stuff is interesting to you and you have the time to watch every video, by all means do so.

This year I thought my deep interest in programming language issues was going to be joined with my deep interest in process issues. It was not to be. This worries me greatly, because I submit that the amount of DSLs written is determined not by technical issues but by people issues.

One implicit premise very clearly on-hand was “the [functional|dynamic] mindset facilitates the meta-level reasoning that’s a necessary precondition to recognizing a language-based opportunity.” OK, two valid premises. But where’s the evidence? And even if there’s a correlation between a particular mindset (whether it be functional or dynamic) and language-based approaches, does the mindset cause (or at least facilitate) that, or is it the case that those prone to meta-level reasoning gravitate towards a particular mindset? And are these mindsets teachable to those whose minds have been corrupted by exposure to the real-world or is our only hope a new generation that doesn’t make any of the same mistakes we did? (Because that hope always pans out.)

I find those questions fascinating and I don’t pretend to know the answers (beyond insisting that the answer has to acknowledge the historically small percentage of people who have exploited these techniques to date). I’m only sad I’ll have to wait a year to hear what the smartest people in the business have to say on the matter.

DSL Writers: Put Turing Completeness Out Of Your Mind

At the recent DSL DevCon, Martin Fowler gave an excellent keynote speech discussing domain-specific languages, an important subject that seems certain to be the buzzword of the next year or two.

However, one slide of his got my goat, leading me to foam at the mouth, beat the table with my shoe, wag my finger angrily, and otherwise mix my metaphors. In that slide, he said something along the lines of “a DSL probably ought not to be Turing complete.”

I think this is terrible advice. First, I think it’s a pedagogical mistake. Second, I think it’s incorrect.


shell ? sql | (minesweeper && life)



Is SQL a less powerful programming language than the game of minesweeper?

To the extent that we want to broaden the number of people writing domain-specific languages, we can’t put that question on the entrance test.

Even if the percentage of people who know the answer can be made large, the percentage who comprehend it is quite a bit smaller, and the number who can apply it is a very small number. In a DSL, it’s smaller still, because you have to analyze your language in the context you’ve embedded it. You’ve climbed right up Bloom’s taxonomy! That’s why I think it’s a mistake pedagogically.

Why I think the advice is flat-out wrong is that DSLs are necessarily embedded in the context of a general-purpose language. Say I want a DSL that converted the numbers 1 through 256 into a set of CA rules following the obvious structure implied in:


A DSL with exactly one production ({byte} -> {CA rules}) is not Turing complete (duh). But the context in which this DSL is expressed is one that leads to a (possibly profound) discovery of Turing completeness. (In case it’s not obvious from the context — the illustrated ‘Rule 110’ CA is Turing complete.)

Fowler referred to this when he advised DSL writers to avoid “accidental” Turing completeness. That really set the hook deep in my mouth, because it has a whiff of this stuff. To raise the issue and then to hand-wave it away is leaving yourself one heck of a big escape hatch. The mention of ‘Turing completeness’ or ‘Turing equivalence’ begs attention; they’re either forbidden holy-words or they’re used precisely and must be discussed with precision. (Thus, O’Brien’s Corollary (1991) to Godwin’s Law: The first person to mention ‘Turing equivalence’ in a debate of programming languages loses.)


It’s only because Fowler generally gives such excellent advice that the “Turing complete” stuff provoked me so much. Sure enough, a moment after the slide I didn’t like, he came up with what seems like the answer. I’m not sure of his exact words, but it was along the lines of:

Start with a general language that you think is readable and take stuff out. If you can’t take out quite a bit, don’t write an external DSL.

Great advice.

Lang.NET: Preliminary Thoughts

There’s a school of thought in anthropology that the form and vocabulary of the language you speak deeply affects how you think, even to the point of limiting if you can think about certain things. This is called the Sapir-Whorf Hypothesis. There’s definitely something to it, although probably not in its strongest “thought on certain subjects is downright impossible” form. It’s relevance to software development and our artificial, highly constrained languages, ought to be obvious. 

I believe a fairly strong version of Sapir-Whorf when it comes to programming languages. Different languages and programming paradigms lead to different results — the cost of a software project is directly tied to the conciseness and maintainability of its expression. Even more, software projects grow from seeds, and the structures expressed in the earliest days profoundly affect the form of a system over its growth. So the designs and approaches used in the earliest days of a project can have ramifications for years afterward.

Meanwhile, the actual popularity of programming languages is an absolute mystery. What programming language are you going to be using in 10 years? No one knows. No one. Not Anders, not Matz, not Paul Graham. Twenty years ago (oh lord…), I started working for the magazines Computer Language and AI Expert. I’ve been hearing about the inevitability of this language or that paradigm or this other environment for two decades. And I don’t have a horse in the race; I’m not a language designer, I don’t teach anymore, I’m not beholden to a product line. 

I do have one theory about language popularity: I think teachability matters a lot. I also have a theory about teachability: You are blind to the teachability of your own paradigm. This is an unfortunate combination of theories.

So that’s why Lang.NET is my favorite conference of the year.