[chubot]

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-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]

>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]

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]

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]

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

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]

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]

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]

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]

>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]

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.

[aeonik]

I used vim for 10 years (not really an advanced user, but comfortable with it), and I just learned Emacs for the last 6 months...

I am now completely confused by the Emacs vs Vim religious war.

The two programs excel at completely different layers of productivity.

I can't think of any software that radically approaches improving your workflow like either vim or Emacs, and they are both wholly unique.

I also use evil mode in Emacs and while it feels like a great match, it has some impedance mismatch in some emacs packages.

It really makes me wonder if there is a deeper layer of integration that can be done here to really allow people to take the reigns off their interaction with computers.

[em-bee]

I am now completely confused by the Emacs vs Vim religious war

i think at least half of those who keep up with the emacs vs vim war are doing it just to confuse newbies. the other half really just prefers the emacs way or the vi way.

either way though you are right. they are both very distinct, and it's not one being absolutely better than the other.

[ohgodplsno]

To be fair, I have never advocated for Emacs either. Nano for quick edits, proper IDEs for anything else.

[em-bee]

every editing command in nano is either ctrl-key or alt-key. vi/vim is the only editor that i am aware of that doesn't make me stretch my fingers across the keyboard.

[kartoshechka]

rclone allows you to mount remote fs via ssh, it has some quirks but overall I'm able to maintain my self host setup with this. also I'm sure there are plenty of similar plugins, maybe even officially vendored, for all the shiny IDEs