
Problems with DSLs for non-programmers - gentleterror
https://artur-martsinkovskyi.github.io//2019/dsls-are-hoax/
======
ghc
The argument here boils down to: I haven't seen it work in places where I've
been employed so it must not work.

Reality check: I've worked on multiple large research teams that successfully
developed DSLs still in use by domain experts -- military sigint in one case,
doctors in another case, industrial engineers in another.

We developed these languages for specific applications where the domain
experts needed to program extremely complex systems to perform tasks in much
shorter timeframes than would be possible if programmers needed to get
involved.

Why did these DSLs succeed? Funding, manpower, and experienced project
managers who delivered constant access to domain experts.

Delivering a successful DSL targeted at narrow domains with non-programmer
users is much more resource-intensive than normal software--it's more on the
complexity level of a compiler or small OS--but that doesn't mean it can't or
shouldn't be done. Plenty of systems couldn't be automated otherwise.

~~~
zwkrt
Anyone who thinks DSLs for the general public can't work has never used Excel.
The real trick is creating a domain model that "clicks" in the heads of your
users.

~~~
snarfy
The counterpoint would be Visual Basic. It was meant for non-
engineers/managers to be able to write programs, but that never really
happened. It was always easier for a manager to write an email 'I need an app
that does X' than to write the app themselves.

~~~
ethbro
There's one key I've seen to DSLs that _really_ work: scope your DSL with
iron.

You should be able to clearly say 'This DSL can do X. It cannot do Y.'

