Slava Akhmechet wrote a piece a while back that that challenged my thinking in terms of design using an old familiar friend and adversary: Ant. If you are a Java programmer, you’ll recognize the patterns Slava is connecting with to share with you why Lisp is so interesting. BTW, this piece would work doubly well with Maven if it was updated. Go read.
Martin Fowler: DomainSpecificLanguage
Martin Fowler: FluentInterfaces
InfoQ: Martin Fowler: Introduction to Domain Specific Languages
The Structure of Structures: Are DSLs simply XML Hell?
Ward Cunningham Wiki: Domain Specific Language
defmacro.org: The Nature of Lisp
Wikipedia: Domain-specific languages
Groovy: Embedding Groovy
Groovy: Groovy Beans
Groovy: Groovy and JMX
Groovy: Dynamic language beans in Spring
IBM developerWorks: Functional programming in the Java language
IBM developerWorks: alt.lang.jre: Feeling Groovy
IBM developerWorks: Practically Groovy: Stir some Groovy into your Java apps
IBM developerWorks: Practically Groovy: Unit test your Java code faster with Groovy
IBM developerWorks: Practically Groovy: Reduce code noise with Groovy
IBM developerWorks: In pursuit of code quality: Programmatic testing with Selenium and TestNG
Groovy Zone: GroovyShell and memory leaks
Code To Joy: Zen and Groovy’s Expando
Code To Joy: Groovy 201: How to Win a Bar Bet on Copy-Paste
Code To Joy: myTunes: Groovy and JFugue
Code To Joy: JFugue and The Charm of Computing
Code To Joy: Zero to RMI with Groovy and Spring
A Public Scratchpad: The Future of Groovy Interoperability?
Test Early: Spring’s so Groovy
Spring documentation: Chapter 24. Dynamic language support
JavaBeat: Integrating Spring and Groovy
Martin Folwer: BusinessReadableDSL:
I do think that programming involves a particular mind-set, an ability to both give precise instructions to a machine and the ability to structure a large amount of such instructions to make a comprehensible program. That talent, and the time involved to understand and build a program, is why programming has resisted being disintermediated for so long. It’s also why many “non-programming” environments end up breeding their own class of programmers-in-fact.
That said, I do think that the greatest potential benefit of DSLs comes when business people participate directly in the writing of the DSL code. The sweet spot, however is in making DSLs business-readable rather than business-writeable. If business people are able to look at the DSL code and understand it, then we can build a deep and rich communication channel between software development and the underlying domain. Since this is the Yawning Crevasse of Doom in software, DSLs have great value if they can help address it.
With a business-readable DSL, programmers write the code but they show that code frequently to business people who can understand what it means. These customers can then make changes, maybe draft some code, but it’s the programmers who make it solid and do the debugging and testing.
This isn’t to say that there’s no benefit in a business-writable DSL. Indeed a couple of years ago some colleagues of mine built a system that included just that, and it was much appreciated by the business. It’s just that the effort in creating a decent editing environment, meaningful error messages, debugging and testing tools raises the cost significantly.
The Fishbowl: Dear XML Programmers…
defmacro: The Nature of Lisp