Austen McDonald just walked into my office and said he didn't like domain specific languages and that they are not the way to go. What do you think? --Jared

If you have doubts about domain-specific languages (DSLs), let's start documenting the disadvantages and concerns. We should either address these issues or use them as the guidelines for picking some approach more profitable than DSLs.

What I find attractive about DSLs is that they provide very high level interfaces for programming. Such interfaces tend to be easy to use (e.g. Blas Vs writing an efficient sparse-matrix LU factorization yourself) and contain lots of information about parallelism and locality to exploit at lower levels. They also provide lots of freedom for the language/runtime implementation, which can change in a manner transparent to the end user.

There are many open questions with this approach. The one I find most challenging is how do we handle applications that contain tasks from multiple domains. How do we make multiple DSLs work together?

Any thoughts?

Christos

Austen McDonald: I would like to say that my comment was posted w/o my knowledge...

I see the power of DSLs but object oriented general purpose languages spoiled us in the sequential world because they enabled us to build up domain specific views through libraries in user space. Can we enable this for the parallel world too?

Martin

I think one of the problems with OpenMP-like pragmas for C-like languages is software verification. Having to verify correctness of software that is written as an extension to sequential programs, seems to me as being much more expensive than verifying software written in DSLs. The semantics of the DSL should make program behaviour much more explicit and easy to model, in contrast with the potentially corner-case ridden extensions to sequential languages.

Hari

I think an important question is WILL people change to parallel programming models? And I think performance will be the driving factor for this. If the effort involved in learning a new model/language is more than the relative performance gain, its likely that it won't be accepted by industry due to vast amount of legacy code(primarily in C/C++). Also the performance gain has to be substantial.

Krishna

I think some DSL with good concurrent primitives and/or good concurrent supporting libraries will give us good insights. It's not exactly DSL, but functional languages seem to have good support for concurrency. Taking some part from it - like take some builtin functions as map/reduce(which every functional languages use) - or taking some concepts from it (maybe take the concept that every variable is immutable and relax it a little bit?) maybe we can make more general purpose currency oriented programming language. Since 'less is more', if functional languages(or some other DSLs) are 'more' what would be less?

Jiwon