Domain-Specific Languages vs. Notation

Re:Domain-Specific Languages vs. Notation by devonkim on Tuesday May 19, 2015 @01:12PM (#9571592)

The need to perform a platform-independent parse + compile is a large part of my personal concept of a DSL. This is not the same thing as writing shims and grafting new methods onto objects to mutate aspects of the language you're writing in already while tying yourself to, for example, variable scoping rules that is inherited from an implementor language. In fact, I've seen some people describe what amounts to a "Fluent API" as a DSL. Fluent APIs are great and help with usability of an API considerably, but I don't think of jQuery or Scalding as DSLs, just libraries that meet all the rules of their implementation languages. Perhaps some people simply don't care and just think of a DSL as a subset of a language regardless of implementation.

If I want to be a bit more specific, I think a DSL needs to be independent in syntax and semantics from any implementation environment or platform and that by leveraging the compiler of your implementation language that it limits the "language" aspect of the DSL. I believe most people are concerned about the "DS" aspect and in this respect that reduces a DSL to being just a higher-level API - an API is not necessarily Turing complete, after all, and while some APIs require some parsing to use, they are still.

An embedded language like how Lua is used oftentimes is not a DSL to me because it is general purpose and is perfectly fine to implement another DSL - a DSL to me should also imply that you can't use it to implement another arbitrary DSL. This will blur as what used to be DSLs add features that make them Turing complete (lots of crazy things possible with SQL and CSS these days).

I don't like to be a terminology Nazi or something, but I have no real rational explanation for why "DSL" in practice rubs me funny.

[ Parent | on HN ]

Re:Domain-Specific Languages vs. Notation by tel on Tuesday May 19, 2015 @04:35PM (#9572958)

Huh, yeah. I don't really enjoy semantic arguments, either, but I think you've got a lot of great points.

There is something really genuinely different about a "DSL" which has reached the status of being totally externalized. On one hand you're now forced to more completely define the semantics/syntax from scratch (you can't bootstrap, though I think to some degree that 'definition by implementation' here is a big fallacy) but then on the other you're also facing a much greater task if your primary end goal is to just better focus on the domain.

In my opinion, DSLs are just languages with an intent to hit a target domain. External DSLs, as I call what you call DSLs at large, are one mechanism for doing that. Internal DSLs, which are not really distinct from APIs + their conventions, have the interesting property, however, of arising in layers. This aids composition and speed to develop.

But they absolutely suffer from being compromised on semantics and syntax due to their embedding. And before a Lisper comes by and talks about macros, I think the tradeoff is fundamental. The more you bear on the "underlying" language in your DSL the more you must compromise.

Genuinely, a very high-value DSL ought to be externalized, I feel.

[ Parent | on HN ]