From programming.reddit.com I came across Carsten’s blog. He has posted a quick article about the possible consequences of what Joshua Bloch presented at JavaPolis, that would be the “evolution” of Java into the functional paradigm field.

The slides from the talk itself are very interesting. Bloch gives yet another historical overview of the Java platform and states clearly the fact that the language was not a “language geek” thing, it was about being practical (or like we always hear these days: pragmatic) and that it suffers because of this. He has a nice reproduction of an 1997 IEEE journal that presents an article by James Gosling.

[Java]’s not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because we preferred tried-and-tested things.

The slides go on about how Java became bloated and how the implementation of something like closures in that shouldn’t be a disaster like the generics, including an interesting point that Java doesn’t need all those fancy features people want, Scala already has got those already. Even if you don’t agree it’s a very nice material.

Anyway, the point that got my attention in Carsten’s post is in a small paragraph:

DSLs are in fashion and a powerful concept for layering a complex application, but they create as well new languages: You can’t hire a Lisp or C++ programmer and expect him to be immediately productive as they have to learn the DSLs of your projects first

I understand the point but can’t agree with that. It’s like saying that if you hire a Ruby programmer that doesn’t know Rake it will impact in your project.

Most work a developer performs nowadays is not related to the language it’s working on (Sun says it can teach you Java in two weeks, by the way) but it is all about modeling domains. Domain-Specific Languages will help exactly at this point, providing a more powerful yet simpler tool to model the business problem.

If a good Domain-Specific Language was defined its actual user will be the Business Analyst (or her equivalent). Even if the BA can’t write code by herself she must be able to write the story and acceptance criteria using this language, otherwise you probably simply don’t have an usable DSL at all.

In a DSL project the biggest job for the developers are to implement, maintain and extend the language and the software infrastructure that supports it. To do that they’ll use (at least before we get some tooling in this direction) their standard toolkit: Java, Ruby and the like. The difference is that instead of modeling the world merely by having objects they have to do that with the DSL itself.

The problem a new developer will face in a DSL team is the same he woul face in a standard Domain-Driven Design team: understanding the domain.