wood burning stoves 2.0*
The moose likes IDEs, Version Control and other tools and the fly likes Why DSLs?  What will we get out of your book? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Why DSLs?  What will we get out of your book?" Watch "Why DSLs?  What will we get out of your book?" New topic
Author

Why DSLs? What will we get out of your book?

Chris Seifert
Greenhorn

Joined: Aug 09, 2008
Posts: 9
What sort of justification can a programmer provide to their company that a DSL is in order? What sort of problems cry out for a DSL? What would be some of the things that an average programmer would get out of spending time with your book? What should we try to use the book for?

Apologies for the simpleton question and this is not a flame, I'm just trying to figure out the practical benefits for an average programmer with an average job.

Terence Parr
author
Ranch Hand

Joined: Jan 13, 2010
Posts: 35
Chris Seifert wrote:What sort of justification can a programmer provide to their company that a DSL is in order? What sort of problems cry out for a DSL? What would be some of the things that an average programmer would get out of spending time with your book? What should we try to use the book for?


Hi Chris, that's an important question. Managers often see building DSLs as a distraction just like they often look at re-factoring code as a distraction. But, it is very shortsighted to only consider how many lines of code a programmer makes every day that directly contribute to a feature.

Ok, so when should we build a DSL? I think the key question is really how often you are performing the same tedious task. Even if I have to do something really painful, I will simply code it up in a general-purpose programming language, at least the first time. If I have to do it a lot, I'll build a tool or DSL to make myself more efficient. These tools/languages can also help other programmers on the team so nobody has to do the painful task manually again.

Even the apollo moon shot in the 1960s used a DSL for their flight control computer. Instead of writing in assembly code, they built a DSL that knew how to do vector math. Not only did this make them faster at writing flight control software, it produced a more reliable piece of software because they got to speak in the language of mathematics not CPU instructions.

As another example, let me tell you how I wrote the book itself. Pragmatic programmers have this awesome proprietary language for writing books. Unfortunately, I have bad tendinitis from writing software for 30 years. I began writing the book by first implementing a DSL that was extremely terse in order to reduce the keystrokes I needed to write the book. I implemented a translator in Java from my format to that of the publishers. Over the long-term, this saved me a huge amount of time and pain in my wrists/fingers.

Also note that sometimes your language application is not the implementation of a DSL. Sometimes you are processing or translating a general-purpose programming language or whatever. For example, all of the tools in eclipse that analyze and re-factor and search code process but do not execute Java code.

So, in summary, think DSL when you see or feel repeated pain My book provides the building blocks necessary for you to implement DSLs or even general purpose programming languages.
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Terrence,

I guess I this must be the other thread you mentioned. I get the idea that DSLs can make programmers more productive, but I still don't see where the balance point is. If I write something difficult/tedious and need it in another place, I make a function out of it so I can reuse it. If there's a lot of related code then it becomes a library or API. When should it become a language?

Thanks,
Burk


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
Chris Seifert
Greenhorn

Joined: Aug 09, 2008
Posts: 9
Terence Parr wrote:
Unfortunately, I have bad tendinitis from writing software for 30 years. I began writing the book by first implementing a DSL that was extremely terse in order to reduce the keystrokes I needed to write the book. ... So, in summary, think DSL when you see or feel repeated pain

Thank you for taking the time for a well-thought out response - particularly with regards to mentioning your tendinitus driving your innovation. I'm starting to think of some pain points (corporate and project administrivia) as well as some fun early-stage stuff related to toy robots. That's pretty cool; Thank you for your time.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

"Should" become a language implies more obligation than I'd be comfortable with. The simple answer is that "it depends". It also depends on what your definition of a DSL is; some DSLs are just fluent APIs, and vice-versa.

The bottom line is that it depends on how the DSL would be used, how inconvenient it is to *not* use the DSL, what kind of support you want to provide, and the target audience.
Terence Parr
author
Ranch Hand

Joined: Jan 13, 2010
Posts: 35
Burk Hufnagel wrote:I get the idea that DSLs can make programmers more productive, but I still don't see where the balance point is. If I write something difficult/tedious and need it in another place, I make a function out of it so I can reuse it. If there's a lot of related code then it becomes a library or API. When should it become a language?


Making a function of something is usually my first step; often this is part of my re-factoring process. The tipping point for me is when using the syntax of the general-purpose programming language obscures what I'm trying to express. For example, let's think about makefiles. It's a lot easier to express with a special syntax:



I could do this in code but it would not be as clear. You could say that the signal-to-noise ratio would be much lower.
Terence Parr
author
Ranch Hand

Joined: Jan 13, 2010
Posts: 35
David Newton wrote:It also depends on what your definition of a DSL is; some DSLs are just fluent APIs..


Hi David. I think I might differ on the definition of a DSL. To use an API you must use a language, typically a general-purpose programming language. So, in my view, using a library wouldn't really be using a DSL, though you can often make the method call syntax looks sort of like the target domain: a = b.plus(c)

The exception to this would be languages like Ruby that let you define operators and radically different syntax (because it does not enforce parentheses for method calls). You can truly bend it into lots of different new syntaxes. Fowler calls these internal DSLs. You can also sort of fake it with the C preprocessor sometimes.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

That's what I'm saying--some DSLs are just fluent APIs. In languages that support "natural"-looking DSLs it's not always obvious it's "just" API calls, although most would let you add the verbosity that would make it obvious.
Terence Parr
author
Ranch Hand

