
Domain-Specific Languages vs. Notation - exupero
http://spin.atomicobject.com/2015/05/19/domain-specific-vs-notation/
======
crdoconnor
I find DSLs ( _especially_ turing complete DSLs) which try to emulate written
English to be grating.

This was what COBOL attempted to do, and far from having the intended effect
(allowing non-specialists to program), it actually just created new breeds of
specialists who could understand this new and really rather bad programming
language.

Capybara's isn't that bad, although trying to make a more human readable DSL
that uses XPath is a little ironic. The robot framework is probably the
language that does this that I hate the most because it's turing complete and,
IMO, actually less readable and usable than the language it was built upon.

~~~
ccalvert
COBOL was created 1959. Singly it out as an example of a DSL in this context
is a bit like arguing against cars by pointing out the faults of the Model T
Ford compared with a Tesla. It just isn't a very good or fair place to start
the argument.

I'm not arguing, of course, that we should go back to using COBOL. But lets
get the facts straight. By 1997, according to Wikipedia, "there were a total
of 200 billion lines of COBOL in existence, which ran 80% of all business
programs." It was, in other words, a massive success. How does that prove that
DSL's are no good?

It's a little hard to wrap our heads around the state of computing in 1959.
I'll just say that at the time it was a difficult even for academics at big
universities to get good access to computers. Most of the readers of this site
weren't even born yet. Yes, of course, COBOL's out of date. If it weren't that
would be a miracle.

DSL's may or may not be a good thing, but bringing up COBOL is perhaps not the
most effective way to reach a valid judgment on the subject.

~~~
jerf
COBOL was a massive success. It is deployed everywhere and runs everything.

COBOL was a massive failure. It had a goal of producing a language that
business people could use directly with no intervening programmers by being
"English-like" and friendly. This totally and utterly failed.

These things are not contradictions.

Further, _everything_ I know that was designed to be "English-like", cut out
the programmers, and let the business people program directly has been a total
and utter failure, _on that metric_. By contrast, there's a number of things
that business people directly use all the time without programmers, like Excel
macros, that aren't trying to attain friendliness through "being like
English". Maybe there's something out there that has done both, but I've not
heard of it.

I don't criticize COBOL for trying. It was an experiment that had to be tried,
and I have strong opinions about it precisely because COBOL and others provide
me the data points with which to have an opinion. But its popularity _among
programmers_ doesn't establish that it was successful in letting business
people code directly.

~~~
dragonwriter
> Further, everything I know that was designed to be "English-like", cut out
> the programmers, and let the business people program directly has been a
> total and utter failure, on that metric.

I would agree, though in many cases (SQL particularly is a strong example)
that's often more a failure of the organizations using the technology than the
technology itself.

It doesn't matter if you have business-side analysts that can use SQL if you
by policy don't let anyone outside of the IT side of an organization have
access and tools that allow the user to use SQL directly against the database.

The IT-as-high-priesthood cult in organizations is strong, and resistant to
any application of technology that challenges the priesthood. And this is,
IME, especially true in organizations where the IT organization (and
particularly its leadership) isn't particularly technically strong to start
with.

------
tel
I strongly approve of this message. I think the reason why Ruby has such
terrible DSLs is not due to its technological strengths or weaknesses but
instead because the community promotes the idea that a good DSL is super human
readable.

I'm not one to denigrate syntax or readability, but I think it must without
any question be prioritized _below_ good semantics. The "Zen of Python" has
some (but hardly all) this hammered out well

    
    
        * Explicit is better than implicit.
        * Simple is better than complex.
        * Special cases aren't special enough to break the rules.
        * In the face of ambiguity, refuse the temptation to guess.
    

Working in DSLs—and really there's no reason to think that we're not always
working in DSLs nearer or further from our actual domain—should simplify
_concepts_ first and syntax later.

~~~
RangerScience
> I'm not one to denigrate syntax or readability, but I think it must without
> any question be prioritized below good semantics

I strongly disagree. You get what you wish for / focus on - if you wish for
good semantics, you will get good semantics, but not necessarily readability.
If you wish for readability, you may not get good semantics - but the point of
having good semantics is readability, so...

This is the issue I have with the Zen of Python (versus the Principle of
Ruby). The Zen of Python attempts to list out the things you should do so that
you get Developer Happiness. Ruby just says "Go get developer happiness".

And so you get Python code that follows all the Zen of Python but fails to
make you happy, and you have Ruby code that breaks all the rules of the Zen of
Python, but does make you happy.

Given that what makes a good programmer happy amount to ease of use,
effectiveness, reliability and speed (in an order dependent on circumstance),
or more succinctly - if I am happy when I am effective... I'd rather be happy
than right.

~~~
tel
Mostly we're just expressing a difference of opinion, but one thing that I'd
like to contest is that the goal of the Zen of Python is to produce developer
happiness. In particular, I'll state that my cherry picking from that screed
is not aimed at developer happiness.

