Sergey Dmitriev, the CEO of JetBrains, was interviewed at JavaOne. He discussed IntelliJ IDEA, Visual Fabrique, and also got into the new Meta Programming System (MPS) that JetBrains uses. This system seems similar to the DSL meta system that Microsoft is working on. Is this the new MDA/UML?

"With this system you can quickly develop the syntax structure, an editor and a code generator for custom domain specific languages."

Sergey explains that this ISN'T UML. This is the same stance that Microsoft has:

CGN: Is this in UML? What is the visual language?

Sergey: The visual language is not one language. It's not an MDA-like program. We have two main parts that are public. One describes the business model, similar to an entity relationship diagram. But it's not about this, it's about business objects. It's a diagram editor because that's a convenient way to represent such models. And we also have editors for queries to the database, but again, not in UML.

We also can discover a database, and talk to web services or to session beans. However, we describe these things on a more abstract level. We don't push the user to use a concrete run-time platform, like J2EE, .NET, Web services, and so forth. You don't need to choose this at an early stage.

This is a domain specific language for this domain, which is data access plus a web user-interface. So for the moment it's just for web applications. But in the future we will also do client side applications. For each domain we will have a special language. Then we generate for a particular computer language. Right now that means we generate Java and J2EE. In the future we will add .NET and others.

When you use a more high-level description, you have less dependence on the target platform.

Our domain specific language for web pages is based on XHTML, and we have a set of web controls that are expressed in our own language.

Read the full interview.

I've made a few domain specific languages using XML mixed with XSL and Java for code generation. It works great.

Getting companies to buy into a Domain Specific Language is pretty difficult though. Most would rather cut and paste ad infintum.

+1 for being able to refactor from the Domain Specific Language out to the Java code.

-1 for putting a GUI on the Domain Specific Language. VB anyone?

Formal languages can solve strictly computable problems - they are both equivalent to a Turing machine.

Reality is non-computable; however, it can be reduced locally to a computable problem by accepting a finite set of axioms in the system. But such a system is either incomplete or inconsistent.

This type of solution is perfectly acceptable iif we have a framework managing both the incompletness and inconsistencies in our system.

IMO though, just the langugage/editor do not provide are not sufficient for providing a manageable solution. A tool to manage the domain statements out of which the language/editor are generated is also required.

Great idea and very interesting research! And I'm not surprised this comes from a innovative company like JetBrains.

Cheers,
Dino

And I'm not surprised this comes from a innovative company like JetBrains.

When perhaps the best Java IDE vendor focuses on users avoiding Java, it's an obvious sign that procedural hand coding has peaked.

And I'm not surprised this comes from a innovative company like JetBrains.

When perhaps the best Java IDE vendor focuses on users avoiding Java, it's an obvious sign that procedural hand coding has peaked.

Yes, old good things never die.

I suspect it's more of an issue of the IDE market being commoditized at the low end. This means tools vendors must provide something over and above simple IDE functionality that may be had for free. Perhaps something like an MDA tool maybe (grin).

Formal languages can solve strictly computable problems - they are both equivalent to a Turing machine. Reality is non-computable; however, it can be reduced locally to a computable problem by accepting a finite set of axioms in the system. But such a system is either incomplete or inconsistent.This type of solution is perfectly acceptable iif we have a framework managing both the incompletness and inconsistencies in our system.

According to Goedel (to whom you are referring here I presume) you have either inconsistency OR incompleteness. I'd rather settle for the lack of completeness because I as a developer can fill this void personally. In fact, that's how we all earn our money ;-)

Yes, I am referring to Goedel's theorem. From this perspective, development seems to cycle between incomplete and inconsistent states. Deliverables seem to belong to the first category though.

I very much doubt that this idea can work in "the real world". There are a couple of reasons for it, for example

• The domain is only understood during the construction process. This is a very common problem in a lot of projects. "Analysts" don't know enough about what the system formally requires and are not able to communicate requirements in a concise way. I would assume this is a prerequisite for developing a domain specific language.
• Domains are too broad. A lot of projects deal with a domain like "the business of United Airlines". This is essentially not a single domain but at least a dozen formal business domains and even more technical domains. One ends up with dozens of languages, potentially with different syntax and editing tools.
• Domain is insufficient. You can see this with fabrique at the moment. Nice to quickly put together simple web apps. But as soon as you work with multiple databases and a message queue and a couple of flat files at the same time as your data source and sinks, you need more flexible, more mature tools
• Graphical editors break down early. This is even true for database modelling, where only very sophisticated (and expensive) tools give good graphic representation for the entire development circle. And this is only data modelling.
• Redundant learning. Learning a new domain language is only justified if it gives you very significant advantage about the generic language. With languages like Java and .NET this is not easy.

I very much doubt that this idea can work in "the real world". There are a couple of reasons for it,

DSLs have been used with great success for over a decade by the Functional Programming community. If you look into this a bit, bear in mind that they often use the term "combinator library" when referring to DSLs. The FP community's favourite use of Monads is for DSLs (a successor to Monads is proposed - Arrows). Also note the arguments in favour of Domain Specific Embedded Languages (DSELs) over DSLs.

