5 ms·

FWIW this wiki page I started may help frame discussions like this: Survey of Config Languages - https://github.com/oilshell/oil/wiki/Survey-of-Config-Language

by chubot 3y ago

FWIW this wiki page I started may help frame discussions like this: Survey of Config Languages - https://github.com/oilshell/oil/wiki/Survey-of-Config-Languages https://github.com/oilshell/oil/wiki/Survey-of-Config-Langua... It puts a bunch of languages in 5 cateogires. Terraform is at least not a YAML DSL, a very common pattern which I don't understand the appeal of. I guess the main appeal is that you can copy and paste, and pretend it's data in simple cases. But even Terraform suffers from the problem of "external" DSLs -- you end up needing a general purpose language. And yes this pattern has repeated itself so many times. Awk and Make both grew into general purpose languages, and in Make's case it's particularly bad. Most SQL dialects have also grown a pretty bad stored procedure language. So I do think making internal DSLs in general purpose languages is more promising. But they have to be designed for it. There have been many attempts to use Python as a DSL/config language, but it's missing a few things for that, and gets awkward pretty quickly. Ruby does a bit better, but it's not perfect either. It's fairly big and heavy if you just want a config file.

pydry 3y ago
>Terraform is at least not a YAML DSL, a very common pattern which I don't understand the appeal of. I guess the main appeal is that you can copy and paste, and pretend it's data in simple cases. It's easy to write an interpreter for - everything maps to either a scalar, list or a hashmap in any language. It also looks pretty familiar to most people. It gets abused an awful lot but so does every language that gets popular.
- saltcured 3y ago
  I thing you're getting to the heart of the matter here. I'm not sure if I'm being redundant, because I reloaded a few times and see that _many_ posts have been made in the short time since I started looking at this article and reading comments. But, the discussing seems to be bifurcating into different camps. Do you assume that the blog and discussion are narrowly scoped to sysop/devops problems, or a general diatribe on programming languages and product design? For product design, a big part of the problem is choosing your audience. The blog author mentions being happy with a prior ops DSL because it let him think he's not being a "software developer". In my opinion, to target this type of user is to always be on the treadmill of toy DSLs. You have to over-simplify something to appeal to someone who wants to use it without deeper engagement in a programming/software development mindset. But then you have other users who hit the toy's limits and want more, and you either provide two entirely different products or start compromising the simplicity to add escape hatches. In the end, I think you'll always find that you need more of an API/framework in a proper programming language if you want to support all the use cases with one solution. Or you make a poor approximate of a programming language, quite likely repeating most mistakes in the ~50 year history of scripting languages. There has been a lot of this churn in the sysop/devops space where system administrators are being given more complex and dynamic deployment problems. (Facing their devops mirror-world where programmers are being given more operations duties). This tension also exists in other domains, but I'd say the systems operations space has much more stark culture of "scripting" and "config files" as a distinct thing from "programming" and it shows in the tools and perspectives.
  - em-bee 3y ago
    fully agree, especially with the second paragraph. even as a developer, i want a simple DSL that lets me declare things and not twist the data structures into code. and especially as a programmer, if code is needed for more complex structures, i want that to be done in a real programming language. so i am favoring the two products approach, or maybe a language with a well designed syntax for data, where the relationship between the two is like that of JSON and javascript.
    - chubot 3y ago
      FWIW the JSON/JavaScript design is roughly where we're going with Oils We have JSON support for literal data, pure data But you can also interleave code and data in what turns out to be a very Lisp-y fashion, which is useful for configuration https://www.oilshell.org/release/0.17.0/doc/hay.html https://www.oilshell.org/release/0.17.0/doc/hay.html Slogan: We're adding the missing declarative part to shell, called Hay (Hay Ain't YAML) That is, most YAML configs are just nested key-value pairs, where some values are shell snippets ... So I think it makes sense to add declarative data to shell instead!
- em-bee 3y ago
  It's easy to write an interpreter for it's even easier to write an interpreter/parser for s-expressions. i think the designers of YAML had the hope that it would not get abused as a DSL, which makes the abuse even worse. and while i'd love to see an indent based syntax for data, YAML isn't it.
ohgodplsno 3y ago
You can add other languages, such as Kotlin to that list. It is explicitly made to give you the ability to build a strongly typed DSL with proper scoping, references, validation, comes with all the benefits of a real language, including working language servers right out of the box that autocomplete everything properly. But that would require sysadmins to admit that editing all their config through nano with no syntax highlighting is an awful idea, no matter the amount of time they tell BUT WHAT IF I'M SSHING ON A SERVER IN ALASKA. Despite all the complaints I have for Gradle (which, arguably, solves problems much more complex than "Ask AWS to burn through my cash"), its Kotlin DSL is impressively powerful and extensible.
- r0b1n 3y ago
  ssh-ing somewhere strange on a small laggy connection is standard operating procedure. Not having internet is normal. Not being able to write gigabytes of crap into root's home is normal. Not to mention not installing some weird language environment like Kotlin just so the config is highlighted properly. Including all the bazillion libs i'll need. And all the editor configuration that i'll of course have to copy around everywhere. And then debug first, to get the language server working on old CrapHeadDistro 17.9 from back when Obama still ruled. Only to get chewed up in the next security audit for having installed too much useless old crap, because I need that to edit some config files... You can pry vim from my cold dead hands. After pressing <Esc> thrice of course. You may even get me to install a syntax highlighting file somewhere and maybe use netrw if possible. But a random server you are adminning just isn't the same as your average developers single laptop.
  - ohgodplsno 3y ago
    >You can pry vim from my cold dead hands. I won't need to, you're already giving yourself carpal tunnel with all the :wQ! INSERT-MODE :wmkGDonzn zz CWSFD, these hands are already marked for death.
    - em-bee 3y ago
      actually the opposite is true. esc-meta-alt-ctrl-shift[0] is more likely to give you carpal tunnel, than vi where you switch modes and then type commands with single keys instead of twisted key combos. i actually get annoyed at how many ctrl-key combos vim has. [0] i don't know if emacs is that bad, but that's a classic pun that just fit here.

by chubot 3y ago

pydry 3y ago

>Terraform is at least not a YAML DSL, a very common pattern which I don't understand the appeal of. I guess the main appeal is that you can copy and paste, and pretend it's data in simple cases. It's easy to write an interpreter for - everything maps to either a scalar, list or a hashmap in any language. It also looks pretty familiar to most people. It gets abused an awful lot but so does every language that gets popular.

saltcured 3y ago
I thing you're getting to the heart of the matter here. I'm not sure if I'm being redundant, because I reloaded a few times and see that _many_ posts have been made in the short time since I started looking at this article and reading comments. But, the discussing seems to be bifurcating into different camps. Do you assume that the blog and discussion are narrowly scoped to sysop/devops problems, or a general diatribe on programming languages and product design? For product design, a big part of the problem is choosing your audience. The blog author mentions being happy with a prior ops DSL because it let him think he's not being a "software developer". In my opinion, to target this type of user is to always be on the treadmill of toy DSLs. You have to over-simplify something to appeal to someone who wants to use it without deeper engagement in a programming/software development mindset. But then you have other users who hit the toy's limits and want more, and you either provide two entirely different products or start compromising the simplicity to add escape hatches. In the end, I think you'll always find that you need more of an API/framework in a proper programming language if you want to support all the use cases with one solution. Or you make a poor approximate of a programming language, quite likely repeating most mistakes in the ~50 year history of scripting languages. There has been a lot of this churn in the sysop/devops space where system administrators are being given more complex and dynamic deployment problems. (Facing their devops mirror-world where programmers are being given more operations duties). This tension also exists in other domains, but I'd say the systems operations space has much more stark culture of "scripting" and "config files" as a distinct thing from "programming" and it shows in the tools and perspectives.
- em-bee 3y ago
  fully agree, especially with the second paragraph. even as a developer, i want a simple DSL that lets me declare things and not twist the data structures into code. and especially as a programmer, if code is needed for more complex structures, i want that to be done in a real programming language. so i am favoring the two products approach, or maybe a language with a well designed syntax for data, where the relationship between the two is like that of JSON and javascript.
  - chubot 3y ago
    FWIW the JSON/JavaScript design is roughly where we're going with Oils We have JSON support for literal data, pure data But you can also interleave code and data in what turns out to be a very Lisp-y fashion, which is useful for configuration https://www.oilshell.org/release/0.17.0/doc/hay.html https://www.oilshell.org/release/0.17.0/doc/hay.html Slogan: We're adding the missing declarative part to shell, called Hay (Hay Ain't YAML) That is, most YAML configs are just nested key-value pairs, where some values are shell snippets ... So I think it makes sense to add declarative data to shell instead!
em-bee 3y ago
It's easy to write an interpreter for it's even easier to write an interpreter/parser for s-expressions. i think the designers of YAML had the hope that it would not get abused as a DSL, which makes the abuse even worse. and while i'd love to see an indent based syntax for data, YAML isn't it.

ohgodplsno 3y ago

You can add other languages, such as Kotlin to that list. It is explicitly made to give you the ability to build a strongly typed DSL with proper scoping, references, validation, comes with all the benefits of a real language, including working language servers right out of the box that autocomplete everything properly. But that would require sysadmins to admit that editing all their config through nano with no syntax highlighting is an awful idea, no matter the amount of time they tell BUT WHAT IF I'M SSHING ON A SERVER IN ALASKA. Despite all the complaints I have for Gradle (which, arguably, solves problems much more complex than "Ask AWS to burn through my cash"), its Kotlin DSL is impressively powerful and extensible.

r0b1n 3y ago
ssh-ing somewhere strange on a small laggy connection is standard operating procedure. Not having internet is normal. Not being able to write gigabytes of crap into root's home is normal. Not to mention not installing some weird language environment like Kotlin just so the config is highlighted properly. Including all the bazillion libs i'll need. And all the editor configuration that i'll of course have to copy around everywhere. And then debug first, to get the language server working on old CrapHeadDistro 17.9 from back when Obama still ruled. Only to get chewed up in the next security audit for having installed too much useless old crap, because I need that to edit some config files... You can pry vim from my cold dead hands. After pressing <Esc> thrice of course. You may even get me to install a syntax highlighting file somewhere and maybe use netrw if possible. But a random server you are adminning just isn't the same as your average developers single laptop.
- ohgodplsno 3y ago
  >You can pry vim from my cold dead hands. I won't need to, you're already giving yourself carpal tunnel with all the :wQ! INSERT-MODE :wmkGDonzn zz CWSFD, these hands are already marked for death.
  - em-bee 3y ago
    actually the opposite is true. esc-meta-alt-ctrl-shift[0] is more likely to give you carpal tunnel, than vi where you switch modes and then type commands with single keys instead of twisted key combos. i actually get annoyed at how many ctrl-key combos vim has. [0] i don't know if emacs is that bad, but that's a classic pun that just fit here.