Joined: Jan 13, 2010
Posts: 35
David Newton wrote:That's what I'm saying--some DSLs are just fluent APIs. In languages that support "natural"-looking DSLs it's not always obvious it's "just" API calls, although most would let you add the verbosity that would make it obvious.


Ah. sorry. right. Sometimes DSLs are really thin veneers over a lib.
Keith Flo
Ranch Hand

Joined: Nov 29, 2005
Posts: 128

Terence Parr wrote:To use an API you must use a language, typically a general-purpose programming language. So, in my view, using a library wouldn't really be using a DSL, though you can often make the method call syntax looks sort of like the target domain: a = b.plus(c).


I must admit I don't get it ... I know interest in DSLs is white hot right now ... but ... When I think of the DSL I use everyday (SQL, Regex to name two) ... I always end up thinking how much better (and simpler!) each would be if they were simply libraries in the given language rather than a separate DSL.

Add to that, every development shop, tool vendor and library writer creating his own 'consise' and 'focused' mini language and it just becomes a nightmare of incompatible gibberish. Can it possibly be productive to have to learn new syntax for every project? Just because somebody wants to pretend to be a language designer (even on a small scale) should I need to learn his 'language' just to read his code?

Lastly, I can understand defining the functionality and features of an app in the same terms that those who use it actually use (insurance terms for insurance, printing terms for an app for printers) ... but that seems to scream for a well designed API (or library) not a mini-language!

Just my .02 ... and Terrence thanks again for answering questions here!


kf
SCJP 5.0 (preparing for SCWCD)
Terence Parr
author
Ranch Hand

Joined: Jan 13, 2010
Posts: 35
Hi Keith,

You're right that sometimes a well-designed API is better because you don't have to learn a new language. On the other hand, some DSLs are usable by nonprogrammers. I guess my rule would be that you should avoid a DSL unless you are truly much more productive writing in the DSL over an API. a+b is better than a.add(b) but not so much better that I'd bother creating a language. It all depends on how much it saves you. I've been playing around with the grammar unit testing tool, gunit, and each "this should give you that" testing pair saves me a whole bunch of cut-and-paste, but more importantly it's much more readable than the equivalent raw junit (I'm using gunit to translate my grammar fragment tests to junit tests). gunit is at least a 5 to 1 compression over raw code.

Don't forget that ANTLR is itself a DSL for building DSLs. We get huge compression going from handbuilt recursive descent parsers down to a grammar. Yes, people have built parsing libraries but they are never as easy to read as a grammar. As another example, consider the simple graphics DOT language used by graphviz. We could write a series of method calls that create nodes and connects them up, but it seems much easier simply to say "a -> b". It only took me a second to glance at their manual to figure out the language. I'd wager it would've taken a lot longer to figure out a library. There's nothing for free so I guess we have to figure out how the API works or learn a language.

My general progression is to start by building a library. If I end up doing a lot of cut-and-paste and figure that I will need this functionality in the future, I will design a simple DSL that is much more expressive. 'course I've gotten pretty fast at building little language applications.

I'm editing this to add an example from the book in section "Creating Target-Specific Generator Classes". Let's say we want to generate bytecodes using an API. Here is the sample code from the BCEL manual to create the method definition object for a hello world main():



That seems like a lot of work just to define a method. All of these constructor calls really add up quickly to a very large code generator.

Rather than using these target-specific generator classes, it's easier use a few print statements to generate a method definition in a bytecode DSL. For example, using the Jasmin bytecode assembler, here’s what main( ) looks like:



This is much more clear. Of course, we have to learn a tiny bit of syntax, but that's easier than learning the vagaries of a library such as BCEL. So DSLs count for output not just input
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

DSLs aren't just used by developers, though--although when they're not, they usually make my life easier, because *other* people can do the work I'd have to do otherwise. How the DSL is implemented goes a long way to helping to decide whether or not it's worth it. An internal DSL in a JVM language is easy to integrate and generally easy to maintain.

External DSLs, on the other hand, at least in my opinion, need a stronger justification.

As far as regex and SQL go--they have a life that is *substantially* wider than a single environment. That's what makes them ubiquitous DSLs, and perfect for the job they do. Having seen Java-esque regex DSLs I'm pretty darn happy to stick with the original. Fluent SQL APIs aren't bad, and make more sense.
Keith Flo
Ranch Hand

Joined: Nov 29, 2005
Posts: 128

Terrence,

The example helps a lot! ... and you're right its dramatically simpler. Also ... I'm thinking I'm gonna need to try to write a small DSL to really get the sense of it.

However, like anything with lots of power there's great potential for abuse. I fear the day DSLs are everywhere ... I have a feeling a bad DSL is a lot worse than a bad API. But clearly, there seems to be a lot of power that can be expressed pretty simply.

The bottom line is ... I need to check out your book!
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Keith Flo wrote:The bottom line is ... I need to check out your book!


Hear, hear. I second the motion. All in favor?

This is a great thread - though I'm going to have to read it a couple of times to make sense of it.

Burk
 
Don't get me started about those stupid light bulbs.
 
subject: Why DSLs? What will we get out of your book?
 
Similar Threads
OpenLaszlo learning curve
Background required for DSL
IDE support for DSL
DSL performance
Dumbing it down: How or when to let users interact with DSL?