Lessons learned working decades with Graphical DSLs | Hacker News Reader

Lessons learned working decades with Graphical DSLs

tomassetti.me

41 pointsteleforce11 comments

This article could have been immeasurably better with some actual examples. Not hand waving about large industry initiatives but actual examples of how this vendor helped their customers and what the resulting DSL looked like.

Perhaps I am cynical but I don't really buy the justification that no customers would to share their DSL due to commercial considerations. That's just what many would say if selling some snake oil product and not wanting to provide any details.

I have designed several DSLs over my two decades of being a professional engineer. Not graphical; but the people using my DSLs are always developers.

I will probably use YAML for the foreseeable future instead of creating new languages or interfaces. Think like how CircleCI configuration works. Essentially it is a DSL, but implemented in a format that is widely used and easy to write and parse.

Another invisible problem with embedded-DSLs (like maybe building within Yaml) is the inability to break the host language’s constraint, limiting utility of the desired DSL

But the only functional constraint is just how it looks when it is serialized. You can write any language’s AST to yaml; it will look like yaml, but the representation at least allows for Turing complete behavior.

I do have issues with how yaml deals with strings, but it’s the best popular format I think I can use, and seems appropriate for developers.

You can write any language's AST to YAML, but not the other way around.

YAML is extremely limited and a very bad choice for DSLs. CircleCI got it wrong. Their configuration files are extremely verbose and hard to abstract over - you have to use orbs and those come with a lot a of flaws. I'm a user for many years now and it's diminishing my productivity.

The solution isn't so hard - even Jenkins got it right. Use a regular programming language (maybe the one of your choice or one that is well suited for DSLs like Scala or Clojure) and then just expect your developers to build a datastructure in that language. This datastructure is your DSL.

Your users get a lot of stuff for free, including fully fledged code-completion and compile-time safety (if you use a statically typed language). It will also be easy to abstract over commong logic and even share it if the language has any kind of module/library system which almost every language has.

Exactly like the Kotlin DSLs provided in TeamCity for this, atleast better than Yaml parts

Another example where, aspects like linking/checking etc are being worked around Yaml limitations are in K8s CDKs.

Definitely this is a very fair criticism to my comment. I don’t fully agree yaml is bad, - I think it depends on use case But I appreciate you bringing up the other side; I agree somewhat that CircleCI is not as easy to use as it could be due to their choice.

FWIW, the most recent thing I built that could be considered a DSL is how we define roles where I work. It’s a lot like IAM policies. I wouldn’t want to run arbitrary code when parsing these documents, and I think yaml suits it well.

> I wouldn’t want to run arbitrary code when parsing these documents, and I think yaml suits it well.

I understand your point that it might be harder for you to run arbitrary code. Depending on where it runs you need to make sure to isolate it.

But other than that, I think your imagination isn't correct. Because even if I want to define something like permission-policies, there is usually a lot of repitition that I'd like to factor out. And doing that with YAML is most often impossible.

But if you still decide to go with a non-programming language for configuration, then have a look at dhall: https://dhall-lang.org/

It allows a lot of logic/abstraction through functions and imports, is typesafe and also has builtin YAML generation. Even the few code examples at the page that I linked above show how you can factor things out easily there.

"So if it’s built on top of an open source stack, then it’s really hard for people to ensure that well, it continues to work next year for sure too. That’s the path we have been taking 20 years ago and that’s the path we currently continue."

Some interesting reading in this interview but the open vs closed source bit goes off the rails unfortunately.

From what I’ve seen, DSLs are one of the few products where user benefits almost always outshines customer benefits. This is where, it becomes very difficult to justify and hence almost always stay-away-from-market tails.

Who are the users if not the customers? And why do DSLs provide benefits to users, but not to customers?

Reply on news.ycombinator.com