MetaCase Job Offer

MetaCase is looking for a Product Marketing & Sales Manager. If you feel you have the right entrepreneurial attitude and like to work in a dedicated team, looking to evangelize DSM and MetaEdit+ as the most advanced model-driven development solution, then I recommend you send in your application.

With MetaCase you get an opportunity to work with some of the industry's most recognized thought leaders in the field of model-based development. We don't need you to be an expert in this area, we DO need you to be genuinely interested and a fast learner with sharp thinking skills. You are skilled in relationship building and know how to "do a room" whenever a networking opportunity presents itself. You are a good negotiator, capable of seeing the big picture even in stressful situations and able to bring new ideas to our team to further promote our product.

If you believe you can provide a healthy contribution to MetaCase then we are ready to provide you with an inviting work environment, a fun team of people to work with and a competitive compensation package.

Send your application to jpt[at]metacase.com

OOP 2007: Vendors step into DSM

OOP 2007 showed me that now more vendors see DSM as the way to go.

Gentleware, known for their UML tool Poseidon promoted DSL-based editors built on top of the Eclipse GMF platform. When I asked Marko Boger about what happens when the customer needs the inevitable change to the supported DSL language his answer was: "Well, then we make more turnover". He could also have mentioned that the customer loses all models made previously and that the customer has to wait until Gentleware makes the new editor available to them. Not exactly the most flexible solution if you ask me, which might have been a reason for him not mentioning it. Still it is nice to see that someone who earlier concluded that UML profiles are sufficient now agrees that in order to generate code, developers need to work with domain-specific languages.

It was encouraging to see so many people participating both the MetaCase vendor session and Juha-Pekka's conference session. Especially the fact that some intelligent discussions took place about defining domain-specific modeling languages among the audience showed me that the audience has matured in this area. Where 3 years ago we had to explain to nearly each and every one what DSM meant now people we more interested in the "how to do it". They got the idea and agree with the benefits it offers, now they want guidance in how to get started with it. I see it as a big step forward.

Some of the best hitting comments I got from attendees were: "MetaEdit+ is the reason why Rational invented UML as their tool could support only one modeling language", "MetaEdit+ is MDA done right, 10 years ago" and "These people are the only ones who know how to do model-driven development correctly"

Webcast: Modeling with a Domain-Specific Language

We published a 12-minute informative webcast on domain-specific modeling. In it, Juha-Pekka directly compares UML with a DSM language-based approach. This makes the difference between them very clear.

Have a look here.

DSM Focus on Code Generation Event

Code Generation 2007 promises to have a significant focus on domain-specific modeling for model-driven development. With Microsoft and MetaCase already signed up as sponsors, I believe we can be quite sure of this.

The event organizers have managed to get some influential speakers in the area of MDD: Axel Uhl from SAP, Markus Völter, Steven Kelly (MetaCase), Andrew Watson (OMG) and of course the people from the Microsoft DSL team.

If I understand correctly, the program promises to give attendees a valuable learning experience with a rich mixture of sessions from 75 minutes up to well over 3 hours.

DSM growing, UML slowing

The number of hits on Google for the string "domain-specific modeling" is clearly showing exponential growth. Today Google treated me with 88,100 results, making the graph I created 2 days ago (above) already outdated (darn...it has that same characteristic UML models also have).

I was interviewed by the German magazine "ComputerZeitung" for their focus on modeling and model-driven development, the article is available here.

Reading it myself, it surprised me to have the magazine report Bran Selic talk about a new wave of UML:
"Wir bauen substanzielle semantische Definitionen ein. So wird die Sprache ausdrucksstärker und zu einem besseren Kommunikationsmittel."

Translation: We're building substantial semantic definitions into UML. This way, the UML will become more expressive and a better vehicle for communication. In other words, it seems the OMG thinks it a good idea to make it even more complex and even less suitable for code generation: Adding precise semantics to a general-purpose modeling language, leads you to some sort of ehr... general-purpose-domain-specific modeling language (hmmm try to market that).

UML is poorly suited for generating anything else from it than simply a copy of what it represents. Normally this means documentation. Adding precise semantics to the UML means the committee of tool vendors (all with their own agendas) need to agree on those precise semantics, which is impossible, period. The precise semantics will most likely end up being very loosely interpretable precise semantics, that you then can probably extend with semantic profiles of something like that. The end: a 160,000 page UML specification with the "U" clearly meaning "universal". Great idea Bran, let's add some more stuff to the UML.

