3 ms·
>Some may say that Rails is a poor example of a DSL. While that may be, it raises the question: are there better examples out there? You are understanding DSL
by flavio81 9y ago
>Some may say that Rails is a poor example of a DSL. While that may be, it raises the question: are there better examples out there?
You are understanding DSL as "ok, let's import this library that defines a DSL".
In the Lisp world, one favored approach is to express the problem in the most natural way possible (i.e. like if describing the problem in english, or in any case, in your dsl language that best suits the problem.) Then, you use Lisp macros and implement this DSL. This has the side effect of making your program work, and thus, your problem to be solved. And, thus, the problem itself is specified in a high-level DSL, where it's more easy to understand and modify.
Note, also, that on a Lisp-family language, creating a DSL is very easy, since metaprogramming is very very similar to regular programming. (In Lisp, metaprogramming is not some advanced topic; quite the opposite, is taught to beginners as well.)
So, for example, if i want to create myself a library that outputs HTML, i define my DSL, which can be something like:
(with-html-output
(:html
(:head
(:title my-page-title))))
or perhaps
(do-html-output
(do-html-head :title my-page-title
:includes js-include-list))
Then, later, i'll create the functions and macros that make my language work. This solves my problem.
As you can see, anybody who knows about the problem domain of "let's do HTML output", will easily understand this DSL. In any case, if you are importing a library that defines a DSL, if the library is good, then by definition the DSL expresses the problem in the clearest way possible, and thus, it should be an easy library to use.
Perhaps it has something to do with the syntax? In Lisp, the syntax is very uniform (s-expressions) while Ruby has a far greater variety of symbols and constructs.
- cujic9 9y ago> Note, also, that on a Lisp-family language, creating a DSL is very easy. I'd argue that this is a bug, not a feature. Yes, DSLs can make for elegant code, but it comes at a high cost in the form of a hidden dependency: the state of the DSL author's brain. In order for us to share a codebase with a DSL, I now need to understand your unique, high-level view of the problem, and be able to speak it fluently. And if your view of the problem is incorrect, I need to be able to hold two conflicting viewpoints in my head and find a way to resolve them. (Something that humans find quite difficult.)
- argv_empty 9y agoA quick `s/DSL/library/g` and the result is just as true and just as much of an issue.
- cujic9 9y agoI disagree. A library works within the style and bounds of the base language. A DSL intends to re-define the base language and invent new keywords and a unique control flow.
- heavenlyblue 9y agoYes, and that is exactly what programmers do: they create hierarchies: we had started with assembly and now we've got easily-scalable-to-multiple-computers cloud platforms which also need to be programmed. God bless generations of programmers doing the same thing over and over again. It's funny how you can't even agree that there _might_ be languages that do allow you to create your own DSLs within the style of those languages; there _isn't_ a base language.
- JohnBooty 9y agoI don't agree at all. On a small project that utilizes a single DSL or a single library, sure, the difference is negligible. On a large project with many DSLs and/or libraries (ie Rails) it's not easy to tell if a given thing is part of Ruby or part of the many-headed beast that is Rails. (or which of those heads provided it...)