JetBrains have opened the public Early Access Program (EAP) for the Meta Programming System (MPS), an IDE-like language workbench for creating domain-specific languages (DSLs) and programs. It includes a plugin for IntelliJ IDEA which helps to generate Java code from your DSLs.

The Meta Programming System (MPS) is a new programming environment which makes it easy to define your own specialized languages, and use them together with any other language, as you see fit. Your languages also have full IDE support: code completion, navigation, refactoring, and more, and you can add your own specialized support (such as special editors) if you wish. You can even extend existing languages and add your own features. MPS eliminates the programmer's dependence on languages and environments, giving more freedom and power to the programmer, ultimately making programming easier, more fun, and more productive.

Also see the MPS "Hello, World!" tutorial.

...MPS eliminates the programmer's dependence on languages and environments, giving more freedom and power to the programmer, ultimately making programming easier, more fun, and more productive...

For now my opinion is that its overly complex, it does not make my work easier seeing the screenshots I just get the shivers. And it makes me dependent on this ide and language. if this is what is nessesary just to generate a hello world program, I dont een want to know how much work it will be to create a full blown application..

The hello world example was long because it had to define everything first (I hadn't look over all the tutorial...boring) . After you have your new meta language designed, you just write 4 lines of meta language code and you're done implementing your erp to the new client :D... well, maybe not 4, but I think this is the idea...

The hello world example was long because it had to define everything first (I hadn't look over all the tutorial...boring) . After you have your new meta language designed, you just write 4 lines of meta language code and you're done implementing your erp to the new client :D... well, maybe not 4, but I think this is the idea...

Kind of like a 4GL then...

It isn't just HelloWorld program. It is meta hello world. With different generators you can create different implementations of hello world program. It may be swing hello world, that shows dialog with hello world text, it may be web app that shows jsp with hello world or something else.

if this is what is nessesary just to generate a hello world program, I dont een want to know how much work it will be to create a full blown application..

I just measured that it takes 40 seconds to walk 100m, but 70 seconds to drive a car (starting and parking take time, you know).

I don't even want to know how long it takes to drive 500km.

Next holiday I'll definitely leave my car home and walk.

can be found at JavaLobby:
http://www.javalobby.org/java/forums/m91836399.html

Cheers,
Lofi.

J2EE is just very complex to be productive, specially if you have to develop several applications with the same style.
Developing with JSF,SDO,EJB (including EJB3), or Spring + Hibernate is not very productive.
I think that a higher level of abstraction is a solution in some cases (think in COBOL against assembler), and the possibility of define a higher level language to define applications is a good idea.
But...
* It necessary not only a tool for define meta languages, but higher level lenguages already defined and tested to develop applications.
* This idea (higher languages to define applications) can be developed using another more standar and simpler techniques, like XML for defining, template languages (velocity, tl) to generate code, and Java to Plugin behaviour (with strategy pattern for example), etc

<quote>
J2EE is just very complex to be productive, specially if you have to develop several applications with the same style.
Developing with JSF,SDO,EJB (including EJB3), or Spring + Hibernate is not very productive.
I think that a higher level of abstraction is a solution in some cases (think in COBOL against assembler), and the possibility of define a higher level language to define applications is a good idea.
</quote>

yes, agree with you and therefore I find this article from Martin Fowler (about LOP/MDA/MDD) is a bit without a good foundation. He critized MDA without having intensively trying the tools by himself...
http://www.martinfowler.com/articles/mdaLanguageWorkbench.html

For a background: there is a very nice overview article about all these buzz words from Martin Fowler and can be found at:
http://www.martinfowler.com/articles/languageWorkbench.html

In case of MDA/MDD/UML I just can advise him to try AndroMDA (http://www.andromda.org) in its 3.0 version to see how you can be more productive building J2EE application with MDA approach ;-) I myself don't want to miss it anymore...

Because at the end all of those tools/workbenchs (LOP/MDA/MDD/Software Factories/Intentional Programming/"whatever you want to put a name here") are there to make us more *productive* in our works. No more no less.

Cheers,
Lofi.
EJOSA - OpenUSS

Hi Lofi,

I agree with you and I think that MDA can be a good solution.
The good way to avoid complexity is to elevate the abstraction level, that is defining more programming less. With MDA you can do it using UML as definition languages.
But some people prefer text to drawing, and for they there are alternatives to MDA, as:
* MPS/DSL : This thread is about that.
* Java5 annotations: Why not? Java as definition language.
* XML: You can try (or see) a frame to develop J2EE with simple XML definitions in http://www.openxava.org

Hi Javier,

<javier>
But some people prefer text to drawing, and for they there are alternatives to MDA, as: ...
</javier>

again, I also agree with you on this :-) (this discussion is a bit boring of course, since we all agree on the things :-))

So the main concept, choose the best tool for your requirements...

Cheers,
Lofi.

FYI:
From the same chap who invented the Amiga OS.

FYI:From the same chap who invented the Amiga OS.

I was just reading that on their website. Now I am interested. :)