The OMG seems to struggle with its mammoth specification, a new wave is needed because competing, disruptive technologies (domain-specific modeling) is eating away at the base. The only thing to do: move upmarket, add more stuff to your product (read this thought leading book on it).

A mark on the wall of UML's demise, is Telelogic, which now offers its UML tool for zilch, all you need is register and download. Their sales team will then no doubt hunt you for costly add ons. The UML tool market is under heavy stress, with hundreds of free tools which are perfectly fine for UML since you cannot generate all that much useful stuff from the de-facto modeling language anyway. Some tools claim they do however, and therefore cost mucho, you'll need to fork-out a substantial budget. Then, according to a Compuware-sponsored laboratory test (wow, must be very reliable) you could achieve a productivity increase of 35%. According to the Compuware marketing professionals this is a real "Landmark".

Funny that you do not see so many more of these studies isn't it? After all, MDA and UML are already so widely applied if you listen to the MDA tool vendors and OMG honcho's. Really, where are all the success stories of UML? Care to share one?

The cost of building DSL / DSM tools

Most of the costs of developing software are attributed to the maintenance phase (often I hear 80%).

I never heard anyone disagree with that.

It makes sense to get your design right from the start - as mistakes in the design phase are normally the most costly ones to solve later on - a good initial design, though, does not eliminate or necessarily reduce the amount of cost that goes into the maintenance phase.

Often I hear the question on how software development with DSL's relates to this wisdom. It's a good question with a simple answer, but there is a better question.

The simple answer first: DSM languages (or: DSL's) aim at development on a more abstract level. The maintenance work, therefore, is also done on a higher abstract level, making performing this work more effective and thus less costly: a change in requirements is much easier to implement. When it comes to getting the initial design right, DSM languages provide better support than general purpose modeling or programming languages: The "wisdom" of the expert and rules imposed by the underlying architecture are (or should be) encapsulated in the modeling language and prevent silly designs. This does not mean that the developer can be a brainless chimp, in fact the more knowledgeable he/she is about the problem domain the better (just like when not using DSL's), but the support he/she gets from the language in getting the design right simply is more prominent.

The better question, however, focuses on the tools for implementing DSM languages and generators (or MDD if you will):

How does the issue of maintenance and "getting the design right" relate to DSL tools?

Why should building your own model-based code generation tool (or tool-chain) be any different when it comes to the design and maintenance issue? Isn't it likely that 80% of the cost of building your DSL tool (or MDD tool chain) will come down to maintaining it? I dare say that the 80% is a rather mild estimate.

Sure, you can get an MDA tool, based on the industry-standard UML language. You will draw complicated pictures, outdated immediately, you won't generate anything useful and you will have very little tool maintenance. You can claim you do MDD but you never even have the time do it or to evaluate the true MDD alternative because you're so darn busy all the time maintaining your code. For you, reverse engineering must be a blessing...

With DSL/DSM tools you shift (most of) the maintenance effort to the language (and generators) you are using. Just like your code in software development today, now your modeling language(s) and generator(s) will need maintenance: You will not get them right immediately and even if after a while you get them right you will still need to change them later on.

So, are we no step further with DSM? Do we just shift the maintenance work to another, more abstract level? No, with DSM less developers will do the maintenance work, preferably the smarter ones and their work helps the less-smarter ones (who are still smart, just a bit less) do smarter things faster.

When using DSM/DSL technology correctly, the major chunk of your work over time will be focused on updating your modeling languages and generators. In my opinion it makes sense to choose a DSL/DSM technology that supports this fact: You do not want the majority of your developers to wait for a couple of days/weeks until the expert provides them with a new, thoroughly tested version of the modeling language, do you? And what about having your developers manually update all models made with the previous version of your modeling language when a new version comes around? That's a lot of maintenance work man. You can claim you're doing DSM or DSL or even that you have a Software Factory, but the factory sucks, and you probably do not have the time to claim it.

Microsoft have a pretty good solution to this problem with their DSL tools: A factory for making factories. I do hope they improve it though as I hear it does have some significant drawbacks. It's been ridiculed but they did think a lot further than the people doing the Eclipse GMF/GEF. The latter have not even started thinking about the maintenance problem, making the framework ideal for code-savvy pet-techies who just like to build stuff and care less about doing (or staying in) business.