I personally think developer happiness is a very poor place to put your stock.
I believe much more that the goal should be one of craft and if the mechanism
is painful and difficult then this is merely the cost to play.

I think there's a lot of room for places where developers are made to be
happy. Education is a HUGE target here and I'm happy to note that a lot of
Ruby's early successes, I believe, were centered there. I believe happiness,
convenience, and a little bit of absurdity are fine traits.

But when I want to get work done, when I want to make things to share and to
last and to communicate my goals and intentions, then I want to suffer
whatever is necessary to do that well. So, in my opinion, developer happiness
be damned.

Then, again, it's also my perspective that developer happiness can perhaps be
maximized in this way as well. But if you take it as your solitary goal then I
don't think you're well equipped to make the whole journey.

------
dozzie
Author hasn't stated that what Ruby calls "DSL" is merely an API, not a
language. It's still valid Ruby, so by definition it's not a domain-specific
_language_.

~~~
hyperpape
It's pretty common to call a DSL "internal" when it works within the syntax of
an existing language, as opposed to an external DSL that is a separate
language. I'm not sure saying "but it's not really a language" helps us stay
clear on what's going on.

~~~
dozzie
Yes, it's pretty common to call it that. Mainly because it's pretty common for
programmers to be undereducated, so they misapply terms or unnecessarily
reinvent terminology.

Let's call the "smart interface with domain-specific verbs" a domain-specific
interface, it would be just fine. But calling it a _language_ is simply a term
abuse.

~~~
kenbellows
> it's pretty common for programmers to be undereducated...

[citation needed]

~~~
moron4hire
Not that I think it's an adequate citation, but there is an essay from
Dijkstra on the front page of HN right now where he says essentially the same
thing:
[https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD648.html)

------
DanielBMarkham
Perhaps I missed something, but is the author conflating the idea of using
english language from the domain as function/variable names with having a real
DSL?

DSLs are parsed/compiled/interpreted. If you're doing one of those things, and
the words represent concepts in the problem domain? You've got a DSL.
Otherwise you just have a well-named API.

But I may have missed it. I failed to see the point of this article -- perhaps
I am in violent agreement and do not realize it!

~~~
th3iedkid
>>Take a look at Capybara’s DSL. Capybara is a library for interacting with a
browser from code. It works hard to make the code read like English.

I think this line lead to believe so , but reading on...

>>But emulating the English language—complete with nouns, verbs, and
prepositions—is simply the language of the domain, not a truly domain-specific
language

And this one too :

>>A key difference between using the language of the domain and a domain-
specific language is that a true DSL—notation—is not only suited for
expressing problems and solutions, but also for getting from one to the other.

Basically he wants to state about notational convenience,degree of
expressiveness and ease of notational operations with the math example.This
ease of operation leads to better formal verification and better spec
translation.He then goes onto talk about notations used in Music etc..

------
ragebol
Having an API that matches a natural language is not a DSL per se, either
internal or external. It may help creating an internal DSL though. An external
DSL is parsed and compiled or interpreted into or by another general
programming language, usually. An internal DSL, the way I see it, is a
'language' that uses the language it is embedded in in such a way that it
makes it easy to read and understand by those initiated with the DSL (ie. the
domain experts). And may not look all that much like the embedding language.

The benefit of a DSL can be that you can do verification etc on the semantics
of the domain. An API with handy naming may not be able to do this trick.

Note that the readers and writers of a DSL may be very different audiences:
the readers can be domain experts who give feedback while the writers may be
software engineers.

------
toothbrush
_" Programming languages often advertise themselves as being well-suited for
writing domain-specific languages (DSLs), [...]. Ruby is probably the most
popular such language, but many others—such as Scala, CoffeeScript, and
Io..."_

I got a bit cynical when the list stopped there. But maybe these languages are
indeed as powerful and expressive as the Lisp of the day?

------
ExpiredLink
Several years ago there was a big DSL hype which - more or less - faded away.
It is very hard to construct a DSL and once established it is cast in stone.
In contrast, APIs are much simpler and more flexible.

~~~
th3iedkid
I doubt that. There are fields in embeded systems , manufacturing ,
verification/proof systems where DSLs are very much in use . They will be in
use for long time too.

Take a look at this person's CV [0] and his "Domains and Customers" section
[Page 20], you will see where all DSLs are applied.

[0]:[http://voelter.de/data/cv/cv.pdf](http://voelter.de/data/cv/cv.pdf)

~~~
ExpiredLink
How many of these DSLs are still in use as planned?

~~~
taeric
Not sure I understand the relevance. Especially when it is contrasted with API
level thinking, which would hit this question equally oddly.

------
ctdavies
lisp lisp lisp lisp lisp lisp

~~~
M8
You forgot the brackets: ((((())))).

