We've submitted a project proposal called "Textual Modeling Framework" (TMF) at Eclipse which focuses on textual DSLs and Eclipse IDE integration. Xtext will become one of two initial contributions.
Would be nice to hear what you think about it.
Please, use the newsgroup (the password can be retrieved via this form).
Thursday, November 22, 2007
Tuesday, November 20, 2007
Definition of the term "Language Workbench"
I just had another look at Martin Fowler's article about language workbenches. I read it when it first came out, but didn't remember what the definition of the term "Language Workbench" was like.
Here is what the article states:
I think this point is an implementation detail:
Why should the source be the AST? What is the benefit from a user's perspective. Shouldn't this be transparent anyway?
I don't want to "feel" like editing the AST, because that's why there are concrete syntaxes, they are closer to what I am thinking about.
It's possible to store the information in a concrete syntax (e.g. a Java File) but view and edit it using other representations (e.g. outline views, call hierarchies,refactoring actions etc.).
Eclipse JDT for example has the complete AST in memory to help the user while editing and exploring the code. They don't need to store the Java files in an XML or a database. So if you know how to define a projection on an AST (like Intentional does), you could do this against a temporary, in-memory AST as well.
IMHO storing programs using the abstract form is a bad idea.
UML-Tool users know why:
You can't use existing text editing tools (diff, editors, etc.). You are always bound to the "Language Workbench". And you have to come up with your own version control system.
People who've used graphical DSL-frameworks like GMF know that in addition it is much harder to migrate your code/model to newer versions of your DSL, because you've to do that using the syntax of the stored AST (ugly XML at it's best). (Of course, Intentional may have developed a special "migration tool" for this as well ;-))
So I 'ld like to change the requirements like so:
Here is what the article states:
- Users can freely define new languages which are fully integrated with each other.
- The primary source of information is a persistent abstract representation.
- Language designers define a DSL in three main parts: schema, editor(s), and generator(s).
- Language users manipulate a DSL through a projectional editor.
- A language workbench can persist incomplete or contradictory information in its abstract representation.
I think this point is an implementation detail:
- The primary source of information is a persistent abstract representation.
Why should the source be the AST? What is the benefit from a user's perspective. Shouldn't this be transparent anyway?
I don't want to "feel" like editing the AST, because that's why there are concrete syntaxes, they are closer to what I am thinking about.
It's possible to store the information in a concrete syntax (e.g. a Java File) but view and edit it using other representations (e.g. outline views, call hierarchies,refactoring actions etc.).
Eclipse JDT for example has the complete AST in memory to help the user while editing and exploring the code. They don't need to store the Java files in an XML or a database. So if you know how to define a projection on an AST (like Intentional does), you could do this against a temporary, in-memory AST as well.
IMHO storing programs using the abstract form is a bad idea.
UML-Tool users know why:
You can't use existing text editing tools (diff, editors, etc.). You are always bound to the "Language Workbench". And you have to come up with your own version control system.
People who've used graphical DSL-frameworks like GMF know that in addition it is much harder to migrate your code/model to newer versions of your DSL, because you've to do that using the syntax of the stored AST (ugly XML at it's best). (Of course, Intentional may have developed a special "migration tool" for this as well ;-))
So I 'ld like to change the requirements like so:
- Users can freely define new languages which are fully integrated with each other.
- Language designers define a DSL in the following parts: abstract syntax, concrete syntax(s), tooling (editor(s), view(s), wizard(s)), and generator(s) or interpreter(s).
- Language users can manipulate a DSL using the defined tooling, which can be different editors, actions or wizards.
- A language workbench can persist incomplete or contradictory information.
Thursday, November 15, 2007
Joining itemis
From the beginning of next year, I'll be working for itemis AG (www.itemis.de), a software consultancy which focuses on model-driven software development (MDSD).
Why's that? There are several reasons.
First of all itemis is an excellent employer. Not only have I always had a very good relationship to the management, but they value their employees very highly and they have a very flat hierarchy, which creates a great working atmosphere. As a result they have a lot of talented young software architects which I'm also looking forward to working with.
However the best thing about itemis is that they are very much involved in MDSD and they understand how open-source software development works.
In addition I've come to the conclusion that it is time for me to work within a team in order to provide greater reliability to my customers and the users of oAW (or Eclipse Modeling) in general. At itemis, I'll form a professional team which will focus on open-source development at Eclipse.org as well as international high-level consultancy in the field of code generators, domain-specific languages and the corresponding tooling.
If you are interested in joining such a team, please contact me.
And of course, if you are interested in being assisted by such a team, please contact me as well. :-)
Why's that? There are several reasons.
First of all itemis is an excellent employer. Not only have I always had a very good relationship to the management, but they value their employees very highly and they have a very flat hierarchy, which creates a great working atmosphere. As a result they have a lot of talented young software architects which I'm also looking forward to working with.
However the best thing about itemis is that they are very much involved in MDSD and they understand how open-source software development works.
In addition I've come to the conclusion that it is time for me to work within a team in order to provide greater reliability to my customers and the users of oAW (or Eclipse Modeling) in general. At itemis, I'll form a professional team which will focus on open-source development at Eclipse.org as well as international high-level consultancy in the field of code generators, domain-specific languages and the corresponding tooling.
If you are interested in joining such a team, please contact me.
And of course, if you are interested in being assisted by such a team, please contact me as well. :-)
Subscribe to:
Posts (Atom)