Live data from Hacker News

DSLs are a waste of time

leebriggs.co.uk

21–30 of 165 posts

Re: DSLs are a waste of time

#21
Ultimately, what is an API but a domain-specific language? This article could well have been written about that.

People often talk about Lisp as a language in which people specify DSLs, but that acronym was something I only encountered outside the Lisp community. The way it always felt to me was that I "simply" designed a set of datastructures and operations around the abstractions and metaphors of the problem domain and then manipulated them to solve my problem. Isn't that the essence of programming in any language?

Re: DSLs are a waste of time

#22
The title is overly broad. They mean a very specific set of infrastructure automation related DSL

I tend to agree on that point. I think CDK and related approaches are much easier. I also find just writing SDK based scripts faster and more reliable. I find very little advantage in things like Terraform, despite my driving a few megacorps to adopt it. (Listen, in my defense, I couldn’t sell the idea of just scripting things, and generally they were repurposing admins who had no programming experience and had a mental block against learning a real language - but somehow a configuration file like language was ok)

However I’ve written a ton of DSLs in my life. They’re always useful, because I write them when I find it cumbersome to not. The broad statement about DSL is of course absurd. However at one point in my life I built a system that made it easy to write DSLs in a monorepo, and it was a huge mistake. Everyone wrote dsls everywhere and you constantly encountered code in some weird language that you had to reverse engineer. So, there’s a DSL entropy principle to be aware of - DSLs are useful if they are bounded. But like anything too much of a good thing ain’t

Re: DSLs are a waste of time

#24
This is where Chef got it right over Puppet, but of which were written in Ruby. But Chef recipes are just Ruby files, and they make use of the Ruby language to do the same thing because it's perfectly capable of describing things that way.

Re: DSLs are a waste of time

#25
This push and pull on "programming language vs DSL" will be with us forever. Some people love maven because it's a concise DSL, easy to understand if you understand maven. Some people like gradle because it's a DSL with a major escape hatch in that it's also just the groovy programming language with all that entails.

This dance has played out with the likes of the Javascript community. Just write a js script, no actually we need a pipeline so let's use grunt. Actually we hate grunt so let's use gulp, actually gulp is just wrong lets get declarative with webpack. Actually that's too inflexible and weedy let's just use a framework (like react-scripts) which just runs our code and gets out of the way.

After 10+ years of programming, it seems like we are on an endless loop of "let the framework do everything" to "let's enable maximum flexibility with a full programming language". (see ant in the java world for an even earlier version of this). It seems like the push and pull is this constant problem that "describing the problem is hard, and messing up that description makes everything more complex to maintain". The lack of flexibility feels nice because there's less to mess up, but then when something really complex arises you usually end up doing something 10x more nasty than you would with an ultimate flexibility framework. On the flip side, super flexible frameworks lend themselves to being completely unique butterflies that require a heavy up front research to understand (as, you don't know what that foo method is doing and why it does it). They can 1x the complex situation but it feels like the tendency is to want to overcomplicate simple problems by reinventing a framework for your company. (My company is dealing with this and jenkins pipelines)

Re: DSLs are a waste of time

#26
post #7
post #4

I think calling terraform a DSL in comparison to general purpose programming languages misses the point. If it used a declarative GPPL instead of HCL I wouldn't care, but imperative alternatives general purpose or not are 'a waste of time' & not fit for the domain, IMO.

Pulumi is an example that proves the exception: using a general purpose language, you create a declaration of desired state. Think of it like if you used a GPPL to emit HCL. You get the power of that language: loops, function calls, unit tests, or even the ability to call external APIs. You're declaraing desired state and letting the framework sort it outb which is you say you aren't writing imperative code like: if…

That’s the key. Declarative converging systems so much better than imperative and all the edge case handling necessary.

Re: DSLs are a waste of time

#27
This really rings true for me. I’ve used many DSLs over the last 20+ years. Build systems. UI definition files. Orchestration languages.

They always start simple and easy, but they always eventually grow so complex that using a real language would be preferable.

I’ve never seen a system remain at the same level of complexity (or much less shrink) over a multi year timeline.

Re: DSLs are a waste of time

#28

We stop calling the useful ones “DSLs” so this is a truism. Is SQL a “waste of time?” Regular expressions, HTML, Makefiles, CSS (and CSS selectors aka jquery selectors)? It’s the bad ones that are a waste of time. The ones still called “dsl” instead of just “language, “format,” or “syntax.”

SQL would be my #1 example too.

It is probably the ultimate DSL if you are willing to get deviant with your tech stack.

Re: DSLs are a waste of time

#29
Hyperbolic blog posts are so annoying.

Really, if OpenTF happens, you’ll be back to square one?

“ When the maintainers of OpenTF inevitably decide that they want to add enhancements that require language changes, you as the end user end up in a situation where you’re effectively back to square 1, learning (potentially) a new DSL.”

Re: DSLs are a waste of time

#30

This is a great takeaway from the article-- "programming languages are the better authoring model for cloud infrastructure". I was surprised by the simplicity of the "complex" terraform example the author offered, I have seen much thornier Terraform. The title, while appropriate for an article inspired by Terraform, I think misses the benefits DSLs have paricularly in LISP-derived ecosystems. A much better title for…

Well... it's part of the cycle. First you create a declarative language to describe WHAT you want the infrastructure planner to generate. Then when your customers discover its limitations, you create a pulumi style imperative "infrastructure builder" language (or library). Then when people complain they have to do everything by hand, you create a different declarative language using whatever transfer syntax is popular that month. Then you keep repeating the cycle to ensure you have something to talk about on your blog every funding cycle.

Though... yes... I've had decent luck with DSLs in Lisp-land. It's not a panacea, and there's a couple months of training when we pick up new engineers, but for our app, it seems to work out fine.

Post reply on HN