The risk involved with DSM/DSL technology can be reduced in several areas:

• Making sure you build a good language and generator
• Adopting a supporting technology that is forgiving to the mistakes that you WILL make
• Tool and consulting support by an organization who have experience in this area
• Assigning tool-evaluating techie who understands that technology is there to support business, not for technology's sake
• Understanding the social and organizational changes that DSM/DSL technology will introduce in your organization and getting support for it
  

Vendors and tool comparisons

I've been pretty amazed (yep...understatement) of how some vendor-executed (fabricated is probably a better description) tool comparisons happed to end-up in tool evaluation reports, which in turn amazed me that these things ended up there, copy/pasted in the first place.

Food for thought: Vendor-executed tool comparisons are always subjective

Don't use a vendor provided tool comparison in your evaluation report. The fact that the vendor-executed tool comparison shows that vendor's tool scoring best in most (some vendors take it that far to score best in all...ghehe) categories, should ring a bell: Something fishy is probably going on.

It's easy to twist a tool comparison in your own advantage:
a) you lie (it's called marketing)
b) you base the competition's data on some old, no longer supported product version that no one really remembers
c) you take only those categories (and give them complicated names) that you score good in, and lie about the competition

It's not the vendors fault really. It is ,however, embarassing to see a tool comparison literally copy/pasted from a white paper or website end up in a tool evaluation report. Sure it saves time making the report, but the potential for losing a year or two in extra work due to your wrong choice or laziness in making the report is very much there.

In a bid to help domain-specific modeling tool evaluators, we added a MetaEdit+ feature list to our website. We did not feel our opinion about a competing tool should matter to you, hence we left the column "other tool" empty, for you fill out. Also did we not feel qualified to categorize our tool features as "best", "average" etc. so we just kept it to "supported" or not. Should you feel we missed some categories then we will be glad to add them there.

More on templates

