> Essentially, you're saying that the point is not to use
> DSL's. The benefits of DSL's are explained everywhere,
> so I don't think I need to repeat them here...
DSLs aren't a gimme. In production code, produced and maintained by a team, and iterated through a lifetime of morphing business requirements, DSLs are almost always more of a hindrance than a help, because they impose an additional cognitive burden on their manipulators.
They're lovely to write, and elegant in a closed system, but in The Real World(tm) where we all live and work, we don't generally have the luxury of writing software to solve those classes of problems.
This is called the "Real World" fallacy. Your techniques are unfamiliar to me, and I am in the "Real World", therefore you are an academic who doesn't actually solve real world problems.
DSLs are used in production code, and solve real world problems better than ad-hoc repetative code does.
Whenever you're creating a function, you're defining a verb in your domain-specific implementation. Whenever you're creating a class / interface / prototype, you're defining a noun in your domain-specific implementation.
To me, the usage of the term itself ("DSL") does not make much sense. Using a combination of public or custom libraries and APIs is in itself a DSL and the combination makes it unique, per application. And when programming, you're extending that language all the time. That's what you're doing with every function, class or interface you add. That's what programming is - specifying to the computer how to do computations by building a language made of nouns and verbs that it can understand and then forming sentences out of those nouns and verbs. And these definitions transcend the actual lines of code, as when you're communicating to your colleagues, in speech or in writing, like in emails or specs, we do need precisely defined words to refer to concepts within your app.
The term DSL in the context of software-development is basically a pleonasm. And discussions on DSLs are actually stupid, as people argue about a non-issue.
The real discussion should be - in what contexts do you really need re-usability and/or composability and/or succinctness? Not always, I'll grant you that.
And here, I think we can learn from mathematics or physics, spanning domains so complex as to be intractable without defining mini-languages to express things efficiently. Speaking of Monads, many people described them in terms of mathematics, like with the infamous "a monad is a monoid in the category of endofunctors". You could say monads are just a design pattern, with some simple properties to grasp and some examples and normal people wouldn't need more to understand their usage, however understanding their mathematical underpinnings, that use big and unfamiliar words that scare us, allows one to grok the notion and build on top of it bigger and better abstractions. And abstractions help us to tackle even more complex problems. Yes, even in the real world.
> Whenever you're creating a function, you're defining a
> verb in your domain-specific implementation.
Yes. And by virtue of it being a function, i.e. a first-class operator in the language I'm working in, I also know _prima facie_ the semantics, cost, and implication of that verb.
This is critical and necessary knowledge. And it's precisely the knowledge that I _don't_ get (immediately) when I use a DSL. I have to know both the semantics of the verb within the context of the DSL, and the semantics of the DSL (as a whole!) in the context of my programming language.
That additional step is, more often than not, a significant burden. I'm disinclined to bear it, no matter how facially elegant it may make the solution.
> The real discussion should be - in what contexts do you
> really need re-usability and/or composability and/or
> succinctness? Not always, I'll grant you that.
Ah, but internal DSLs do use the same constructs and semantics that the language provides, unless you're talking about macros.
And we aren't talking about macros here, but about monads (a quite reusable design pattern), possibly in combination with the do-notation from Haskell, or for-comprehensions from Scala, or LINQ from .NET ... basically a simple and standardized syntactic sugar to make operations on monads more pleasant to read, but not really required.
A monad is basically a container with certain functions that can operate on it that have certain properties. That's not a DSL. Those are just function calls on a freaking container implementing a design pattern.
They're lovely to write, and elegant in a closed system, but in The Real World(tm) where we all live and work, we don't generally have the luxury of writing software to solve those classes of problems.