Unfortunately I missed JAOO this year which was a shame as Intentional are starting to talk about the work they've been doing with CapGemini in the Pensions space.

I know it's old news, but I just got a chance to watch Charles Simonyi discussing the Intentional language workbench and it's really interesting for anyone interested in the future of working with DSLs.

DSLs aren't for simple use cases. DSLs are for use cases where repetition exists within the problem or solution domains. It's why we create classes with methods (a very simple language expressed as an API), it's why we create XML configuration files, it's why we create content management systems (and metadata management systems), it's why we write little languages and parsers, and why we create languages using visual language toolkits like Microsoft DSL tools, openArchitectureWare and MetaEdit+ . . .

[More]

Markus Voelter just had a great paper published at InfoQ. In it he works up a DSL for describing the architecture of a distributed system. It's slightly different from the usual examples but shows exactly the power and value in developing a Ubiquitous Language that is sufficiently formal to be used to generate code.

I've been getting more involved recently with the XP and test driven development lists. One thread that has come up is the appropriateness of unit and integration tests within a software product line. That lead to the following exchange which raises the question: "when does configuration become programming"?

[More]

You're building web applications. You want to simplify and de-skill as much of the work as possible so a programmer is only required for the code that is absolutely unique to a specific project. Describing screens, actions, business object, relationships, properties, validations, value lists and the like shouldn't require someone with a degree in computer science. The question is, what kind of interface do you provide for entering such data and how do you store it? This is a problem I struggle with time and time again as I keep trying different approaches each of which has relative strengths and weaknesses . . .

[More]

I realized while writing a recent article why I seem to obsess over potential variabilities that most developers don't worry about. It is the difference between creating a software product line designed to create hundreds or thousands of web applications over a number of years and architecting an individual application and it's an important distinction to understand for anyone interested in improving the efficiency of their software development processes . . .

[More]

In the first part of this series I looked at how we could describe simple forms more concisely and DRYly. In the second part I came up with some small syntactic wins, but really nothing to justify the approach. I'm hoping to strike paydirt (or strike out and move on) in this third posting which looks at encoding intent of rich fields and client side validations . . .

[More]

In the first part of this series I looked at how we could describe simple forms more concisely and DRYly. I'm not convinced that I made the case that a generator would be "the simplest thing that would work" - it all really comes down to how likely you would be to need to refactor your form markup during a project. Still, in this posting I want to look at some of the additional types of information required to describe a form to see if I end up with sufficient benefits to make it worthwhile to write a simple form generator that'll take XML or method calls and generate the appropriate HTML . . .

[More]

I find that I keep returning to the simplest elements of building web applications, continually asking how we can make our code more concisely express intent. All other things being equal, less characters = less code to review, less cognitive load leading to quicker development times and simpler maintenance (excluding the time for developing and learning the tighter syntax). There is no question that you can go too far with terseness. A quick skim of most Perl programs proves that conciseness doesn't equal maintainability, but in web development it seems to me that there are areas where we are still repetitive and where a DRYer representation of intent would be ideal. One example of this might be forms . . .

[More]

As you start getting into using Domain Specific Languages, one of the biggest issues is how to handle legacy statements in your DSL as your grammar evolves . . .

I'm actually presenting a paper at the DSM Workshop at OOPSLA on our approach to solving the problem (categorizing different types of grammar transformations to allow for the automatic transformation of statements within the language). However, I just saw a really nice posting on how MetaEdit+ handles this. Well worth checking out the video to get an idea of how powerful the system is. Very cool stuff!