Domain Specific Languages aren't for simple use cases . . .
Software product line engineering is about creating a combination of frameworks, re-usable code snippets, DSLs for unbounded variability spaces and configuration managers and feature modelers for bounded variability spaces - often in a structure where ad-hoc custom code can be added for functions that are not worth developing a DSL and an interpreter (framework) or compiler (code generator) for. The trigger point for the effort of developing a DSL providing a ROI depends on the tooling, experience and inclinations of a given developer.
There is no application you can write that I can't generate. There are parts that it may not be worth me generating, but there are patterns of best practices in everything from object modeling to UI design and I think that much more of our skills and best practices can be turned into reusable heuristics than we might like to admit.
I've used DSLs quite effectively in the past. Model-Glue's XML would be the best known one, but there's also ChiliBeans and a never-released project called "Alex" that was basically LightBase (for all I can tell). Alex taught me that writing good applications takes a DSL of such variability and breadth that it's not a DSL.
Therefore, I question your continued use of the term DSL. The broader its target problem, the less specific a DSL. Put differently, if you had a DSL for Web applications that really could generate any application I've written, it wouldn't be very specific, would it?
> There is no application you can write that
> I can't generate. There are parts that it may not
> be worth me generating
This is one of the smartest things I've heard you say. Generation is all fine and dandy when you work on repetitive projects. The apps I work on are so specialized (even when they're master lists and detail views, they have to be "just so" in terms of both UI and backend) to their users and customers that the cost of building a generator would quickly be more than building a well-designed code base, as it'd have to support the same level of variation and tweaking as its outputted lower-level languages.
"Good, cheap, fast. Pick two." Software product lines aren't going to buck that equation. If your customers are OK losing one of the three, more power to ya.
The domain is web applications. Even though your customers' domains may range from gardening to oil and gas production, they web applications they're likely to need are still going to be web applications - and you can describe them in those terms. So, it's still specific to a domain, just not a vertical one.
But I don't think that simple is the right word - or that complexity of the domain has an effect on whether to build a DSL or not.
The reason I use the term DSL widely is because *thinking* about programming as language design - specifically DSL design can inform your development choices. Many people automatically choose to develop a custom tag or an API or an XML config file or a cms to solve a particular problem. By decoupling the process of language design from the selection of one or more concrete syntaxes to project the language into (sometimes one for editing, one for consuming, one for documenting, etc) I find that I'm more likely to choose appropriate syntaxes for a given language.
More importantly, for non-trivial systems, the real problems with language design (API design, DB schema design, XML schema design - they all have similarities at a fundamental level) lie around managing change and evolution - especially of syntax, and being able to look at the literature on DB schema evolution, XML evolution and API evolution and to understand that they are all solving similar classes of problems can be extremely useful when trying to create languages that will be tolerant of grammatical change over time. (Have you ever had to write an API that evolves in non-backwards compatible ways but still accepts calls against older versions of the API? There are some patterns, but it isn't a trivial problem to solve!)
As for the "good, cheap, fast", there is a fourth variable which is sometimes forgotten which is efficient. If there wasn't, then a website built in model-glue instead of with a homemade framework would ALWAYS be worse (because it is cheaper and faster) and using Hibernate would also be a technique for lowering quality as it also speeds and cuts the cost of development.
Like the DSLs implemented in model-glue and Hibernate, those in a SPL can also speed up development without lowering quality. How much they can do so obviously depends on the amount of repetition within an application and the elegance of the distinctions within the language used.
@Sam, Fair point. I deliberately took a little creative license between what I said and what I meant. My intent was to clarify that DSLs aren't exclusively for simple domains. One of the things that drives most DSM people I know nuts is the misconception that only simple problem spaces can be solved by using DSLs and/or DSM. Why didn't I say "DSL's aren't ONLY for simple use cases . . ."? Honestly, I felt really silly stating something that is so obvious (although from frequent experience it's clear that not everyone has got the memo yet). So I chose to make a different statement which is factually inaccurate but more pleasurably challenging. The thought that DSLs shouldn't be wasted on simple master:detail pages and should be reserved for automating the development of solutions in complex and rich problem domains is at least a way to challenge the widely held belief that DSLs are only for simple use cases.
However, as you point out, DSLs are patent medicine - good for anything - just so long as there is sufficient repetition in either the problem or solution domain to justify the effort of developing the tooling required. Talking of which, you see the video by Charles Simonyi? I believe Markus Voelter is doing some work on the CapGemini project and can't wait until it's all non-NDA'd and out there so I can actually get to play with the toolkit!