This is absolutely the next big thing that is coming. Another example is Rebol (http://www.rebol.com), which is a relative expression object language to create DSL. Check out the examples and you will understand the power of domain-specific languages.

For now my opinion is that its overly complex, it does not make my work easier seeing the screenshots I just get the shivers.

If you think this looks complex, check out Microsoft's Toolkit for DSL's. I went through the walk through and had no clue what I had done when I finished. At least the JetBrains walkthrough explains what your are doing. Microsoft's just tells you to click this and type that with no explanation as to what you're doing.

Pardon my ignorance but is correct to say we could create these DSLs with plain java code and tools ?

Pardon my ignorance but is correct to say we could create these DSLs with plain java code and tools ?

Of course, if Java didn't have any static keywords and all the "keywords" where dynmically defined. For example, why do you have write

Calendar cal = Calender.getInstance();
cal.setTime(time);
cal.add(Calendar.HOUR, 2);
cal.add(Calendar.MINUTES, 15);
time = cal.getTime();

just to add 2 hours and 15 minutes? or the code you have to write just to check if the time is after 18:00? As a good OO programmer you add a couple of new classes that handles these shortcomings in Java, but what you are actually doing is creating a new DSL for handling time. Isn't better to dynamically be able to "expand" or "dialect" your language with better time handling and get IDE support for your new time "dialect". Being Rebol influenced, I would like to be able to write in Java:

time+= 2:15;
if (time > 18:00) {...

:) Christer

Christer

Thanks, your example was clear. And about Rebol, I had played with it some few hours today. Thanks too ;)

From Martin Fowler article:

If language workbenches live up to their hopes, in ten years time we'll look back and laugh at what we now think DSLs should look like.

Ironically, although crucial for surviving in current capitalism , IT projects had big impact on job marketing in last decades. Some people had to recycled itself but eventually many people simply lost their jobs, in all economics fields and countries.

Now if the statement above is true (I am not sure if I want to believe but I think it kinda can be from what I've learned today) eventually the IT industry itself (products and services) will realize we will have trouble times ahead...

Sorry by off topic, I dont have a blog.. ;)

Err, I misread my own quote. Instead of

DSLs should..

i thought was "programs should be".

