Howard Dierking’s quote on the LOP session at Alt.Net:

On a positive note, though, I wasn’t alone in my thinking - and a side conversation on language oriented programming got started and actually continued after the meeting ended. Several issues were discussed, but a couple interesting ones that jumped out at me were the following.

• Language oriented programming is defined along somewhat of a continuum - the continuum is measured by the definition of language and ranges from defining language as a soluble code library to defining language as a full blown DSL. Depending on your definition, the proximity for the realization of language oriented programming shifts.
• We will probably go way too far in implementing custom “languages” before we figure out the best practices - then pragmatism will drive things back to the center (sound familiar?)
• In the case of DSL, there are 2 major challenges
• Keeping the language scoped to a narrow domain - the biggest mistake for a DSL creator is letting it grow into another Turing-complete GPL.
• The language integration/collaboration strategy. I am personally REALLY interested in this one.

Since he’s a MSDN Blogger I believe that much of what he says about LOP and DSL and his reaction to “seemed to only want to talk about the philosophical ramifications of doing away with parentheses for method calls in Ruby. I remember having similar conversations wrt JavaScript about 5 years ago!” are related to Microsoft’s highly graphical and bing-bang approach to the technique, Software Factories/DSL Tools, but he had good points at that list.

As all new way of doing things we definitely will do lots of mistakes until we get even a clue of the right way of doing LOP. The industry in always on a hurry and will not wait scientists to figure out what are the implications of merging General Programming Languages (GPLs) and Domain-Specific Languages at software development (we have some niche studies but nothing in a very large scale); and as always the best way to figure out what is the best way to work with those new languages are by using them.

I think Internal DSLs minimize a lot the issues that could arise integrating DSLs with GPLs. An internal DSL is embedded into a language and will be automatically integrated to it (since it’s a way of language adaptation).

The Internal DSL approach gives yet more fuel to the doubt about how can we narrow a language scope to its domain. An Internal DSL is often turing complete just like its host language. Anyway I don’t think it is a real problem since the whole point about embedding a DSL is not about removing power from developers (although it can be useful) but to get a language that is deeply related to the model it implements.