The Logical Programming community gets DSLs, too. See this paper:
"A Horn Logic Denotational Framework for Specification, Implementation, and Verification of Domain Specific Languages" by Gopal Gupta and Enrico Pontelli
(www.cs.nmsu.edu/~gupta/logden/dsl.ps)
 
Imperative programming language practice has lagged badly, and it is time to enjoy the benefits of DSLs/DSELs.

The domain is only understood during the construction process. This is a very common problem in a lot of projects. "Analysts" don't know enough about what the system formally requires and are not able to communicate requirements in a concise way. I would assume this is a prerequisite for developing a domain specific language.

You are confusing waterfall process with DSLs. There is no connection. Development of DSLs is highly iterative.

Domains are too broad. A lot of projects deal with a domain like "the business of United Airlines". This is essentially not a single domain but at least a dozen formal business domains and even more technical domains. One ends up with dozens of languages, potentially with different syntax and editing tools.

For a look at an approach for linking domain semantics for very complex endeavours, see the work for the Rosetta System Level Design Language (www.sldl.org).

Domain is insufficient. You can see this with fabrique at the moment. Nice to quickly put together simple web apps. But as soon as you work with multiple databases and a message queue and a couple of flat files at the same time as your data source and sinks, you need more flexible, more mature tools

It would be wrong to judge DSLs by where fabrique is at right at this moment in the development of their product. There is plenty of other experience with DSLs.

Graphical editors break down early. This is even true for database modelling, where only very sophisticated (and expensive) tools give good graphic representation for the entire development circle. And this is only data modelling.

Agreed, but there is no particular connection between graphical editors and DSLs. Historically, DSLs have been developed non-graphically.

Redundant learning. Learning a new domain language is only justified if it gives you very significant advantage about the generic language. With languages like Java and .NET this is not easy.

You are thinking about domain languages in terms of large general purpose languages, and this is leading to you to a wrong conclusion. Instead, try equating a DSL with an API. Do you avoid APIs because there is something to learn about using them? I hope not.
Also, there is no avoiding acquiring the necessary domain knowledge under any approach, and hence no possibility of avoiding learning. A DSL makes standard (normalises, if you like) the domain knowledge.

You are confusing waterfall process with DSLs. There is no connection. Development of DSLs is highly iterative.

No I don't think I am. But I do know that you require more than a single programmer for a project and I know that the quality of most "software engineers" is not good enough to sustain a single comprehensive language, let alone a lot of languages that are "evolving" and "iterative". Also I know that even if some domain languages will be available, people will be reluctant to use them but rather "roll their own", much like with APIs. And finally, waterfall process is back big time with the current trend to offshoring anyway :-)

>ou are thinking about domain languages in terms of large general purpose languages, and this is leading to you to a wrong conclusion. Instead, try equating a DSL with an API. Do you avoid APIs because there is something to learn about using them? I hope not.Also, there is no avoiding acquiring the necessary domain knowledge under any approach, and hence no possibility of avoiding learning. A DSL makes standard (normalises, if you like) the domain knowledge.

Yes, but what if you have to deal with different domains and different languages using different syntax at the same time. Sure you can integrate them and there are standard ways of doing so. But still this is overhead and essentially may create more problems than it solves. In particular when you are confronted with large systems with high developer fluctuation and long application lifetime, keeping complexity low and integration easy is a prime concern. If I see people struggling using SQL, JavaScript, Java, JSP, Ant and whatnot at the same time, I think it is not because they are "general purpose" but because they are different. So I'd like to keep people/teams working with as little different languages as possible. This makes me a bit wary about lowering the threshold for the creation of a domain language as a general approach in the first place, no more, no less.

You are confusing waterfall process with DSLs. There is no connection. Development of DSLs is highly iterative.

No I don't think I am. But I do know that you require more than a single programmer for a project and I know that the quality of most "software engineers" is not good enough to sustain a single comprehensive language, let alone a lot of languages that are "evolving" and "iterative". Also I know that even if some domain languages will be available, people will be reluctant to use them but rather "roll their own", much like with APIs.

In that last sentence, you were so close to understanding what DSLs are. Stop thinking of DSLs as something only "supplied", and do think of them as something that people build for themselves, much like APIs.

And finally, waterfall process is back big time with the current trend to offshoring anyway :-)

It is still in your thinking though.

you are thinking about domain languages in terms of large general purpose languages, and this is leading to you to a wrong conclusion. Instead, try equating a DSL with an API. Do you avoid APIs because there is something to learn about using them? I hope not.Also, there is no avoiding acquiring the necessary domain knowledge under any approach, and hence no possibility of avoiding learning. A DSL makes standard (normalises, if you like) the domain knowledge.

Yes, but what if you have to deal with different domains and different languages using different syntax at the same time.

If you are using someone else's DSL but you don't like the syntax, just change the syntax. As for having to deal with different domains, you have to deal with different APIs today.

Sure you can integrate them and there are standard ways of doing so. But still this is overhead and essentially may create more problems than it solves.

