Marco Tech Blog

April 14, 2008

Introducing Domain Specific Languages

One of the reasons for using dynamic methods invocation is to implement an internal Domain Specific Language (DSL) in Delphi.

posted by marcocantu @ 8:38PM | 4 Comments [0 Pending]

Introducing Domain Specific Languages 

OK, getting somewhere, but this "Why" is still a "What"...

Q: Why do we want/need Dynamic Invocation?
A: So we can do DSL in Delphi.

Which then simply leads to ....


Q: Why do we want/need to be able to do DSL in Delphi?


The only answers I see so far are:

1. Because it looks like it could be fun
2. Because it looks like we can


Of course, we see again the "Business Benefit De Jour"
for "new" language developments these days....
increased "productivity", which upon closer
examination means "Jam Today", which works great for
throw away code (in which case, why not just use a
language/tool designed for creating such "disposable"
products int he first place, rather than twist and
coerce a product designed for something else entirely).

The "new" in "New Language Developments" being
enquoted because as you yourself point out, a lot of
these "new" ideas are in fact old ones that have had
their chance and "failed" in the "real world" (lots of
enquoting of colloquialisms not meant to be taken
literally) or at least been found wanting.

All that has changed in most significant respects is
that sufficient time has passed that their failings
have been forgotten and a whole new audience is able
(and/or willing) to be talked into parting with $$'s
in pursuit of another motherlode of Fool's Gold.


Unless, that is, there really is a real answer to the
"WHY" question in all of this.

Comment by Jolyon Smith [http://www.deltics.co.nz] on April 14, 23:34

Introducing Domain Specific Languages 

It seems like the term "domain specific language" is a
fairly loose definition.  If you import data from a
spreadsheet, the spreadsheet could be a domain
specific language, and one that represents data in a
way that is comfortable for users and not too foreign
to a database.  I have found that to be a very
productive and flexible interface to work with.  I
will be very interested to see how developing a
further understanding of an external domain specific
language can help me in this area.

Comment by Jack Rodenhi on April 15, 00:07

Introducing Domain Specific Languages 

For the sake of practicity about DSL:

Do you think that ABAP, the Domain Specific Language
of the almost all-mighty and succesfull ERP named SAP,
one of the greatest features is a practical joke? 

Domain Specific Languajes is a great tecnique when you
have a requirement of flexibility in your
applications, no matter the size of them. Of course,
the market you're targeting is what matters, but I
think even no-brainers could bennefit from a tool
whenever they try to customize your apps further.

I have implemented something myself, and this DSL turn
to be one of the major advantages. I even have a post
about Dynamic Method Invocation too (in spanish).

http://salvador.oversistemas.com/2007/11/llamada-dinamica-metodos_19.html

Way to go, Marco!

Comment by Salvador Gomez Retamoza [http://salvador.oversistemas.com] on April 15, 22:38

Introducing Domain Specific Languages 

Joylon, I totally agree with you that DSLs should not 
be used just because it looks like it could be fun or 
because we can.

Like any other design pattern, the Interpreter pattern 
should only be used when you encounter a problem that 
the pattern solves, and not a second before.  But 
there are very common problems which the Interpreter 
pattern is ideal for solving and therefore very good 
reasons for writing DSLs.

For me, the primary reasons to use them are 
readability, the elimination of duplication and 
reducing the code I have to write.  As a tool I don't 
treat them any differently to any other abstraction 
mechanism (including functions and procedures).

Ruby on Rails is where I've experienced them most, and 
here are a few examples of some simple uses of this 
pattern.

class Customer < ActiveRecord::Base
  has_many :orders
end

class Order < ActiveRecord::Base
  belongs_to :customer
end

The single line in each of the above classes does a 
whole lot of work behind the scenes, including adding 
methods for accessing orders on the Customer class and 
the Customer on the Order class.  The has_many and 
belongs_to statements are simply method calls that 
decorate the classes with a bunch of useful methods.

Properties in Ruby follow a very similar pattern.  The 
methods attr_reader and attr_accessor provide the same 
functionality defining properties on a Delphi class 
(creating a variable, getter and setter methods).  But 
it's done in a way that's easy to understand and 
imitate.

Another example is the time manipulation functionality 
that ActiveSupport provides.

1.hours
1.5.hours.ago
90.days.ago

All ActiveSupport is doing is adding some methods to 
the Fixnum and Float classes (Ruby has no primitives).  
1.hours actually returns the number 3600, while the 
'ago' function will subtract whatever number its 
called on from the current time and return the result.  
So 1.hours.ago and 3600.ago do exactly the same thing.

I've seen (and implemented) similar mechanisms to do 
things like 1.usd.in.euros, 2.aud.in.usd, etc (with 
the ability to update or add currencies on the fly).

These are all VERY simplistic examples of internal 
DSLs.  But I frequently miss not being able to take 
similar short cuts in Delphi.

And when you consider that Ruby and Delphi are of 
similar age, it's disappointing that Delphi is only 
just beginning to incorporate some dynamic features.  I'd easily estimate that the typical Delphi program 
has 10x more code than a typical Rails application to 
do exactly the same thing.  And languages like go are 
even more terse.  That extra code costs you more in 
writing it, testing it and supporting it.

As I've said previously: If you really don't believe 
in DSLs, then try doing without them.  Totally stop 
using QBE, SQL, XML, HTML, LINQ, etc, etc and see how 
far you get.  I'm sure none of us wants to go back to 
reading and writing flat files or building tcp/ip 
packets from scratch.  A DSL is simply an abstraction 
that allows us to get more done with less code.

Comment by Craig Read [] on October 3, 04:33