Ironically, although crucial for surviving in current capitalism , IT projects had big impact on job marketing in last decades. Some people had to recycled itself but eventually many people simply lost their jobs, in all economics fields and countries. Now if the statement above is true (I am not sure if I want to believe but I think it kinda can be from what I've learned today) eventually the IT industry itself (products and services) will realize we will have trouble times ahead...Sorry by off topic, I dont have a blog.. ;)

I'm going to be pragmatic and say, simply, I'm not worried.

Let me give a crass and simple example.

Lawyers.

They're not going anywhere, and have no fear that their position is going to dry up.

Why?

Because what lawyers deal with most (beyond those that basically file paperwork) is the interaction and relationships of the laws. As we get more and more laws, these relationships get more and more complicated.

Laws aren't written in "plain english" because they are taken very literally, yet can be applied differently. Lawyers are just like hackers, trying to get the system to work for their clients.

And, it's basically not getting any simpler.

Sure, there are "Make your own corporation" kits, "Write your own Will", etc. etc. Just like more information and accessiblity make the Stock Market "easier to use".

But look at your local rules, codes, guidelines, etc. from all of your assorted authorities (local, country, state, national). They are there in plain site, like Open Source software. Anyone can read these things, but to most, including smart people like you or me, it's inscrutable and unparseable. Thus lawyers.

When it comes to computer systems, which, ideally, are deterministic machines, WE, the computer geeks, designers, and programmers are the "lawyers" of thse systems.

We understand the laws, and we know all about not just the laws, but the back room deals, who knows who, etc. that makes the systems REALLY work. That's why we have J2EE experts, embedded system experts, Window experts. Just like in the law you have different disciplines, so do we.

Our systems are not getting any simpler, their interactions are getting even more entwined. With our faster machines and more resources, we just throw more at them to make them more complicated.

We're lucky. Most of the time we're dealing with deterministic machines not subject to the whims of human emotion or judgment...MOST of the time, at least so it seems. But how many of use have simply "reloaded Windows" to fix a problem?

So, we're not going anywhere. DSLs or no.

This is a very good example of where two different things are compared as if they were of equal time.

Calendar cal = Calender.getInstance();
cal.setTime(time);
cal.add(Calendar.HOUR, 2);
cal.add(Calendar.MINUTES, 15);
time = cal.getTime();

Is an exercise in using one particular library API.

time+= 2:15;
if (time > 18:00) {...

Could be thought of as the same. But get this: just as someone would have to implement the specifics about the += operator, the 2:15 time-notation format and the > operator, one could just as easily (harhar) implement something like:

time = Time.forNotation("2:15");
if (time.isAfter("18:00")) {...

I'm not arguing agaínst anything other than your comparing of the "language approach" to the "library approach".

This is what the Groovy-folks do aswell. They'll whip up an example of how groovy syntax combined with their sql interface requires very little code in comparison to something like JDBC.

As I also mentioned, you can (and should!) create or use an API like the one you describe. But will your time-API "dialect" get any compiler errors, syntax high-lighting, keyword completion, or refactoring help, and all other nice stuff that mordern IDE support you with? Nope, that together with code that is usally harder to read, understand, and maintain are the major disadvantages with the API approach. As you probably have noticed the java community should really benefit from a formal way of specifying DSL. For example, Groovy, Arch-Java, EJB, JSP, JSTL, JSF, all OR-frameworks like Hibernate, Ibatis, etc are actually domain specific languages wannabees that would greatly benefit from a formal way of "dialecting" or extending the java language.

But will your time-API "dialect" get any compiler errors, syntax high-lighting, keyword completion, or refactoring help, and all other nice stuff that mordern IDE support you with? Nope, that together with code that is usally harder to read, understand, and maintain are the major disadvantages with the API approach.

As far as I understand comde completion and other cool IDE features will be available only in specific DSL editor.
You are proposing to mix several DSLs togethere in 1 source code file.
That would be not only extremely hard to read and write. But also impossible to provide all IDE features you mentioned.

So i would rather stick with libraries and watch you guys drown in DSLs :))

DSL experts, any great links to post here?

My quick interpretation is that by building a language/library set that is specific to a given domain then applications can be developed/maintained in that domain much more easily.

Having a system that can help you create these DSLs more easily is great, especially if built on Java's huge functionality set.

The object of a DSL is the opposite of a full blown language like Java. Instead of a very feature-rich, powerful but low-level language you build a very specific but terse language that allows applications against a specific domain to be created quickly and with much less code.

The object of a DSL is the opposite of a full blown language like Java. Instead of a very feature-rich, powerful but low-level language you build a very specific but terse language that allows applications against a specific domain to be created quickly and with much less code.

DSL looks indeed very promising. However, who is able to shape correctly and completely a DSL which covers all the needs of a particular domain?

Just an example: DSL for banking, finance, automotive, etc.

Once again, a need for standardization will arise. And times will be long.

The object of a DSL is the opposite of a full blown language like Java. Instead of a very feature-rich, powerful but low-level language you build a very specific but terse language that allows applications against a specific domain to be created quickly and with much less code.

DSL looks indeed very promising. However, who is able to shape correctly and completely a DSL which covers all the needs of a particular domain?Just an example: DSL for banking, finance, automotive, etc.Once again, a need for standardization will arise. And times will be long.

I guess I was thinking on smaller domains not an entire industry. I'm not even sure it would be prudent to try to make a DSL for an entire industry.

DSLs are usually custom languages, just as application APIs are usually custom to a particular enterprise. If there is no standard API for an industry, don't expect a standard DSL. Linking DSLs to standardization is to confuse DSLs with the monolithic general purpose languages with which we all are so familiar i.e. DSLs as not analogous to Java, C++, C#, ... where creation of a new language is a major matter, and start thinking custom creation, flexibility, immediacy.

Usage of DSLs may somewhat facilitate an industry moving to a standard collection of DSLs, because the DSLs will distill the interface between usage and implementation more clearly than APIs and so promote examination of essential interface differences.

Also, there won't ever be just one DSL involved in an industry. Look at the number of applications that a player in that industry presently has, and maybe halve that number to arrive at the number of DSLs they would use in future. Bear in mind that future collection of DSLs will support more function than the collection of present day applications do. The relationship between the number of present day applications and number of future DSLs is something that will be better known as enterprises convert to DSL usage, giving us some experimental data here.

DSL experts, any great links to post here?

Have a look at what Sheard
http://www.cs.pdx.edu/~sheard/
has written on the subject, perhaps starting with his
Evolving Domain Specific Languages paper
http://www.cs.pdx.edu/~sheard/proposals/EvolvDsl.ps

Sergey Dmitriev, the CEO of JetBrains
http://www.codegeneration.net/tiki-read_article.php?articleId=60

Andy Evans at Xactium
http://www.codegeneration.net/tiki-read_article.php?articleId=68

Krzystof Czarnecki, author of 'Generative Programming'
http://www.codegeneration.net/tiki-read_article.php?articleId=64

Charles Simonyi, of Intentional Software
http://www.codegeneration.net/tiki-read_article.php?articleId=61
http://www.edge.org/digerati/simonyi/simonyi_p1.html

http://java.sys-con.com/read/101674.htm

Dmitriev and Fowler make some excellent points.

Fowler considers example-driven programing, which is something mainstream OO developers have no exposure to. He specifically praises Subtext, which superimposes dataflow graphs on source text. Subtext also embraces refactoring as a first-class coding skill, beyond what a best-of-breed Java IDE can do.

Dmitriev notes that an editor gives a view of an abstract syntax tree, which shouldn't be limited to a particular traversal such as a one-dimensional sequence of text statements. That's the first step in breaking away from direct editing of a source text file. He mentions decomposing editor real-estate into language-meaningful rectangles. He doesn't mention that rectangles can be folded or have graphics.

Clearly Fowler and Dmitriev are laying the foundation for visual programing, though they deny it and bash UML. UML-2's prior lack of semantics is an outdated complaint of Fowler's; UML-2 activity diagrams now fully formalize processing semantics. So UML-2 is now a Turing complete programing language.

Both Fowler and Dmitriev lean heavily on generative metaprograming for supporting DSLs. They frown on XML, but I wonder if they've read XML and the art of code maintenance which exposes the desirability of XML programing languages for Aspect Oriented Programming and Language Oriented Programming thanks to the superior transformability of XML. XML is more amenable to generative metaprogramming than traditional grammars. And since XML is inherently extensible, things like embedded/internal DSLs come naturally. Doclets and annotations are mere hacks in comparison.

I hope to see more from the ongoing direct collaboration of Fowler and Dmitriev.

Subtext also embraces refactoring as a first-class coding skill, beyond what a best-of-breed Java IDE can do.

What I like best about the research of Dmitriev and Fowler is that they seem to regard direct manipulation as the future of programing. Eg, refactoring with Subtext is almost entirely drag-and-drop, without the clunky refactoring menus and wizards of IntelliJ and Eclipse. Likewise, Subtext's coding-by-example doesn't divorce coding and debugging into two separate chores like best-of-breed Java IDEs do. So the coding environment is more immersive, thereby reducing strain on the developer.