1. 14

  2. 18

    A DSL is better than the alternative. Terribly shitty HIDDEN DSL’s embedded in yaml files … cough kubernetes cough.

    1. 4

      My biggest gripe as a programmer of the past ~2 years is pointing out exactly this to ops people and having been met with a blank stare not even understanding what the problem is. I guess there’s a sort of a watershed between people who sees configs as an asset vs. a liability.

      1. 6

        As a programmer turned ops person. This is also my biggest grip. YAML is awful as a language, it’s pretty lovely as a data format (easy to read, easy to format), but using it like Ansible or K8S does is just asking for trouble.

        1. 3

          Most ops people are convinced Turing completeness is evil but they have no problem putting loops in templetized YAML files.

          I think it started with tools like puppet and ansible and their marketing. They needed to sell “not programming” as a hireable skill so they did. Now we’re stuck with weird DSLs that configure and manage enterprise software systems with no reasonable path out of the mess.

          1. 3

            I have been using https://github.com/dhall-lang/dhall-lang for configuration and like it. It has some programming capabilities, but is not turing complete. Though I think the same problem can happen of forcing a tool to do too much.

            1. 1

              Terminating and statically typed programmability seems like a valid tradeoff for a configuration language.

      2. 17

        I don’t consider Emacs Lisp, vimscript or even TeX to be DSL’s. They are fairly general purpose programming languages. Is C a DSL for building compilers and operating systems? Is PHP a DSL for building websites?

        1. 3

          They may not be DSLs formally, but informally, at least in my experience, most Emacs users don’t view the code in their .emacs file as a full-blown programming language . Instead they learn the “magic words” required to set something to a value they want, copy that to a file, save that file, and more often than not restart Emacs and get the correct font color or whatever. Realizing you can apply the change directly by executing that line is next-level understanding.

          1. 2

            Xmonad uses Haskell for its config file. Dues that make Haskell a dsl too?

            And restarting emacs is not a bad idea since you start from amino good state. Making changes on the fly works until it doesn’t. Especially for ui changes on the gui client. Even switching default themes often leads to unexpected results.

            1. 2

              (I’ve deleted my previous reply because I wrote it just before going to bed, having drunk a beer - not a good lobste.rs moment).

              Having thought about this some more, I’m going to go beyond personal preference and experience and say that Emacs Lisp is a Domain Specific Language - it’s a language specific to the domain of Emacs editor programming.

              And Wikipedia agrees with me!

              From that article:

              The line between general-purpose languages and domain-specific languages is not always sharp, as a language may have specialized features for a particular domain but be applicable more broadly, or conversely may in principle be capable of broad application but in practice used primarily for a specific domain.

              This fits elisp to a T.

              I wouldn’t say Haskell is a DSL just because it happens to be used as a configuration language for a specific application. If in 20 years the only place where Haskell is still used is in xmonad, then it would be a DSL.

        2. 9

          I think that the original idea of a DSL was to embed it in another, general-purpose language, e.g. CLOS is a complex object system embedded in Common Lisp.

          The problem is that everyone and his brother keeps on badly reinventing the wheel, only this time square-shaped, chrome and periodically it explodes.

          1. 8

            Single use, tiny languages are my catnip. I actually have to keep the temptation to learn them in check.

            1. 3

              If you check out the documentation section of this site there is a DSL for rolling different dice and visualizing the distributions. It’s the most niche DSL I think I’ve encountered.


              1. 3

                That’s pretty interesting! Some of the basic features aren’t surprising: being able to combine dice, sequences of rolls, etc., is what I’d expect from someone making a dice-rolling DSL. But this has a whole programming language pretty clearly included too, complete with looping and function calls. It’s even seemingly DIY syntax, not exactly lifted from an existing language. I wonder what the history is. Did these features accrete over time due to being needed in modeling some specific dice-roll situations? Was it designed up front as such a full-featured DSL?

                1. 3

                  I don’t know what the history is, but I thought it was fascinating when I stumbled upon it. I was trying to simulate dice rolls for D&D. (What’s the distribution of 1d20s vs 2d10s? How would you do advantage/disadvantage for 2d10s? Etc.) It was very much an “everything you try to do someone else has done 100x better” situation. I was happy with my ASCII command line charts and this guy over here made an entire programming language dedicated to this one problem.

            2. 5

              Most of the other commenters here have nailed it. The author presents this as an either-or choice: pick A or pick B. Good DSLs are just a part of the language. There’s no bright line where one stops and the other begins. The problem is that we’re getting crappy, half-implemented DSLs.

              1. 2

                I’d say, following Fowler in his book on DSLs, that a DSL basically is a library API. So it’s definitely not either-or; it’s and. Moreover, a library can (sometimes: should) have multiple API’s for different purposes.

              2. 5

                Bash is a DSL. I’d rather type cd foo than chdir("foo");. The bash syntax is more productive, as an interactive user interface. I’ll make the same claim for short bash scripts. It’s well known that bash doesn’t scale, you don’t want to maintain a 1000 line bash script. You probably want to use a general purpose language for anything big and complicated. It doesn’t follow that DSLs should not exist.

                1. 3

                  Another word for a Turing complete DSL is programming language. The issue isn’t the syntax but lack of programmability. Throwing out decades of programming language research and tools and replacing them with half ass YAML interpreters is kinda insane. I’ll take bash over whatever bastardization K8s has settled on as its control language.

                  1. 1

                    A programming language can be useful and expressive without being Turing complete. Configuration is just one of many “specific domains”. False dichotomy underneath conceptual confusion. Not going to untangle it here.