Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflections on the Lack of Adoption of Domain Specific Languages [pdf]

grammarware.net

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Reflections on the Lack of Adoption of Domain Specific Languages [pdf]

#21

Post by jamesblonde »

bnr wrote: post #7
jamesblonde wrote: post #5

Earlier quoted context omitted.

We built the first open-source feature store for ML, https://github.com/logicalclocks/hopsworks , when every existing proprietary feature store (Uber Michelangelo and Bighead at AirBnb) were shouting about how their DSL for feature engineering was the future. Fast-forward 2 years and it is clear that Data Scientists want to work with Python, not with a DSL. We based our Feature Store on a Dataframe API for Python/PyS…

The article (controversely, maybe) classifies libraries for general-purpose programming languages as internal DSLs. One could argue that Data Scientists working with libraries in Pythin are already using a DSL, just with an escape hatch into the general-purpose world. I don't think proper vertical DSLs should be made marketed towards people who are comfortable working in a general-purpose language. I see them as a wa…

A library is not a DSL, despite what the learned authors may claim. In fact, there are a couple of examples of "successful" DSLs in the data world - you could argue that Talend and DBT are visual programming tools for ETL pipelines. Defintely Zapier- which is just for integrating services that have well-defined REST APIs.

Re: Reflections on the Lack of Adoption of Domain Specific Languages [pdf]

#22

Post by notacoward »

m-hilgendorf wrote: post #18
notacoward wrote: post #9

It seems to me that the main reason DSLs aren't more widely adopted is that any DSL will be unsupported by other tools developers consider more important. Your IDE won't have syntax highlighting and auto completion for it, and a lot of developers nowadays seem crippled without those. Linters and semantic checkers won't understand it. Nor will debuggers. There will be no mocking libraries or makefile rules for it. The…

I think this is a great point, but I'd counter (disclaimer: I work on developer tools for a DSL). It's a great time to create language tools. The language server/debug adapter protocols make it possible to develop a rich backend for your language of choice and a thin client to integrate into many editors, rather than extending a single editor/IDE platform. You don't really need to build an entire IDE to create a rich…

> It's a great time to create language tools.

Absolutely. In fact, after I wrote that comment I started thinking about what could be done to make this easier. Language servers help a lot with some parts. Linters and checkers might be able to use something like that, if you're transpiling. Run standard tools on the target form, but with ways to tie results back to the original source. If we stick to a transpiling model, CI/CD integration might also be eased with a generic DSL adapter that just needs to know extensions and target language. It's now on my list of "maybe some time" projects now that I have a lot of spare time, but TBH it's not high in that list so I doubt I'll get to it.

Re: Reflections on the Lack of Adoption of Domain Specific Languages [pdf]

#24

Post by juancn »

They miss the main problem: tooling.

DSLs are nice, but you need to integrate them into a development workflow which means strong IDE support and build systems. Auto complete, testing, backward compatibility, etc.

If I normally have code in my IDE, where I right click on a test and choose run, everything is done for me, no fuss.

If I integrate a DSL, things stop working as normal. Unless it's a widely supported DSL, such as regular expressions.

Re: Reflections on the Lack of Adoption of Domain Specific Languages [pdf]

#25

Post by juancn »

notacoward wrote: post #9

It seems to me that the main reason DSLs aren't more widely adopted is that any DSL will be unsupported by other tools developers consider more important. Your IDE won't have syntax highlighting and auto completion for it, and a lot of developers nowadays seem crippled without those. Linters and semantic checkers won't understand it. Nor will debuggers. There will be no mocking libraries or makefile rules for it. The…

It's not crippling, it's annoying. I can code without an IDE just fine, I just don't want to.

It's too slow and you end up doing a lot of very repetitive and boring tasks. Modern IDEs, much like type systems, help you avoid whole class of errors.

Why type a method name, with the risk of typos, when with 3 keystrokes it's filled for you and provably correct.

Same for renaming operations, function/variable extraction, etc.

