Tag Archives: DSL

Java coder don’t get Lisp? Read defmacro: on coding

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.

Vacation reading, it’s all Groovy

Groovy: Embedding Groovy

Groovy: Groovy Beans

Groovy: Groovy and JMX

Groovy: Using Spring Factories with Groovy

Groovy: Dynamic language beans in Spring

JavaWorld: Creating DSLs in Java, Part 1: What is a domain-specific language?

JavaWorld: Creating DSLs in Java, Part 2: Fluency and context

JavaWorld: Creating DSLs in Java, Part 3: Internal and external DSLs

JavaWorld: Creating DSLs in Java, Part 4: Where metaprogramming matters

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

Apache: GroovyUtil.java

Code To Joy: Zen and Groovy’s Expando

Code To Joy: Simply Groovy (How to gain Competitive Advantage on Weiqi Gao’s Friday Java Quiz)

Code To Joy: Groovy’s -e and friends: The Command Line for Java Developers

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 Fowler: “Will DSLs allow business people to write software rules without involving programmers?”

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.

Related:

The Fishbowl: Dear XML Programmers…

defmacro: The Nature of Lisp