Neal Ford is keynoting on using dynamic languages to build domain-specific languages. It’s a stark contrast to Dave Thomas’ keynote from 2 years ago. Dave was very philosophical on the ways we think about doing development. Neal is right down there in the code – source is getting more screen time than powerpoint at this point. He contends that Java is already commonly using domain specific languages in the form of XML configuration files for our frameworks. [As an aside, the wireless access here in the main session room/dining room is actually reliable. JRoller still continues its attempts to eat my drafts as I save them.] Thus far, I honestly think he (along with half the developer community) has gone a bit far off the deep end in terms of the pain of developing in Java. Perhaps I’m numb from being knee deep in Java for more than 5 years, but the repeated dismissive references to “curly brace languages” are a bit overstated, I think.

He’s mentioning Language Workbenches, but at this point it looks like the current set of language workbenches are all proprietary, vendor-based offerings. In my opinion, until there are multiple, freely available language workbenches, perhaps an Eclipse variant or plugin to handle it, this technology will face serious challenges to wide adoption.

So the general idea is that you use this language workbench thing to create a meta-language, that defines a language that is very similar to the problem domain. The problem I see with this is that each individual problem at each individual company is defined with its own domain specific language. One of the reasons community acceptance is such an important selection criteria in choosing which Java framework to use for a particular problem type is the knowledge that the more known the framework, the easier it will be to hire someone who immediately understands at least that framework, even if they don’t understand the company’s software yet. For lower level concerns, I can almost understand a use for this – in replacing the Java frameworks. At a higher level, in terms of a business’ actual problems, such as CRM, manufacturing, etc, I see a potential problem where you now end up hiring developers who understand neither your language nor your problem domain.

This is my gut-shot reaction. I’m going to have to chew on it a bit more and reach more long-term conclusions. Time to head home, starting back at 9 AM tomorrow.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.