Also, code navigation. Large codebases are read a lot more than written. And code is not read like a book, it's more like traversing a graph. Do dataflow analysis, find usages, analyze hierarchies, etc.

Re: Reflections on the Lack of Adoption of Domain Specific Languages [pdf]

#26

Post by m-hilgendorf »

notacoward wrote: post #22
m-hilgendorf wrote: post #18

Earlier quoted context omitted.

I think this is a great point, but I'd counter (disclaimer: I work on developer tools for a DSL). It's a great time to create language tools. The language server/debug adapter protocols make it possible to develop a rich backend for your language of choice and a thin client to integrate into many editors, rather than extending a single editor/IDE platform. You don't really need to build an entire IDE to create a rich…

> It's a great time to create language tools. Absolutely. In fact, after I wrote that comment I started thinking about what could be done to make this easier. Language servers help a lot with some parts. Linters and checkers might be able to use something like that, if you're transpiling. Run standard tools on the target form, but with ways to tie results back to the original source. If we stick to a transpiling mode…

I have my own ideas about making CI/CD for DSLs easier. I don't think transpiling is necessarily the right approach, since not every language has a valid transpilation targe (here's my bias showing - consider a hardware description language, there can't really be a transpilation target).

One of the problems in designing generic tools for language development is they have to be far more abstract than the author might realize at first. The notion of evaluation is a big one, as in what it means to evaluate a chunk of code, what its results are, its intermediate products, and when the evaluation takes place (is it compile time, run time, parse time, etc). I think the next generation of tools are going to inspect these subtleties a lot more than traditional tools, since it has a big impact on usage when languages have heavy macro or other compile/parse time evaluation.

Re: Reflections on the Lack of Adoption of Domain Specific Languages [pdf]

#28

Post by rualca »

cle wrote: post #17
rualca wrote: post #10

Earlier quoted context omitted.

> I don't want MAKE, or whatever DSL, I want to be able to drop into a real programming language when necessary. So libraries. That's one opinion, sure. However, DSLs are always in a far better position to solve domain-specific problems because, unlike generic programming libraries, they not only reflect domain-specific knowledge and best practices and represent standardized solutions for recurring problems. Conseque…

It’s funny you mention the latter, I’ve seen an industry-wide trend toward using standard programming languages with those things (Pulumi, CDK, et al). I’ve started using them myself. I’m not convinced yet that they’re better. Gradle seems to be an interesting case of a successful build system with an interface in a real language (Groovy), although Groovy is so dynamic that the line between Groovy and DSL is pretty b…

> I’ve seen an industry-wide trend toward using standard programming languages with those things (Pulumi, CDK, et al).

I can't really talk about Pulumi, but CDK is just a high-level CloudFormation generator, and arguably one whose only usecase is to serve as an ad-hoc template engine, much like SAM.

CDK is currently one of 3 or 4 offerings from Amazon that handle the same usecase, thus it's strange that you decided to refer to it as an industry trend when at most is a cherry-picked example.

Meanwhile, should we ignore how the entire industry, from Kubernetes to Docker Swarm and passing through Ansible and Chef and whatever other tools, runs on tools that use domain-specific languages?

> Gradle seems to be an interesting case of a successful build system (...)

...yet it's market share is completely eclipsed by the dominant tool, Maven, in spite of Android's push.

Re: Reflections on the Lack of Adoption of Domain Specific Languages [pdf]

#29

Post by permille42 »

This article misses the broader goal/reason to use DSLs. That reason is metaprogramming.

DSLs are very powerful and extremely effective when they simplify how some specific task or sequence must be configured.

When you do something repeatedly in a programming language where it seems like there is a lot of copy/paste, that is exactly when a DSL should be created and applied to avoid that sort of behavior.

In this sense, good DSLs are deeply related to the low-code movement.

When enough DSLs are made, need to write all logic in a general purpose programming language will be minimalized.

The place where this can most be seen currently is in process management systems and the DSLs used to configure them. Few are familiar with these because they are very expensive enterprise tools used to rapidly setup business processes and related interfaces.

Post reply on HN