
Ask HN: Are Domain Specific Languages Still a Thing? - gitgud
A long time ago, I remember DSLs were all the rage. The Future was a vision of custom languages designed around the business problems and embedded into apps. But today it doesn&#x27;t feel like that&#x27;s the case.<p>Besides specialised languages for UI, and logic. Does anyone build custom DSLs for each application or industry?
======
btilly
The hype comes and goes, but they always have and always will be, in one form
or another. But they don't always get called DSLs. Put the idea in your
toolbox, and use where appropriate. Call it a DSL or something else based on
what is currently cool.

Good programmers have long known that you should build your language up
towards your application, and then write your language within that language.
What tools are available to do that and where the line is drawn will vary. But
you'll find customized languages buried in your database (SQL), configuration
languages like
[https://github.com/vstakhov/libucl](https://github.com/vstakhov/libucl),
specialized build configuration languages like make or ant, regular
expressions for text matching, and so on.

Some languages encourage building external languages that you then parse and
act on. Others encourage customizing an existing language to your needs. (Our
Glorious Leader published a book in the mid-90s on doing that with Lisp, see
[http://www.paulgraham.com/onlisptext.html](http://www.paulgraham.com/onlisptext.html)
for details.) There have even been languages which are designed to be easily
implemented in other languages, with whatever customizations you want. For
example I personally worked with code from the 1980s that implemented a Forth
variant to write financial models in.

But the idea doesn't have to be literally a new language. Squint sideways at
any API, object model, or library and you can see it as a language.
Conceptually there is a close parallel between scripting web services, and
writing a TCL script that uses prebuilt commands written in C. If you can see
the parallels and see how principles from the one apply to the other, the odds
are that you'll be doing both better. Whereas if you don't see it and reinvent
the wheel from scratch, you're going to wind up learning lessons the hard way
that were learned many, many years ago.

All that said, writing and maintaining a language is significantly harder than
writing business code. Therefore you'll always see rather more people writing
code in languages, than writing languages to make code easy to write.

~~~
marktangotango
Good, very concise

 _All that said, writing and maintaining a language is significantly harder
than writing business code._

The same can be said for writing good APIs and libraries, isomorphic to your
second point.

------
bjourne
People in the thread have been citing HTML and SQL as examples of DSLs. Those
are examples of _universal_ languages but not of _domain-specific_ languages
as envisaged by the proponents of DSLs.

The DSL "philosophy" as presented in for example The Pragmatic Programmer from
2000 was that every programmer should write his or her own domain language as
the situation requires. That every project should come equipped with its own
language, codifying that business problems business rules.

That philosophy, and the surrounding hype, has completely died down. Put
simply, it wasn't a good idea. More languages makes it harder to communicate,
not easier. Plus, writing a good DSL that someone other than the creator of
said DSL can understand is tons of work. Instead, what one aims for is
generality.

~~~
usgroup
ggplot2 is a solid dsl example. Use it with margrittr.

I agree with this in the main unfortunately ... I was a proponent of DSLs and
did my best to try make them whenever practical. The only pattern that’s
worked out for me is the builder pattern. This doesn’t require much work, and
you get something functional that works as you might expect that people
appreciate.

Again ggplot, epic example. Other examples , Varnish, Dockerfile, Nginx, ufw,
etc

------
JohnFen
I'd count the likes of AWK, shell scripting, PostScript, Perl, and even
(depending on how you define "language") HTML as domain-specific languages, so
they do seem to be a thing still.

Personally, I tend to use them quite a lot in my own projects. These aren't
commercial (and often aren't released at all), so might not count. Still, it's
very handy to be able to embed a DSL into a complex project to provide
programmability, and most of the modern scripting languages tend to be too
large and/or too slow for my purposes.

My DSL of choice for this tends to be TCL-based, as I can easily extend the
language in task-specific ways and drop the parts of the language that aren't
useful for the task at hand. This results in something capable, tiny and fast.

------
segmondy
Every complex program is a DSL interwoven with the programming language, so
yes. Unfortunately most languages are terrible at separating the DSL from the
main language like most lisps.

------
kasey_junk
DSLs are endemic in the ops stack. Think HCL for terraform or VCL for varnish.

~~~
cbluth
nginx, cloudformation, and any other JSON-y extension out there

------
ken
By "DSL", do you mean only a text file bundled with the application? I'd say
the simple answer is that the median language got a lot more powerful. We
write DSLs in code now, just like Lisp programmers have all along. We just
don't tend to call them a "DSL" any more.

------
walterbell
Do code generators count, e.g.
[https://chisel.eecs.berkeley.edu](https://chisel.eecs.berkeley.edu)

------
thedday
What about something like Robot Framework? It is used as a test language and
is in widespread use to test websites as well as embedded systems. The
underlying language is Python, a scripting language which might also be a DSL
under some definitions.

------
shatteredvisage
I last developed a small DSL in 2016 at my last company that's still in
production. I haven't seen another since!

~~~
quickthrower2
“That’s still in production” says nothing. Rarely is any code taken out of
production once it’s put there in my humble experience. Not to rain on you
though: good work getting a dsl out there.

------
m0llusk
JavaScript is universal domain which kind of shorted out the metaphor. CSS is
web front end. R is big noodles. Perl is good for parsing HTML with regular
expressions.

