Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A reasonable configuration language

ruudvanasseldonk.com

Post reply on HN
Print view View original

41–50 of 111 posts

Re: A reasonable configuration language

#41

Post by OJFord »

hnlmorg wrote: post #20
mcphage wrote: post #16

Earlier quoted context omitted.

That’s not really the opposite opinion… the opposite is not allowing trailing commas (like JSON) so if you remove the last item from a list, you need to adjust the line above as well. And when you add something to a list, you need to know if something will come after it, even though you don’t necessarily know. Commas as separator is pretty much orthogonal, and… well, better overall.

I got what they were saying. My point is that if you have a line feed then a comma is an entirely redundant piece of syntax. Commas should only be needed if you are placing multiple statements on a single line. Just like how several programming languages treat semi-colons (eg Go, bash, JavaScript, etc). So mandating them is the opposite of that modern languages should be insisting upon. In Murex (my own language) bot…

It's only redundant in languages that make it redundant, like you mentioned C at the end - it's the new line that's redundant there (or only for readability), it's the semicolon with the 'end' semantics.

Re: A reasonable configuration language

#42

Post by civilized »

ncallaway wrote: post #36
civilized wrote: post #8

I have seen many of these posts now and I have a simple question. Why do we need special configuration languages? Why not just use existing languages? I understand why data formats like JSON and YAML are valuable, and I understand why it would be valuable to use a programming language to automate the generation of such formatted data. But the niche of the configuration language remains mysterious to me.

> Why do we need special configuration languages? Why not just use existing languages? Sure, or you could turn around and ask: Why do we need languages at all? Surely we can express everything with assembly? Or, shouldn’t one language work for all cases? Why not just use C everywhere? And the answer becomes obvious: some languages are better at certain tasks than others! Then, a “configuration language” is just going…

Okay, then in your terms my question would be "why is the best language for configuration not an existing language?"

Re: A reasonable configuration language

#43

Post by teo_zero »

hnlmorg wrote: post #20
mcphage wrote: post #16

Earlier quoted context omitted.

That’s not really the opposite opinion… the opposite is not allowing trailing commas (like JSON) so if you remove the last item from a list, you need to adjust the line above as well. And when you add something to a list, you need to know if something will come after it, even though you don’t necessarily know. Commas as separator is pretty much orthogonal, and… well, better overall.

I got what they were saying. My point is that if you have a line feed then a comma is an entirely redundant piece of syntax. Commas should only be needed if you are placing multiple statements on a single line. Just like how several programming languages treat semi-colons (eg Go, bash, JavaScript, etc). So mandating them is the opposite of that modern languages should be insisting upon. In Murex (my own language) bot…

Would your language also accept this?

  list = %[
    chair, table
  ]
And this?

  list = %[
    chair, table,
  ]

Re: A reasonable configuration language

#44

Post by mst »

lolinder wrote: post #7

Reading through this I'm reminded of another article from about a month ago, An app can be a home-cooked meal [0]. Whenever someone starts on a new language or framework, people are quick to ask "why" and bemoan the proliferation of languages and frameworks. I think this article is a good illustration of the "why". What the author understands that so many don't is that a language can be a home-cooked meal. A programm…

I'm working on something that may end up being rcl-like.

My intention is to make it something that can update existing configuration files just as well as -be- a configuration file, such that if somebody finds it useful, they can use it without their colleagues needing to be aware and with the same commit diffs as if they'd done the same work by hand.

How well that will work in practice is still an open question, though a bunch of my experiments in that direction seem to have worked out nicely so far.

But so long as it helps -me- make changes to a repository that are good, so long as I can ensure nobody else working on that repository needs to care that I used it to help, I figure it's worth the attempt.

