Some DSL are success stories (SQL, HTML, CSS, etc).

But most DSL I encountered in the wild were terrible: no community, weak tooling and documentation, plenty of design mistakes and limitations.

And there are so many in the shadows of the corporate caves, lurking in systems created by the cowboy of the moment who though that would be the perfect solution to the problem du jour. It then had to be supported forever, leaving bugs, frustrations, and unsatisfied programmers and users in it's wake.

9 times out of 10, a library would have been a better choice.

But even famous and popular open source DSL can be a mistake. For me the most obvious example is Ansible. Because they needed idempotence, and maybe expected other languages to join in, they created a YAML based DSL.

In the end, you get a terrible coding experience, learning the thing is depressing and can only be leverage for this very tool, plus debugging very complicated deployment files is a huge hassle.

The ironic part ? In the end this DSL just call Python modules. It's just bytecode with extra steps.

They should have skipped the middle man and gone with a well crafted Python API + tooling + doc making hard for you to make something non idempotent.

> And if a type system can not guard against run-time errors, what’s the merit of having one?

The type annotations would document the programmer's assumptions and lead to fail-fast behavior. In the presented use case, it would be immediately clear from the run-time type error that the input data isn't in the expected format (as opposed to a typing bug somewhere else in the program).

The problem author describes, is very similar to the problem of response caching. And DSL that may be similar to Varnish DSL

https://varnish-cache.org/docs/trunk/users-guide/vcl.html

Varnish VCL, accomplishes the job, but far from elegant, of course.

It would be nice, indeed, to be able to start from some template of a rules language.

Where one can customize the 'language syntax' of declaring entities, and what to do with them. And,then, to implement a domain-specific backend (either as code generated, or as interpreted at run-time).

I could not find a framework like that when looking for it, however.

( At the time, I was looking for something allows me to quickly build frontend, and backend runtime in language that can be embedded into java, C++ and javascript).

I started with metalua (this was years ago), and some success but was too difficult at the time to take it further.

Then I tried xText and xtend (so that I could get automatically an IDE.. but again was too difficult).

> > "... The project I am currently working on involves receiving and processing gRPC messages from some A-brand network devices. The messages contain ordered sets of key-value pairs. The meaning and naming conventions for the keys and values varies greatly and is inconsistent across different message types. The problem was how to describe various processing rules for the messages...."

I'm neither a fan of new languages nor dsl's, so I'm in a minority? Rather than a dsl, I want a great API, and before apis I want compact and expressive utilization of existing apis.

Interesting approach! I've been contemplating a similar query DSL for compressed time-series data on embedded devices. It's easier to make a specialized language than commonly thought. Though generally the trickiest part is creating appropriate tooling for things like source maps, debugging, etc.

It surprises me that the author used Elixir for implementation but didn't just write a query DSL utilizing the Elixir macro facilities [0]. A macro based DSL likely would be much simpler than writing a new grammar and builds on existing language tooling. Ecto for example does a great job (IMHO) of making a sane DSL for SQL [1]. Given data processing primitives provided by Elixir libraries like Streams and GenStage [2] it seems it'd be pretty straightforward to implement.

Take for example the "segmented query path expression". It is handled fine with a minor modification as an Elixir quoted statement:

`quote do: @query_path//foo/goo[instance='a2']/blah/x[a='S 512']/y`

That yields a well defined AST tree base on the Elixir syntax: ``` {:@, [context: Elixir, import: Kernel], [ {:path, [context: Elixir], [ {:/, [context: Elixir, import: Kernel], [ ... ```

The closures work as well by switching the dollar signs to ampersands: `quote do: select(@path/foo/&x/&goo/z/y/w, { value(&1) < 3 })`

Makes me want to write an Ecto adapter for dealing with Elixir Streams. =)

0: https://hackernoon.com/understanding-elixir-macros-3464e1414... 1: https://github.com/elixir-ecto/ecto 2: https://hexdocs.pm/gen_stage/GenStage.html

Interesting use case ! I think model driven engineering deserved to be treated better nowadays. For people against DSL, just try to play with Ecore (Eclipse) and Xtext, you will be amazed by the speed of conception, and by the powerful reusability of your model. DSL is just the tip part of the iceberg, the concept of meta-model for example is a very interesting to study.

I knew I read about "A domain-specific language for processing ad hoc data" in my interwebs trawling -> https://pads.cs.tufts.edu/papers/pldi.pdf (pdf).

IIRC I got a grammar working then went off to play with some new shiny thing before trying to get it to generate some code since I didn't really have a use case beyond just playing around though I believe my plan was to get it to spit out AST classes since my ASDL parser/generator is kind of a goofy mix of boost::spirit and moustache.

https://github.com/dhall-lang/dhall-lang seems like it might have been a suitable candidate here also.

Check out Gremlin by Apache TinkerPop: http://tinkerpop.apache.org/gremlin.html It is a Turing Complete language that can be embedded in any host language that supports function composition (f.g) and function nesting (f(g)). Finally, if this resonates with you, https://arxiv.org/abs/1508.03843 .

I wish the author went into their failed attempts at traditional tools. I can't help but think XPath and an existing language would do the job and be more approachable to would be maintainers.

Related Racket blog post under discussion at the moment:

https://news.ycombinator.com/item?id=19232068

Quite a neat language, I just wished there was more code samples / full ones, and/or having the code be open sourced (maybe not possible depending on the employer).

Also I thought it was going to talk about something like the Blub Paradox: http://wiki.c2.com/?BlubParadox

Oh, I did almost the exact same thing once in an SQL database reporting system, brings back memories!

  /foo/*/blah/*/y

We were putting very hierarchical data into a "flat" database, but we still wanted to be able to query on those deeply nested paths. At the time our front end used a lot of XSLT as well so it was a similar approach. Writing the library that turned these "special" queries back into SQL was one of the more fun engineering projects I ever worked on. Definitely wouldn't do it the same way today but for the project it was a good fit.

http://restsql.org/doc/Overview.html is pretty awesome. Same guy who wrote YAML spec I think.

I don't see why this can't be implemented as a simple library, with perhaps a little more verbosity.

For example:

> select(/foo/$x/$goo/z/y/w, { value($1) < 3 })

Could become in JS:

    select("/foo/$x/$goo/z/y/w", function(a){ return a<3; })

Nice! It'd be good to hear Stephen Dolan's story of how jq [0] came to be!

[0] https://stedolan.github.io/jq

I have been coding for 49 years. And people seem to be imventing new languages at a steady rate the entire period. The cutrent emphasis is mobile full stack and cloud OS.

Glossing over the numerous articles and he's clearly an intelligent fellow. I can't follow even half of the concepts.

> And if a type system can not guard against run-time errors, what’s the merit of having one?

This makes me really question the author's credibility. Clearly the author is pretty confused about static vs. dynamic type systems, and the value and history of type systems in general.

The link didn't work from my part of the world so I couldn't read it, but the title is self-explanatory, so I'll make a point which you may have already made. Previously constructed languages like Esperanto use vocabulary sampled from European languages only, which I suspect is why they haven't become popular. A new language would need to take words and grammar from non-European languages also, such as Arabic, Swahili, Chinese, Japanese, and Indonesian, in order to be adopted in any meaningful scale.