(Then, if Y sometimes needs to get done, provide an escape hatch integration
point to C et al.: but don't _ever_ expand your DSL beyond the domain!)

~~~
zwkrt
You can see this with how VB became much more monstrous and complex as soon as
they tried to shoehorn in a multi-table paradigm.

~~~
ethbro
I think later-legacy-VB (eg 6) suffers harshly from failing to properly
separate primatives.

Imho (open to disagreement), one should think _incredibly_ hard before adding
primatives to a DSL. Because what that's essentially saying is "My abstraction
was incomplete over the target domain, and now I'm going to hack something
in." And now you have a "domain + some other stuff" language, which starts to
look like a general purpose language.

SQL vs VB is an excellent example of focus.

(Although I do think VB.net added sanity back to the mix, by saying more
clearly "These are VB things" and "These are .net things", and if you want to
do the latter in the former, just make a library call)

------
np_tedious
> The last time I had a business analyst that wanted to write SQL, he tripped
> over one join and asked me to do the job. SQL is used widely, but it does
> not work that well for people who are not programmers. HTML and XML were
> also originally intended for non-programmers - where are they now? They are
> used by amateurs or enthusiasts sometimes, but most of the time programmers
> do the job.

At both is my last two jobs (SaaS and e-commerce startups), the marketing
teams had several individuals proficient in SQL. Hell, in some ways (complex
read only queries) they were probably better than me simply because they did
it more often. There existed BI tools and dashboards for many things, but the
savvier and more curious individuals always wanted to dig further out
experiment with queries before getting them formalized like that.

Members of the email team knew a fair bit of HTML and CSS too. And email is
not what I'd consider one an easy HTML medium.

Due to these examples, I can't agree with the article at all. Must be a
selection bias experienced by author.

~~~
ramraj07
My experience has been there are definitely people who become very proficient
with sql while not knowing any other programming but they generally hit a
ceiling. For most people they can do joins and some basic nesting but they
start getting out of their elements if you mention window functions, ctes etc

~~~
np_tedious
I'm just one data point, but this group I'm thinking of uses a LOT of CTEs.
Perhaps too many - they seem to always have a bunch in their saved queries,
personal notepad, etc and would probably benefit from being allowed to create
views so that they'd have smaller queries with fewer WITH clauses.

Seeing things like the above or spreadsheet power users really makes me think
that "everyone should learn to code" education / literacy initiatives could be
a very good idea if done properly.

------
vinceguidry
I've met many non-programmers who are quite comfortable with SQL. There are
many smallish scripting languages that should qualify as DSLs that allow lay
access to domains that mystify normal people. Excel comes to mind. Mathematica
used to be one of these before it became a real general-purpose programming
language, if a somewhat limited one.

The author appears to be projecting their personal convictions onto everyone
else.

~~~
GordonS
I agree that DSLs can work for non-devs, and Excel is a good example of this.

SQL though, I'm less convinced about - while I've known business people to use
it for _basic_ queries, many _devs_ struggle with anything more complex.

~~~
liability
That many professional developers are worse at SQL than professional non-
developers is an indictment of those developers, not SQL.

------
clarkevans
I think it's better to call the users of such high-level DSLs, _accidental
programmers_. It's not like they are not programmers, its just that they don't
see software development as their vocation or profession. Yes, it's important
to have languages that target them (e.g. Excel, Latex, SQL). Design of such
DSLs is important and hard work. We need more professional activity making
DSLs usable, consistent, and extensible.

~~~
azhenley
The research community calls them end-user programmers:
[https://en.wikipedia.org/wiki/End-
user_development](https://en.wikipedia.org/wiki/End-user_development)

------
nn3
Reminds me of a speech rms gave about programmable editors. Money quote:

" Multics Emacs proved to be a great success — programming new editing
commands was so convenient that even the secretaries in his office started
learning how to use it. They used a manual someone had written which showed
how to extend Emacs, but didn't say it was a programming. So the secretaries,
who believed they couldn't do programming, weren't scared off. They read the
manual, discovered they could do useful things and they learned to program."

[https://www.gnu.org/gnu/rms-lisp.en.html](https://www.gnu.org/gnu/rms-
lisp.en.html)

~~~
rgoulter
Related: Steve Yegge discussed use of Emacs for a customer-email processing
application at Amazon:

[https://sites.google.com/site/steveyegge2/tour-de-
babel](https://sites.google.com/site/steveyegge2/tour-de-babel) (2004)

""" _Shel wrote Mailman in C, and Customer Service wrapped it in Lisp. Emacs-
Lisp. You don 't know what Mailman is. Not unless you're a longtime Amazon
employee, probably non-technical, and you've had to [directly talk to
customers]._ [....]

 _Mailman was the Customer Service customer-email processing application for
... four, five years? A long time, anyway. It was written in Emacs. Everyone
loved it._

 _People still love it. To this very day, I still have to listen to long
stories from our non-technical folks about how much they miss Mailman. I 'm
not shitting you. Last Christmas I was at an Amazon party, some party I have
no idea how I got invited to, filled with business people, all of them much
prettier and more charming than me and the folks I work with here in the
Furnace, the Boiler Room of Amazon. Four young women found out I was in
Customer Service, cornered me, and talked for fifteen minutes about how much
they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent
years developing) still just wasn't doing it for them._

 _It was truly surreal. I think they may have spiked the eggnog._

 _Shel 's a genius. Emacs is a genius. Even non-technical people love Emacs.
I'm typing in Emacs right now. I'd never voluntarily type anywhere else. It's
more than just a productivity boost from having great typing shortcuts and
text-editing features found nowhere else on the planet. I type 130 to 140 WPM,
error-free, in Emacs, when I'm doing free-form text. I've timed it, with a
typing-test Emacs application I wrote._ """

~~~
rightbyte
It's funny how some Smug Emacs Lisp-guy are confronted with why the Emacs with
extension mail client was deprecated. It must have been some life changing
experience chatting with non Smug Emacs Lisp-guys people actually wanting to
use Emacs.

I can quite understand why you would want Emacs for Customer support emailing,
with the ability to semi-automate tasks and extend extensions. If it's your
full time job to write quite similar emails, it's probably worth the effort.

------
tyleo
To add another counterexample into the mix, I’ve met many artists and
designers who are proficient with Unreal Engine’s Blueprint with no C++
experience. Some have even shipped games made entirely in blueprint with no
traditional code.

~~~
matthewwiese
To add to that: Clickteam's Multimedia Fusion 2 Developer, which I learned to
make games with back in elementary school. It is strictly (although not
exclusively) "no code." Hell, one of my favorite indie games of all time,
Knytt Stories, was made in it.[1]

[1]:
[https://web.archive.org/web/20160821143752/http://nifflas.ni...](https://web.archive.org/web/20160821143752/http://nifflas.ni2.se/?page=Knytt+Stories)

------
bhougland
The SQL example is rediculous. I wasn't a programmer when I decided to use
SQL, but learned it to be better at my job. After I learned it everyone else
thought what I could acheive was magic. I only had read access so I had to be
able to perform advanced subqueries, windowing statements , etc. After a
couple of years my skills could embarrass most programmers in the company
(minus the Oracle dbas). This is because the programmers wanted to write SQL
in a proceedural way using plsql and were never very comfortable with set
theory.

This knowledge expanded my power within a mutibillion dollar company and I
went from temp analyst to director of supply chain business system and
informatics within 3.5 years. I also decided to learn python due to the data
libraries, and my power grew more as I automated most routine processes in my
department. I required every employee of mine to learn SQL and gave them 3 hrs
every Friday for self study. Our supply chain went from being ranked 340 in
the country ( for our industry) to the within the top 10.

Don't tell me non programmers can't learn SQL. Also these DSL get people like
me that should of gotten a CS degree the experience and confidence to get
deeper into programming. Now I write python and clojure. In fact, because I
have deep domain specific knowledge in supply chain I can apply my programming
in ton of different ways. I find most corporate programmers have all these
skills and either don't really know how to apply it to really help the
business, are too lazy and think of the business stakeholders as a annoyance,
or just do their job and go home.

I think it is going to be hard to bea white collar worker in the future if you
don't know how to program.

------
craigsmansion
It would have helped if the author would have given their definition of a DSL
at the start.

Embedded in a later paragraph a DSL is defined as having a syntax where "code
that must look similar to proper English of the domain."

I tripped over that because, as a schemer, it's easy to discover there's
really no fundamental difference between a "DSL" and "a program", in any
programming language.

~~~
wool_gather
Completely agree; this is a difference of degree, not kind. Quoting myself[0]:

> As soon as you have something as apparently simple as named procedures,
> you're really writing a DSL, albeit very coarsely, for your business
> problem.

[0]:[https://news.ycombinator.com/item?id=18770192](https://news.ycombinator.com/item?id=18770192)

------
ChrisSD
For most of the article the author seems to be discussing non-professional
programmers rather than non-programmers. Or perhaps using the two
interchangeably?

There is certainly a need for non-professional programmers to be able to
program (e.g. in the sciences). For non-programmers, programming a task via
GUIs have been effective, although admittedly in the worst case they can
devolve into a mess of check boxes, drop downs and spinners.

EDIT: Of course in a business you'd hire professionals for a job (or outsource
it). That's just good sense for anything your business relies on.

~~~
azhenley
I'm not sure about what the article is specifically referring to, but _end-
user programming_ refers to a spectrum of people that need to accomplish a
programming-like task without being a professional developer.

The paper "The state of the art in end-user software engineering" discusses
this spectrum from an email user to a middle school child to a scientist:
[https://dl.acm.org/citation.cfm?id=1922658](https://dl.acm.org/citation.cfm?id=1922658)

------
mamcx
Also: Not discount the power of some basic training to unlock the power of
DSLs.

I work a lot around RDBMS. Most people have almost null training about SQL,
relational model or how databases work. They learn it in the most ad-hoc,
step-by-trick-step.

Is mostly: "Hey how do that? Look! this cool trick do the work!". You see this
everywhere. Sometimes people ask you this question a lot (about excel, sql,
how use email, what? Word can do some mat too?) and so on.

Eventually, I sit a few minutes with them and explain the fundamentals. It
change the game. A lot.

------
ivanhoe
IMHO author is missing the historical perspective of DSL approach. In the time
when SQL was developed, users simply needed a much higher level of tech skills
than today. One older colleague told me once how he wrote his PhD thesis using
ed (unix line-editor), and it was more than 100 pages work. To us that seems
crazy complicated and unfriendly, editing 100s of pages line by line using
obscure single letter commands, but to them it was a huge improvement compared
to typing it on a typewriter - and they all learned how to use it. Similarly,
analyst in the days when SQL was invented had very different expectations and
ideas about what "simple to use" means. Back then you expected that you need
to type your commands as text, so developing specialized tools in form of DSLs
was a perfectly logical step. Today DSLs make less sense as we can build
spreadsheets, wizards, visual drag&drop UIs, AIs for speech commands and so
on. Users' expectations and skills are completely different now, and it's less
likely that they'll invest time into learning a new language, they want
buttons to click. That's why DSLs are now more a middle step that simplifies
life for programmers when dealing with specialized tasks - for those areas
where visual tools are too limiting, but still you need a way to abstract the
complexity - just the way the SQL does it.

~~~
detaro
I think one can argue that a "visual drag&drop UI" to build a e.g. a complex
query can also be a form of DSL.

~~~
ivanhoe
Exactly, fully agree. It's a DSL of this era.

------
faitswulff
> The last time I had a business analyst that wanted to write SQL, he tripped
> over one join and asked me to do the job.

Anecdotal counterpoint: I've met many an analyst who had some mean SQL skills.

~~~
dagw
And equally I've met many a career programmer who get confused by non-trivial
SQL

------
no_identd
The problem with DSLs consists of trace debugging, in my opinion.

First, one more counter example to add to the mix already presented here:

[https://www.scholars.northwestern.edu/en/publications/pop-
pl...](https://www.scholars.northwestern.edu/en/publications/pop-pl-a-patient-
oriented-prescription-programming-language) Florence et al. – POP-PL: A
patient-oriented prescription programming language (2015)

Citations:
[https://scholar.google.com/scholar?cites=4536900861193079588](https://scholar.google.com/scholar?cites=4536900861193079588)

The debugging issues which came to light as part of the development of POP-PL
led to the new Racket trace debugging facilities in the form of Medic and
Ripple, which I've previously commented about here, and which unfortunately
barely anyone seems to know about:

[https://news.ycombinator.com/item?id=19962087](https://news.ycombinator.com/item?id=19962087)

------
mannykannot
I think there are good counter-arguments in these comments, but I also think
DSLs should be approached with caution: creating a non-trivial DSL that is
correct in a consistent and intuitive way, which provides useful feedback on
syntax errors, and is documented well enough to be used by someone else, is a
lot of work.

------
Sharlin
Another counterexample: LaTeX, used by zillions of career mathematicians and
physicists every day.

~~~
inlined
The example given, SQL, also falls flat. There’s plenty of people who are
technical but not developers and use SQL for their daily lives. I know a
marketing manager who is better than me at SQL.

Heck, I ask a PM at work to debug some of my complex queries and he asks me
for help with sample code for a developer product.

------
nudpiedo
Can I point to a counterexample? The printing dialog which asks for a page
range at the UI on windows/Linux/Mac:

12,15,30-40

------
darkpuma
DSLs for non-programmers are battle-proven. The author dismisses SQL with an
anecdote but the simple fact of the matter is that SQL is known and used
proficiently by a massive number of non-programmers to get real work done. I
guarantee you there are numerous non-programmers that know SQL better than the
author, but he met a few guys who aren't so good at it so he thinks nobody
else is. Terrible article.

~~~
sligor
how many time did these "non-programmers" spend on learning SQL ? wouldn't
have they learned basic programming skills on languages such as python or ruby
during the same time ? The problem with DSL is the S, they are Specific, and
trap the "non-programmers" in a non-programming culture. If they want to do
something a little different than the DSL is targeted for, they are unable to.

Excel is good example, it is REAL good tool for what it is meant for, but I
seen many people doing crazy thing with excel that can be done with very basic
python in a dozen of basic statements. Why ? because they people never learned
to do other thing than excel sheets, "When you only have a hammer everything
looks like a nail".

------
edejong
Counter example: spreadsheets.

~~~
twa927
I think DSLs are about defining a 100% textual format. And spreadsheets are
GUI apps. There's a DSL for defining a cell formula but in total it's a small
part of the experience of using a spreadsheet app.

~~~
darkpuma
> _" I think DSLs are about defining a 100% textual format."_

That's an unjustified qualification. I could throw together a spreadsheet
format that is all text. The spreadsheet GUI then becomes a advanced text
editor that, when editing that particular format, exposes advanced content-
aware controls not at all unlike advanced text editors like emacs can for
s-expressions.

We can bridge the gap in other ways too, for instance the '2d' racket language
that lets you do control flow using a two-dimensional ascii art grid:
[https://docs.racket-lang.org/2d/index.html](https://docs.racket-
lang.org/2d/index.html) It's not hard to see how this concept could be
iterated on to become something quite like a spreadsheet, and with editor
support the editor/language combination would begin to look a lot like a
spreadsheet too.

~~~
teddyh
> _I could throw together a spreadsheet format that is all text._ […] _The
> spreadsheet GUI then becomes a advanced text editor that, when editing that
> particular format, exposes advanced content-aware controls not at all unlike
> advanced text editors like emacs can for s-expressions._

Emacs already has that, included in org-mode:
[https://orgmode.org/org.html#Tables](https://orgmode.org/org.html#Tables)

(Emacs also has an even more spreadsheet-like mode; ses-mode, but that saves
its data in less-than-purely-textual format. Or, at least, less textual than
org-mode.)

------
sligor
Many DSL can be replaced by python modules: it is far easier to develop and
document a well written python module than a good DSL Defining a syntax,
documenting it, doing parsing, syntax checking, generating good error
reporting on a DSL is far harder than just designing a python API.

Of course it is a programming language, but Python can absolutely be used by
non-programmers. Not as cleanly as a good programmer will do of course, but
I've seen many non-programmers learning it pretty quickly for basic usage (in
this case the basic usage is just to use your python module which act as a
"DSL")

It also has the advantages of having tons of resources online, IDE, code
coloration, etc... the random "user" of your module will in general just have
to search "how to do XYZ in python" and get plenty of answer.

~~~
vsskanth
This is actually a great idea. You get all the readability and ease of access
of a DSL with a strong language backend.

In fact, some gui-heavy software have a python interface to write some
automations or plug-ins to extend functionality beyond the GUI, mainly
targeted at advanced users.

------
mjw1007
There's a middle ground, where most of the users you hoped would write the DSL
never become comfortable enough to do so, but do become competent to read the
DSL and review proposed changes.

------
EB66
I'm surprised no one is talking about React JSX. I'd be very interested to
hear the authors opinion on it.

Unlike the author's examples, JSX isn't intended to be used by business
people, but I think JSX presents some of the same problems but instead with
regard to web designers. JSX is a DSL that was intended to help simplify and
streamline the process of building a web app, but the leakiness of JSX as an
abstraction prevents anyone less than a full front-end engineer from working
effectively with React.

~~~
gentleterror
My point was about the tools that let people do the job they'd ask to do
programmers otherwise, but it is also a nice touch. Although, I think it is
not only about JSX, virtually any modern framework markup part is not easily
readable by non-developer. With complexity of the clients and trends we have
now it is not fixable and won't be for a long time.

------
andybak
How do we make automating the work of a computer more accessible?

1\. Visual programming usually turns into a hot mess. It's actually as hard to
learn properly as a simple programming language and once learned - usually
harder to build things in. How many devs choose a visual environment when
there is a genuine option?

2\. "Simple" languages - BASIC, Python, Applescript, Logo. They often become
complex over time unless ruthlessly maintained.

3\. DSL's - probably is they tend to be, erm, domain specific and therefore
you have to learn from scratch multiple times if you want to do things outside
of your initial domain.

I think a hybrid of all of the above might be interesting:

1\. A visual builder as "training wheels" but always ensure a perfect
transform from visual to code and back again.

2\. A small language with a simple syntax (something Logo or Python-like but
even more carefully curated)

3\. DSL-like behaviour without being a DSL. Extensibility with elegant
syntactic support. Ruby aspired to this but it's Perl-isms stopped it being a
good beginner's language.

~~~
rightbyte
Have you used Simulink? It's quite nice for doing realtime control
programming.

------
njharman
Is a thing where DSLs are expected to be for non-programmers? I mean language
is right there in the name. They are programming languages and you have to
have programming skills to use them.

Unless by non-programmer you mean non-developer. People for which programming
is secondary or tangential activity. Like scientists.

------
jbotz
Who changes the titles of HN posts?

I'm just curious... the blog post has the title "DSLs for non-programmers are
a hoax" and this HN post originally had the same title. At some point it got
changed; I've seen this happen before. Is this HN editorial intervention, or
did the OP make the change?

Just curious...

~~~
GordonS
Mods sometimes change the title if it's incorrect, unclear, or deemed to be
too click-baity.

------
JohnBooty

        P.S. I hate Gherkin, Cucumber and other DSLs that 
        let you write the tests that “read like English”
    

I'm with you there, friend!

But then the author mentions Rspec as a good DSL, so I don't know what their
ideal of a good DSL is because Rspec's about as English-like as it gets.

~~~
thrower123
Any time I've encountered Cucumber-esque testing DSLs, the amount of work that
was required to plumb things up to the actual test code made me want to throw
up my hands and just write xUnit tests or whatever and cut that extra work
out. It's very possible that I haven't worked with anybody that really
understood how this is supposed to work, and with the ten thousand other
things I am responsible for, I haven't had the time or inclination to take a
real deep dive into it.

~~~
JohnBooty
I agree with you completely.

I mean, they want you to write "expect(some_thing).to be_true" and even more
ornate stuff.

I mean, why not "expect(some_thing)" or "expect(some_thing==true)"?

Rspec, Cucumber, etc. _do_ have matchers that are helpful and more concise
than idiomatic Plain Old Ruby but some of them are so basic and yet so ornate
that they really seem like some kind of a joke.

------
hirundo
Anyone who uses a DSL is a programmer. Another way to say that "DSLs for non-
programmers are a hoax" is: Good DSLs make programming easy enough that people
who aren't otherwise programmers can successfully program.

------
nwatson
Jetbrains, makers of IntelliJ IDEA and PyCharm, have a DSL-creator tool called
MPS [0]. It looks interesting, lets you include language and "non-textual"
elements including "math notations, diagrams, and forms." I'd like to apply it
in some context.

[0] [https://www.jetbrains.com/mps/](https://www.jetbrains.com/mps/)

------
anderspitman
When I read Game Engine Architecture[0] I got the impression that DSLs are
pretty effective in that industry. Anyone have war stories of game DSLs gone
horribly wrong?

[0] [https://www.gameenginebook.com/](https://www.gameenginebook.com/)

------
satyenr
I don’t necessarily agree. I have worked with financial analysts using Excel,
SQL etc. quite proficiently. In fact, I am told that familiarity with DSLs
used for data analysis/manipulation tools is considered a part of the job
description by many companies nowadays.

------
taeric
The problem with programming for non-programmers is so many programmers have
told non-programmers that they can't program. Programming is far easier in the
small than we'd care to acknowledge. Don't cripple what you let your users do,
enable them.

------
qwerty456127
DSLs made of elements of a real programming language always seemed weird to
me. When I need a language for a specific domain I just make one from scratch
using either S-expressions or manual string parsing (using just string split
and replace functions).

------
mola
I agree with most. But I find SQL to be a very bad example for a failed DSL.
On the contrary, It is a highly successful DSL. In most large companies
business analysts (with no programming education) do use SQL extensively.

------
banku_brougham
“SQL is a DSL.” Well, it’s certainly not a general purpose language but why do
I feel huffy about this statement?

------
rconti
DSL = Domain Specific Languages

------
karmakaze
TL;DR - DSL's are hard

> The DSL fashion I oppose [...] is the fashion of self-baked business-
> specific tools that are intended to be used by users that are not
> programmers or even tech people. Those require much more effort than a
> regular system and are seldom to be done well. So it is better to think
> twice before creating your own DSL [...]

------
oioiboyo
"In the end when the serious stuff comes in it was always a better choice to
hire someone who really understood what he was doing." \- I know this is a
side point, but it makes it very hard to engage with articles when their use
of gender pronouns deliberately excludes you from being 'someone who
understands what they are doing'. I understand that this is often accidental,
but in 2019 I'd like to think people would be more careful about excluding a
marginalised group in software.