It was nice to see Microsofts' Gareth J agree with me when it comes to providing DSL tool users with ready language templates, i.e. generally a bad idea. It just leaves me to wonder about Microsofts' DSL tool strategy to provide users with complete ready languages (not leaving it just to templates but go the whole nine yards in providing organization A a method that organization B says is probably best for them, without knowing a whole lot about how exactly software is developed in organization B). At least, this is what the media tells me to be the strategy Redmond will follow and of course the media does not always get it right, but this most often happens when editors think they understand a new technology (...but then they don't...and still write a story on it), my guess is that they often get it right on strategy. Especially when interviewing and quoting team members and project leaders.

I wrote my earlier post on language templates with in mind the idea we at MetaCase have that it is probably best to allow the organization that uses the DSL to define that DSL... themselves and make defining tool support for the DSL (in the end that is what we need) convenient.
There are several reasons for this conclusion:

1. MetaCase employees only know a lot about Domain-Specific Modeling tools, we do not pretend to know how software is or should be developed in different vertical problem domains
2. Providing a ready-language to many (say more than 2) ALWAYS leans toward the one-size-fits-all problem that we see with UML: users want to change it to become more domain-specific, which if you would, often suffers from its original version legacy: The template problem.
3. Allowing users to define their own, makes them think more and in different ways about their problem domain, which has the effect that they will start to understand their problem domain better, which is undeniably a big advantage, which can lead to more concrete advantages

Of course there may be the argument that MS focuses on horizontal domains instead of the presumably vertical domains that we at MetaCase focus on but even then I feel that many of my arguments still stand: It is better to allow companies to define their own DSL and code generators, this is what makes them really domain-specific, which provides the biggest benefits.

Webinar: Domain-Specific Modeling

Domain-Specific Modeling promises to change software development in many companies by changing models from being a bunch of out-of-date rectangles, diamonds and lines to executable representations of solutions in domain-terms. Models no longer depict the soon-to-be-roundtripped, visual representation of the code you need to write later. Instead, the implementation is generated automatically and completely from your high-level models, similar to how compilers generate full assembler from current programming languages.

A free webinar by a true expert in this field on December 14 will give a very concise explanation of domain-specific modeling in an easy to swallow format. So sit back, relax and learn. Learn what?

2 things basically, what it is and whether it makes sense to look into it further. Register here.

Released: MetaEdit+ 4.5

Defining modeling languages graphically in the new MetaEdit+

Today we are releasing the latest version of MetaEdit+. Version 4.5 is stuffed with a lot of significant improvements compared to its predecessor, like to name a few of these:

• Graphical metamodeling (see above)
  
• A whole new generator definition system, that:
• instantly validates generator scripts
• provides a debugger for defined generators
• provides "live code": generated code links back to its original model objects for tracing
• allows you to build more powerful, better generators, faster
  
• Model, and metamodel import/export via XML
• An improved SOAP/WebServices-based API that provides access to models, metamodels and MetaEdit+ functionality
• More powerful metamodeling capabilities
• Symbol import in SVG & Bitmap formats
• A much improved modeling environment

To sum it all up, we clearly focused on allowing developers to obtain tool support for domain-specific languages faster and more conveniently. As an indication: Just for fun, yesterday I "equipped" MetaEdit+ from scratch with Use Case modeling in about 15 minutes. Try that with the visual studio DSL tools or the GMF framework from Eclipse and you'll grow a beard...a big one.

Additionally, our development team put in a big effort in opening MetaEdit+ up, allowing it to work via open-standard SOAP-Web Services, via ANY programming language with ANY tool.

To top it off, we now offer companies, their first license of the new MetaEdit+ Workbench (introductory license) at 150 Euro! Additional licenses carry our normal pricing. There is thus no reason to miss out on experiencing how much value, speed and convenience MetaEdit+ offers.

Free training on creating DSM languages

At the coming OOP 2007 conference in lively Munich, expo and conference attendees have free access to all vendor tracks. MetaCase will provide one that teaches participants "hands-on" how to build a domain-specific modeling language and how to obtain tool support for it. Our aim is to provide participants with something a bit more valuable: Leaving the class room after 90 minutes feeling you've really learned some skills, instead of being made aware of a bunch of product features.

People should bring their own machine, and may opt to bring their own DSM tool. For those that wish to use MetaEdit+ we'll provide them with a copy. From a skills perspective, it's irrelevant what DSM tool you use really. Whether its Eclipse GMF, DOME, GME, Microsoft Visual Studio DSL's, MetaEdit+ or any other tool that can support DSM languages, they're all welcome to the session!

MetaCase offers a free ticket, you can get it here. It also provides entrance to all keynotes, product sessions, special training, vendor tracks and the expo.

New Event: Code Generation 2007

Mark Dalgarno, editor of codegeneration.net pointed me to a new conference, Code Generation 2007 on, well, code generation that his company is organizing in May 2007 in Cambridge UK.
The conference is currently seeking people and companies that are interested in running a session and/or sponsoring the event.

With very few (to my knowledge at least) events on code generation in the UK, this seems like an excellent opportunity for many companies to get exposure.

OMG: "MDA and DSL are the same!"

I came across a webcast by OMG Chairman and CEO Richard Soley in which he claims that MDA and DSL is "the same thing really", since MDA provides DSL's as well via MOF and UML profiles. I agree with Richard that you can get a DSL via MOF and UML Profiles, except that this way we'd have to bin that "little issue" of making sure we get a quality DSL (or DSM language, a term I rather use).

So, what defines the quality of a DSM language? Of course that is debatable but I would suggest "Its ability to define an application correctly, conveniently, concise and completely, with a minimum amount of effort." as that provides the basis for being able to generate 100% of the application's implementation in code. In this light, the lack of quality provided by MOF and UML Profiles leads to incomplete code generation. Richard mentions 70% code generation "which is not bad". Well, it's not good either since it creates the need for keeping models and code synchronized via round-trip engineering, which makes it pretty bad in my book.

When it comes to convenience, Richard "rubishes" the concern so many developers have with UML being too complex, by saying that he - as a man - "likes to have a big tool box", because he "wants to use a tool that is best suited to the problem at hand." To me it seems that Richard's big tool box contains just one very big and complex tool that you can use for whatever it is you wish to develop, therefore not making it very well suited for any specific problem at hand. It's "OK, nothing more", which already may be overstated. Don't give me that crap about it being great for everything.

Providing a developer or company with a great tool for modeling and generating the software he/it wants to build, means providing the ability to conveniently build an own tool that precisely matches the domain-specific requirements, in the shortest time possible. Not by providing a one-size-fits-all big man's box of tools that are "pretty OK" for doing almost anything.

MDA and DSM (using DSL's for generating code) are NOT the same. The OMG would do good to stick to its own MDA vision, abandon it or make an attempt to define it more concisely, instead of positioning it as the greatest thing for all of mankind while trying to jump multiple bandwagons and please everyone's agenda in order to justify its own existense.

Rants, Strikes, Planes and Wheels

It seems OOPSLA has its way in causing many to rant about reinventing wheels, not buying the latest book, airlines, stupid business decisions, blatant tool marketing and what have you. I suppose it's the "lovely" autumn weather and returning darkness that triggers our emotional outbursts.

The good side of it all: the DSM Workshop (6th time) at OOPSLA keeps on growing in size, a clear indicator that we're making progress in our market creation activities. Also the media are now clearly picking-up on the issue on a larger scale, so are the analysts..... so are businesses, and good for it!

With the new MetaEdit+ on its way to being officially released soon, MetaCase is making it significantly easier and definitely more convenient for businesses of any size to start developing software more effectively (faster, less complex, better quality, less cost, less testing, less development time) than with all-purpose UML.

Despite the ugly weather and everybody's rants, I am delighted to see this happening.

MDD & Product Lines Conference review

Markus Völter, one of Germany's most respected consultants in the area of software engineering and software technology, also founder of Software Engineering Radio posted some comments about the recently held Model-Driven Development and Product Lines Conference in Leipzig, that I blogged about earlier.

He comments about using MetaEdit+ being a great tool for building modeling languages and his wish to use MetaEdit+ as a front-end to Open Architecture Ware (oAW) generators. This is something that one of our contacts is actually working on right now, his comments were that "currently the process of assembling a working and useful editor with GMF is quite painful and time consuming. It's just not feasible for larger models." and that “Modeling with MetaEdit+ was indeed quite convenient and a lot easier to accomplish than trying to achieve the same results with Eclipse GMF.”

MetaEdit+ already provides the ability to plug oAW into it, via the model and meta-model import/export facility in XML format, which oAW accepts. Alternatively, there is also the SOAP/Web Services-based API that MetaEdit+ provides. There should thus be nothing stopping Markus from using MetaEdit+ more intensively :)

DSM @ DevWeek 2007 in the UK

Juha-Pekka has been invited to speak about defining domain-specific modeling languages and generators at DevWeek 2007, the UK's biggest conference for developers. On Thursday, March 1, JP will "demystify DSM, open the lid on OMG's MDA and shine a light on Microsoft's Software Factories".

Besides showing why UML-based MDA is generally a bad idea (do notice that not a single session in the whole conference deals with UML-based MDA anymore....hmmm maybe JP should just leave the lid where it is and focus on stuff that works), he will discuss the steps developers can take toward defining their own modeling languages - those that suit the work to be done better and therefore making them more effective - and generators, making sure that whatever it is the generator spits out, is what they want it to spit out.

From a guy with over 15 years of experience in this field, you can expect the session to be enlightning, well worth a visit.

The problem with language templates

When the idea behind DSM and MetaEdit+ has just settled in the minds of many people I talk to - these usually include developers, their bosses, magazine editors and analysts - I regularly get the question about language and generator templates: "Do you offer any ready-made templates?"

Although this would seemingly make adopting DSM faster by offering a "more-ready" solution that users would only need to tweak a little, it actually falls into the "one-size fits all" trap that UML offers. Ready-made templates try to do what ready-made templates try to do: offer one solution to many, which is what DSM tries to avoid for productivity reasons. A solution that needs to work for many, even if they are all active in the same horizontal or vertical, has to make compromises in the design of the modeling language and therefore the code generators, which negatively affects the productivity boost that DSM seeks to offer.

What we at MetaCase see, is that there are huge differences between problem domains, even between companies in the same vertical that make the same product. They benefit from DSM just because they can design the modeling language to fit exactly the way they wish to design their products/systems: Not surprisingly, the desing languages they use differ completely from one another in terms of the concepts they use, the rules that apply to them....the abstraction level they work on.
Providing them with a ready-made language template would:

• Get them started on the wrong path: They would not think carefully about their problem domain and attempt to create a language that would fit it. Instead, they would take the ready-template and try to fit it to their problem domain via all kinds of complex adaptations (similar to the UML profiles approach): Let's do it quick and ugly.
• Because of this, limit the possibilities and flexibility to generate the code they need, leading to a need to reverse engineer and round-trip: A road to nowhere...

The problem with language templates is that they exclude the much better solutions that exist for an individual problem domain. Although the idea seems a good one at first thought, once the idea of DSM matures however, providing or using ready-made templates seems a lot less attractive.

DSL: How to start creating your own language

This is becoming a more important issue for many, since modeling with DSL's or DSM languages is clearly picking up steam. Some stuff has been written about it but I feel it's definitely something that deserves more focus since it is such an important aspect of DSM. Sure, many experts, evangelists and even MDA-guru's speak about meta-models and, if you're living life on the OMG matrass, the good and bad of MOF. This is mostly the "WHY". I've seen only few give advise on the "HOW".

It seems that once you get into a serious session of DSM language creation, the tendency is to push it as far as you can....which often is the wrong thing to do: You're re-inventing UML.

Some time ago, Juha-Pekka wrote a great article on DSM language definition (for Software Factory aficionado's and Gareth J: This is the more correct acronym for a graphical DSL) and he's got another one coming soon in Methods and Tools.

Business before Pleasure

With Model-based development based on domain-specific modeling languages getting more interest from businesses, I have noticed several times now that teams blindly decide to build their own DSM tool using freely available frameworks, like the one offered by Eclipse, only to realize a few weeks (or months) later that the effort this requires is more than they initially hoped for.

There are many facets involved with building your own MDD tool like providing the ability to define your own modeling languages and generators, defining and associating the visual representation to the defined language, defining tool behavior, providing the means to immediatley test your languages and generators while defining them simultaneously, sharing your languages, generators and models with others, possibly even on hetrogeneous platforms, providing integration with other development tools, supporting different DSM languages at the same time etc. Building your own DSM tool does not end with your first version of it.

It's highly unlikely for one that developers will get their first DSM language right the first time, or that this will be a good DSM language. Furthermore, it is very likely that even a good DSM language will need to change over time, which will have its effects on the models that have been created with it. Normally, defining a DSM mechanism requires developers to concentrate on both language definition and generator definition simultaneously. If those developers also need to concentrate on making sure there is reliable tool support for their continuously changing definitions, the effort becomes very complex, very time consuming and very costly.

In order to make DSM a success, developers need to put the goals of business before the pleasure and challenge of building their own DSM tool from scratch....which is what it comes down to, really, when using free frameworks.

At MetaCase, our vision is that developers should be allowed to focus on building good DSM languages and generators, where the environment helps them in doing so by making the effort convenient and transparent. Developers should not be bothered with the intricacies of creating tool support for their own languages and generators, a good environment automatically provides the tool support for them. Not just for the "using them" part, but also for the "defining them", "sharing them", "maintaining them" and "integrating them" parts.

You don't want to spend man-years in developing a tool that in the end will make you a lot faster just until it inevitably becomes obvious that you need to make a change to the language, generator or tool...........and you can start all over again. This may be nice for people that like to build stuff, just for the fun of building stuff, it completely offsets the benefits the DSM approach has for the business goals.

Thankfully, some people have realized this in time, before having wasted precious time on building from scratch:

“Modeling with MetaEdit+ was indeed quite convenient and a lot easier to accomplish than trying to achieve the same results with Eclipse GMF,”
Ulf Hesselbarth, SIEMENS Communications.

"MetaEdit+ provides convenient tool support for domain (meta-)modeling as well as for the definition of concrete instance data, which is simplified by a domain-specific graphical user interface. Easy to learn — easy to use!"
Cord Giese, Research Analyst, Delta Software Technology.

"MetaEdit+ is the most sophisticated DSM tool,"
Scott Ambler, Ambysoft

"Even as a beginner with MetaEdit+, I could define a domain-specific activity language in about six hours - design, testing and one failed trial included,"
Laurent Safa from Matsushita Electric Works, Ltd., Japan.

"MetaEdit+ was the most flexible tool, allowed us to define our own design syntax quickly, and make fast experiments while developing the method,"
David Narraway from Nokia.

Struggling with Microsoft's wording

GarethJ is wondering if MS's "DSL" tools might make people think MS is targeting textual languages. Remarkable.....especially when knowing that DSL's have for decades been textual languages. It remains a mystery to me why MS have not opted for the more correct "DSM languages", with the "M" representing Modeling. I suppose some marketing buff up in Redmond decided "DSL" to "sound" better and of course......it would save some ink.