10 ms·
> 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
by redbad 13y ago
> 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.
This is a disingenuous framing of the problem.
- bad_user 13y agoAh, 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.
- redbad 13y agoI guess what you call an "internal DSL" I call an API.