[erhserhdfd]

Has anyone implemented a DSL for a professional use case? I would love anyone to share what was the use case, what alternatives did you consider and how did you measure success?

I have previously implemented one for credit policy decisions, but I am not sure in hindsight if it was the right approach and we did a poor job of measuring success, so I would love to hear from the community.

[jerf]

In the full, strict sense presented in the article? No. Since the publication of the book in 2010, we have a lot more serialization languages available to us, and I try to avoid creating a full, true parser for a brand new language when possible.

I've created a couple of things that can be plausibly called interesting DSLs, in the sense of having some grotesquely non-standard execution model relative to the host language, and having language-like recursive grammar constructs, but so far I've managed to keep them within YAML and/or JSON and thus didn't have to create a new language.

(Before someone pops up with "ick! YAML!", consider your options; do you want to encounter your fifth or sixth YAML format, or you want to encounter a brand new bespoke language for whatever it is I solved this way? At least you know how YAML is broken; Jerf's Bespoke Language is a minefield of "interesting" of unknown size and density, and I'm just talking in grammar... we still haven't even gotten to have it actually functions and you've already blown more limbs off than you realized you had.)

Going back even farther, the "interpreter" pattern in the GoF is extraordinarily powerful, but in 2024 I'd update it to if at all possible be written in the form of some existing serialization mechanism that then serializes straight into your AST(-equivalent) and starts off to the races from there. If you have to write a real grammar, well, there may be times that is unavoidable, but if you can avoid it, you can cut much more directly to the "meat" of your task without having to deal with bringing up a complete grammar first.

[SatvikBeri]

I've done two DSLs in my career.

One was for a visual novel video game, where the designers had relatively detailed specs. They had been manually translating those to code, but that was tedious and pretty far outside their expertise. I was contracted to translate those specs into code. I ended up mostly writing a script to turn their specification language into a more structured representation, then translate that into code, with a bit of back & forth to make their language more precise. From everything I heard this was a big success, my script saved them a lot of hours, and the game was pretty successful by the standards of indie games.

The other...is not exactly a DSL, but I don't know what to call it. We had researchers who were writing a lot of numeric code to try and find signals in data. This code often worked, but was slow and expensive to run at large scale, in part because it would have to recalculate intermediate values over and over again. So we wrote a "DSL" that had almost exactly the same syntax as the code they were writing, but was lazy and created a DAG rather than immediately executing, and eventually used the DAG to execute much more efficiently.

[victorNicollet]

I have created a DSL for supply chain optimization over the last 10 years[1], and gave a talk about it back in 2017[2] that summarizes the main reasons why we did this over the alternatives (such as using Python).

We measure success along a few indicators:

- Ease of deployment of an optimization model to production

- Training time required before a new employee (with a background in Supply Chain, but no software development experience) is proficient enough to contribute new code and edit existing code.

- Cost of running all the execution infrastructure

- Frequency of defects caused by running out of memory

- Frequency of package version upgrades that require manual intervention

- Frequency of unsuccessful attempts at auto-completion and other Language Server Protocol interactions

1: https://docs.lokad.com/ 2: https://www.youtube.com/watch?v=_gmMJwjg0Pk

[danielvaughn]

Depending on what you consider "professional". For a while, I was trying to create a DSL for UI designers. The idea was to give them a platform-agnostic syntax, using terminology familiar to their domain, that could be transpiled into platform-specific UI code. I've somewhat moved on from the idea, but the repo is still up - I wrote it as a tree-sitter grammar:

https://github.com/matry/tree-sitter-matry

[rm7]

I've implemented a DSL for casino slot machine mathematics. I originally did it as an internal DSL with C#, but it was too difficult to use. Many of my customers solve these problems using Microsoft Excel, so a programming style environment is difficult, and embedding into an actual programming language even worse.

I then redid it as an external DSL, which has been successful, but a vast amount of work. A more limited environment has a lot of advantages for my users.

[nickpsecurity]

In languages with macros (esp Lisp), you can implement HTML right inside the language. It can become both a data structure that code can be embedded into and a generator of applications.

The huge number of Flask-like stacks makes me think that’s a significant, use case. Double true if the host stack supports live updates of running applications.

You might also look up the iMatix DSL’s that had high-level constructs that compiled to low-level code.

[peterbell_nyc]

Loads. Back in 1999 I built an entire suite of DSLs for generating web applications - you described objects, properties, validation rules, newsletter settings, commerce functionality, forum rules, etc and it used some combination of compile time code generation and run time parsing to deliver the functionality, substantially decreasing the dev overhead in building "good enough" web apps.

[peterbell_nyc]

I will also note, that while it's possible to build a parser generator for external DSLs, for many use cases concrete syntaxes with existing parsers work fine. Back in 2000 I created a set of DSLs for generating web applications and I used the concrete, serializable syntax of XML as I got the capacity to describe types fairly clearly and I didn't need to generate a parser (or more importantly, an IDE plugin with auto complete and type validation). I figured I could always write a lightweight interface to display the info from the concrete DSLs to save business users from the angle brakcets. Json would allow you to do the same these days.

[mrkeen]

I had nothing to do with this work, but it's the first DSL I thought of: https://wiki.haskell.org/wikiupload/c/cf/The_Haxl_Project_at...

[packetlost]

Yes, Rust macro-based, used for defining process-variables for distributed control systems. We can define hierarchical identities with strong types, poll frequencies, cache TTLs, and other metadata that gets serialized and brokered. It's been quite successful (IMO).

[km3r]

Most of the workday application is written in an in house DSL. Certainly has it's limitations but definitely allows for some impressive feature delivery and stability.

[almostgotcaught]

> Has anyone implemented a DSL for a professional use case?

I can name at least 3 ML DSLs that you've heard of.