(also, hey, I'm having fun :)

Re: A reasonable configuration language

#45

Post by mst »

qznc wrote: post #12
AtlasBarfed wrote: post #2

The configuration rabbit hole, for practically any system that becomes widely applied or through large amounts of feature iterations. With provisioning systems you rapidly walk the ladder because they are basically starting about five steps down on this already: You start with an INI/yaml/json Then you might have several overlaid INIs Eventually: https://docs.spring.io/spring-boot/docs/2.1.13.RELEASE/refer... Go ahea…

I defined myself 5 levels: Level 1 is just values in a file. The Linux kernel uses that. Level 2 is a list of values, e.g. ini files. Level 3 allows nesting. JSON, XML, and YAML are here. Level 4 allows computation but limited. Dhall and Starlark are here. Level 5 is a Turing-complete language. Python, Javascript, etc. RCL seems to be level 5, so I'm not sure if there is really an advantage compared to Python.

I think the goal is to have a language that feels like it was designed for level 3/4 but allows you to break out to level 5 as an escape hatch.

Given how many configuration languages eventually end up with a half-assed level 5 (Greenspun comes to mind) it strikes me as, at least, an experiment worth performing.

Re: A reasonable configuration language

#46

Post by Jtsummers »

zer00eyz wrote: post #21

The problem isnt "configuration" Yaml, JSON, xml, text files... all work great for configuration. But the assumption is that your configuring a piece of software on an already existing system. A config file as means of setting up a system, installing software, and establishing how its going to run is exceedingly stupid. Write your app so it can run on bare metal, install with apt, yum or your tool(s) of choice for yo…

> Write your app so it can run on bare metal, install with apt, yum or your tool(s) of choice for your org.

If it's running on bare metal, why are you using apt or yum? Those are parts of an OS you wouldn't have if you're running your program without an OS.

Re: A reasonable configuration language

#48

Post by Jtsummers »

danenania wrote: post #33
Jtsummers wrote: post #25

Earlier quoted context omitted.

What do you do when your normal programming language stops being your normal programming language (you add a language, switch languages), but you want to preserve details of the configuration? Translate it all into your new language(s)? How do you keep these things synced up? You extract the details into a configuration language/serialization format and then deserialize in every language you work with. Embedding your…

You can compile your general purpose language DSL to json and then I think this isn’t too much of a problem. A bigger issue imo is packaging. General purpose languages aren’t typed well-designed for producing single, understandable standalone files like config languages are. Like I think a simple config DSL in TypeScript could potentially be a perfect way to solve this problem, except that no one wants to lug around…

So turn the general purpose language into a non-general purpose language by creating a compiler for a subset of it. That might be what we'd call a configuration language then since it's no longer actually the original language (in full). Like JSON and others.

Re: A reasonable configuration language

#49

Post by lamontcg »

civilized wrote: post #8

I have seen many of these posts now and I have a simple question. Why do we need special configuration languages? Why not just use existing languages? I understand why data formats like JSON and YAML are valuable, and I understand why it would be valuable to use a programming language to automate the generation of such formatted data. But the niche of the configuration language remains mysterious to me.

People keep hacking up YAML with templating to produce a configuration language which is a bad solution (see for example https://leebriggs.co.uk/blog/2019/02/07/why-are-we-templatin...). The problem is that the people who are using templated YAML don't really want to learn a full-blown language since the vast majority of them never, ever want to write a compiler or a highly concurrent HTTP server. They definitely don't care about functional programming or want to know what a monad is or want to have to learn about first class functions and closures or async/await. They just want a pretty trivial language that you can learn in a weekend or two. The kind of necessary complexity that you might 'add' to such a language before anything else is making it side-effect free so that you can't alter the running state of the system in the language and the purpose is to render a YAML/JSON/TOML config to feed as declarative config into tools like terraform. That focus is much different from a programming language which gives you the ability to execve() arbitrary commands and comes with concurrency primitives that templated-YAML users just don't care about at all.

When you look at it from the perspective of someone who already knows a computer language well it doesn't seem useful, but the point is to address the users who don't know any computer languages particularly well.

And 24 years ago I thought we needed to just use general purpose computer languages and turn system administrators into programmers (or fire the ones that wouldn't learn) but that has clearly never happened, and we're retaining the less-technical-than-SWE roles who manage infrastructure, although its now DevOps people managing k8s with YAML. If just using a general purpose language met the social needs that we have then it would have happened already. The existence of templated YAML and its overwhelming success proves that there's a need that has to be met. I'm still skeptical that any of these configuration management languages is thinking clearly about what need is driving templated YAML though, but its nice that there's an explosion of them so that hopefully sooner or later one of them will really stick and become popular.

Re: A reasonable configuration language

#50

Post by [deleted] »

paulddraper wrote: post #28

> I was struggling with that day was to define six cloud storage buckets in Terraform...The kind of thing you’d do with a two-line nested loop in any general-purpose language I understand this is just an example, but FYI the modern solution is to use CDKTF rather than HCL for Terraform. That allows you to choose your favorite general purpose lang: Python, TypeScript, Go, Java, C#.

[deleted]
Post reply on HN