4

Today, an interesting discussion with a colleague. We're going to create a wrapper for WCF's channels, that will handle the Close(), Abort() and Dispose() correctly. This wrapper is to be used instead.

A coworker argued that this was like creating a domain specific language. He opposed the idea, saying it would impose a certain way of working on every software developer that he considered intrinsically wrong. He'd rather overload the 'using' keyword. (Now, AFAIK, this is not possible in C#)

So, does it? Does creating a set of classes and using them strictly instead of classes from other libraries (i.e. forbidding use of Channel) make a DSL?

When does 'code' become a DSL? I always understood a DSL as a new language with its own grammar, keywords, parser, tokenizer, etc.. Is the term becoming more vague with use?

class ChannelWrapper : IDisposable
{
    void Dispose(bool disposing)
    {
        ...
        try {
            channel.Close();
        }
        catch (CommunicationException) {
            channel.Abort();
        }
        catch (TimeoutException) {
            channel.Abort();
        }
    }
}
Improve this question
1
  • When it is specific to a particular application domain. Examples of domains: accounting, matrix mathematics. Commented Jun 30, 2016 at 13:49

2 Answers 2

Reset to default
4

This isn't a DSL, it's simply an API.

An API provides a set of building blocks for use within the language the application programmer is using. If it's a set of building blocks for use within another programming language that another programmer will be using, it's a set of bindings.

A domain-specific language is a newly invented language, usually one that is simpler than a programming language, often one in which a non-programmer can express useful content. HTML is almost too complex to be called a DSL. The configuration file formats of many small tools are better examples of domain-specific languages.

Improve this answer
7

You are touching upon the difference between an External DSL (a separate language with its own syntax and semantics) and an Internal DSL (a way to creatively design an API in such a way that using it feels like a different language, even though it is actually still bound by the syntax and semantics of the "host" language).

You will also sometimes hear the term Embedded DSL for the latter (and more confusingly see it abbreviated as EDSL) and just DSL for the former. This is basically a cultural difference, e.g. the Ruby community uses the Internal DSL / External DSL terminology, whereas the Haskell community uses the EDSL / DSL terminology. However, I find the term Embedded DSL ambiguous, because it sounds more like a language embedded in a different language, e.g. like regexps are "embedded" into Perl or LINQ is embedded into C♯.

As to your question where the border is … I believe there isn't one. Every language is an API, and every API is a language. The "better" an API is, the more "language-y" it feels. API design is language design.

This is especially true for OO: if you go back to Alan Kay's vision of OO, it is highly inspired by what would later become the ARPAnet and then the Internet. Computers (objects) which are separated (encapsulated) from each other and have their own private memory (instance variables) communicate with each other by sending messages (calling virtual methods). In fact, he even used the term "messaging" for what we nowadays call "virtual method call", and the API of an object is still called its "protocol", usually informally, but in Objective-C for example even as a language feature.

So, the networking metaphor and terminology is deeply ingrained in OO thinking. In very early implementations of Smalltalk, there weren't even methods (or objects). There were message streams flowing through the system, and these streams were parsed, interpreted, re-written and re-routed. Then, a couple of patterns emerged: 1) there would be clusters of closely related "stuff" in the "sea of messages", these later became "objects", and 2) there was a peculiar pattern where the beginning of a message denoted some enumerated set of actions, and the rest of the message parameterized that action, these later became "methods" and "messages".

Note, how I talked about parsing and interpreting messages above? Doesn't that sound like a language implementation? We can indeed interpret each object in an OO system as an interpreter for its own language!

Note, however, that your API really doesn't feel very "language-y" at all. While I said that every API is a language (and vice-versa), there's still the question as to whether it will commonly be recognized as such. If you think about Rake, Gemspecs, RSpec, or the Rails Routing API in Ruby, for example, when people look at them, they'll intuitively see a language, and only later realize that it's actually "just Ruby code". OTOH, when I look at your code, I see C♯, not something different, so it just doesn't "feel" like a language.

So, tl;dr

  1. what your colleague means is an Internal DSL, what you mean is an External DSL
  2. there is no clear border between API and language, good APIs are designed like languages
  3. languages are deeply ingrained in the fabric of OO, objects are essentially interpreters
Improve this answer
6
  • Smalltalk style is failed OO. Every time message passing ideas get introduced at the programming language level, it ends up going nowhere, rejected in the marketplace of ideas in favor of Simula-style OO. Even Objective-C would have (rightfully!) languished in obscurity forever if Apple hadn't shoved it down the iOS development community's throats. And even today, it's all but nonexistent outside of the Apple ecosystem, and Apple is trying to backpedal as hard as they can and replace it with Swift now that Steve Jobs (throat-stuffer-downer-in-chief) is gone, because it's a very bad idea. Commented Jun 30, 2016 at 14:17
  • Objective-C with types (better known as "Java") seems to be doing at least somewhat okay. ECMAScript is also not too shabby, in the number of users, number of deployed language processors, and number of developers. Python and Ruby don't seem to be failing either. Erlang/OTP is pretty much exactly what Alan Kay envisioned, maybe even more so than Smalltalk itself, which he considered going into a wrong direction and wanted to start over. The only Simula-style OO language which is not an obscure niche language is C++, which seems to enjoy its popularity largely due to its non-OO features. Commented Jun 30, 2016 at 17:44
  • The Sun team may have borrowed the concept of Interfaces from Obj-C, but it's still very much Simula-style OO: static typing, single-dispatch with binding as early as possible, and no language-level concept of "messages" or "message_missing". Ruby was briefly popular but has been in decline for years now, Erlang never was anything more than a niche language in the first place, and Python is a horse of a different color entirely. Commented Jun 30, 2016 at 17:57
  • 1
    As for JavaScript, it's widely considered to be a horrible ball of WTFs that people use by necessity, not by choice, because it rode HTML's coattails to prominence. One of the biggest areas of language research and development over the last several years has been in statically-typed languages that cross-compile to JavaScript, because everyone hates having to actually use JS itself. And again, JavaScript has no language-level concept of "messages" or "message_missing", so why do you define it as Smalltalk-style OO in the first place? Commented Jun 30, 2016 at 17:57
  • "JavaScript has no language-level concept of "messages" or "message_missing", so why do you define it as Smalltalk-style OO in the first place?" – Because Alan Kay and Dan Ingalls do, and I do tend to trust that those two know a little bit about Smalltalk. JavaScript is essentially Scheme with maps instead of lists as the fundamental ubiquitous data structure plus an OO system inspired by NewtonScript, Act-1, and Self, with syntax, the latter of which implies the loss of homoiconicity and macros. Commented Aug 12, 2019 at 13:43

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.