With all the current talk of DSLs and concurrency, what I find lacking is discussions about how to combine the two. Of course, domain specific languages are incredibly important – they create a logical separation between the implementors of the business logic, and the people implementing the actual implementation of the DSL. Does it seem like a strange idea to want many DSLs to be able to run parallel to each other? I would imagine that in most cases a DSL that describes business rules and business logic is sequential in the particulars, but that there are also larger concurrency possibilities. This should be totally invisible for the business rule implementor in most cases – the runtime system should be able to run everything as efficient as possible.
A natural way of looking at DSLs is as declarative languages. In many cases that’s the way you write them (just look at the ActiveRecord API. it looks very declarative – it just happens to be implemented using imperative primitives). Now, if the language is truly declarative it should be side effect free. In the end, that isn’t a real goal, but if it would be possible to clearly understand which parts of the rules are using side effects, the rest of the implementation should be able to run totally concurrently.
These kinds of things should be possible to implement in any language with sane multi threading/multi processing. That said, I wouldn’t want the task of doing it with Java’s concurrency primitives if I can help it. So what kind of tools would be helpful? Possibly Erlang of course, since it’s already functional and that makes the identification of side effects much easier. Another possible alternative seems to be Gambit Scheme and Termite.
Anyone else thinking about these issues? Is there any research going on that would shed some light on it? And further, what’s the next step? Why haven’t this question already been discussed? It seems to be well time for it now.
4 Comments, Comment or Ping
Haskell?
September 13th, 2007
I hate BPEL. Expressing application flow and decisions in XML has always struck me as wrong. So earlier this year, I started to write a DSL to express java application flow in JRuby. The concurrency stuff gave me trouble so I guess I dropped the ball. Perhaps the concurrency features in Java 6 will make a JRuby Concurrent DSL a little easier.
September 13th, 2007
Stackless python seems to ba a sane pick.
September 13th, 2007
A decade ago there’s been work to take functional languages (side-effect free) and parallelize them automagically.
I wrote something that a bit related to your thoughts: http://www.manageability.org/blog/stuff/fortress-dsl
September 14th, 2007
Reply to “Concurrent DSLs”