Comment by BiteCode_dev
6 years ago
While there are a few DSL that won the war, like CSS or SQL, it is very unlikely that your DSL will prove worth it. 99% of the time, what you need is a good high level library/API to deal with the problem with your current technology.
Here is why:
First, you need to design it properly, and most devs are not good language designers. The chances your DSL is going to be good is very low.
Second, unless you are incredibly talented and have little constraints, you will not even remotely provide 1% of the tooling existing languages already have for free. I've seen so many DSL without basic syntax highlighting nor linter it's not even funny, but you need much more to be productive with a new language. Even if you are using macros and claim to be able to use the tooling for the main language you come from, stop a second and think about the last time you had fun debugging a complicated macro magic.
Third you need to test it and document it. Do you even do it properly for your regular code? It takes time and resources. A lot of it. Which could be better spend on the project, or on the library/API you should be writing about.
Fourth, what about training? Because you can hire somebody for language X. But for your DSL, you'll need to train them.
Then of course, you plan to support it for as long as it's used. Right? Right?
Good time to urge people to comment on the article, not on a term you saw in the headline.
> 99% of the time, what you need is a good high level library/API to deal with the problem with your current technology.
TFA exactly describes a solution based on current technology available in Lua.
> First, you need to design it properly, and most devs are not good language designers.
A lot of languages are small and obvious, like the one described in TFA.
> Second, unless you are incredibly talented and have little constraints, you will not even remotely provide 1% of the tooling existing languages already have for free. I've seen so many DSL without basic syntax highlighting nor linter it's not even funny, but you need much more to be productive with a new language. Even if you are using macros and claim to be able to use the tooling for the main language you come from, stop a second and think about the last time you had fun debugging a complicated macro magic.
TFA addresses this not by macros or an entirely custom language, but by using Lua grammar for it entirely.
> Third you need to test it and document it. Do you even do it properly for your regular code? It takes time and resources. A lot of it. Which could be better spend on the project, or on the library/API you should be writing about.
"You need to test your code" is not a problem unique to DSLs
> Fourth, what about training? Because you can hire somebody for language X. But for your DSL, you'll need to train them.
I've skimmed the article for a total of maybe 45 seconds and I know the ins and outs of the DSL it describes. "You need to understand your code to work with it" is again not a DSL specific problem.
> Then of course, you plan to support it for as long as it's used. Right? Right?
Another code-in-general remark.
Completely agree with your replies here, but there are internal DSL's that stray so far away from the regular syntax/semantics that your skills in the host language don't apply when writing in the DSL. (Scala SBT I'm looking at you)
I think that the syntax of a DSL should make a problem easier to work with, like CLISP's format macro. Yeah it's kind of crazy having to learn a whole mini-language just to use a certain library, but my experience with CLISP assures me that this madness is worth it. I prefer to manipulate strings using format rather than try to do it in a real LISP.
2 replies →
IMO, your comments belie the entire experience of library developers in "DSL-friendly" languages; those with a system of language features that compose well to create what humans perceive as "sub-languages". Ruby and Haskell come to mind immediately, each with a very different set of DSL-enabling attributes.
"The chances your DSL is going to be good is very low." – Nonsense? Yes, API design can be hard. But DSL design at the scale of embedded, ergonomic DSLs is most commonly exactly the same scale as API design. Moreover, there are plentiful examples to draw from these days, especially around builder-type APIs as illustrated in the article. We have quite a suite of well-established patterns to draw from, and they're just not that hard to apply well.
Notably, "language design" doesn't come into it. Almost all proper "language design" decisions for these kind of DSLs are made by the host language – that's why embedded DSLs are so appealing in the first place. There are exceptions when the "language" is really a language (e.g. embedding a Prolog in Haskell or whatever), but most of the DSL examples in the wild end up simply being nice ways to construct rich data structures for consumption/interpretation by some utility library.
SQL is not a “DSL”.
It’s a “Declarative Programming” language and arguably the most popular one.
https://en.m.wikipedia.org/wiki/Declarative_programming
Declarative, functional, imperative, stack-based, array-based, etc is a description of the language itself, or rather the primary computational abstraction; DSL is a description of its usecase and purpose. The opposite is a general-purpose language. The two concepts are orthogonal.
For example, your Wikipedia page defines regexes as also a declarative language, and yet it is also the quintessential DSL.
And in terms of it's domain... SQL has a very a restricted domain it was meant for, and is generally used for. You could argue its domain has expanded slightly with things like LINQ, but it's clearly wrong to describe it as an alternative to say python, or c#, as a language, in purpose or usage.
a language being a DPL doesn't preclude it from being a DSL
I’m not certain that is true.
With a DPL, you describe what output you want without describing how to produce the output.
With a DSL, you have to describe how to produce the output.
1 reply →