Do you find introducing an API to be an overhead that creates more problems than it solves?

In particular when you are confronted with large systems with high developer fluctuation and long application lifetime, keeping complexity low and integration easy is a prime concern.

Yep, and DSL is the best approach so far for reducing complexity.

If I see people struggling using SQL, JavaScript, Java, JSP, Ant and whatnot at the same time, I think it is not because they are "general purpose" but because they are different. So I'd like to keep people/teams working with as little different languages as possible. This makes me a bit wary about lowering the threshold for the creation of a domain language as a general approach in the first place, no more, no less.

The things you are thinking of as domain specific languages don't really qualify as such. Java and JavaScript are very far from DSLs, unless of course the domain is general-purpose computation. JSP and Ant don't address the complexity at the heart of an application domain. As for SQL, while relational data manipulation is a smaller domain than general purpose computation, it is still very large.
There is a second reason why those things aren't good DSLs, that being that you can't look at their syntax and semantics and readily customise them. The DSL approach and supporting tools are all about vastly lowering the cost of introducing a custom-built language.

If other people's taste in syntax offends you, you can define your own syntax for the same semantics. Multiple syntaxes can be in use for the same semantics at the same time.

Do have a glance at the paper I cited, unless learning something is just not on the agenda.

DSLs have been used with great success for over a decade by the Functional Programming community. If you look into this a bit, bear in mind that they often use the term "combinator library" when referring to DSLs. The FP community's favourite use of Monads is for DSLs (a successor to Monads is proposed - Arrows). Also note the arguments in favour of Domain Specific Embedded Languages (DSELs) over DSLs.

Hi G Hermitage,

Your comments on DSLs in FP interest me. Do you have any pointers (URLS?) to resources on DSLs, or combinator libraries, in FP?

Thanks.
--
John

Hi G Hermitage,Your comments on DSLs in FP interest me. Do you have any pointers (URLS?) to resources on DSLs, or combinator libraries, in FP? Thanks.--John

It may be useful to start reading about DSL in FP via the DSL versus DSEL discussion
http://www.haskell.org/yale/papers/icsr98/dsl.pdf

http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/Papers/dsel-hudak.ps

Other sources
http://www.cs.chalmers.se/~rjmh/
http://www.cs.chalmers.se/~rjmh/Combinators/

http://www.haskell.org/yale/publications.html

http://homepages.inf.ed.ac.uk/wadler/topics/monads.html
http://homepages.inf.ed.ac.uk/wadler/papers/monads/monads.ps

http://www.haskell.org/arrows/

Note GHC's support for Arrows
http://www.haskell.org/ghc/

Do let me know if this stuff isn't quite what you are looking for.

It may be useful to start reading about DSL in FP via the DSL versus DSEL discussion http://www.haskell.org/yale/papers/icsr98/dsl.pdf

Thanks! I'll start with the first paper on DSEL.

Thinking out loud: All these are in FP (or logical prog). I'm wondering if DSEL can be done in OOP...
--
John

Thanks! I'll start with the first paper on DSEL.

Cool.

Thinking out loud: All these are in FP (or logical prog). I'm wondering if DSEL can be done in OOP...--John

It is a good question to keep in mind when reading that paper.
I am curious to see what the vendors (e.g. Microsoft) will deliver in 2005 in support of DSLs.

The second paper is "especially targeted for the software reuse community, which is not likely to be familiar with many of these ideas".

The second paper is "especially targeted for the software reuse community, which is not likely to be familiar with many of these ideas".

Are you referring to the paper at
http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/Papers/dsel-hudak.ps? It has the same content as in the first pdf file...

Btw, I had a quick read of the first paper. Given my rusty Haskell, I don't follow all the details (e.g. The Haskell syntax. And this concept of "monads" seems unique to Haskell. Don't recall seeing it in LISP or LML etc.) But the general paradigm is fascinating!
--
John

The second paper is "especially targeted for the software reuse community, which is not likely to be familiar with many of these ideas".

Are you referring to the paper at http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/Papers/dsel-hudak.ps? It has the same content as in the first pdf file...

Oops, so it does. Unify my remarks about the "first" and "second" papers.

Btw, I had a quick read of the first paper. Given my rusty Haskell, I don't follow all the details (e.g. The Haskell syntax. And this concept of "monads" seems unique to Haskell. Don't recall seeing it in LISP or LML etc.)

Arrows is a recent successor of Monads, and using Arrows is the thing to do. However, following what is written about combinator libraries requires understanding Monads.

But the general paradigm is fascinating! --John

Aye!

sveiki kaip tiktai zvalgiausi kokio nors pigesnio web serverio, nes noriu patalpinti savo home page. Gal kokiu patarimu?
Aciu

I very much doubt that this idea can work in "the real world"

I am very certain this idea works in the real world, so are companies like Nokia, Lucent, St. Jude Medical, NASA, SiemensVDO, Audi, EADS, USAF, Vertu and many more. A rich number of case descriptions can be found from the website of the DSM Forum at www.dsmforum.org