241–250 of 667 posts
Earlier quoted context omitted.
Not everyone wants a bloated and buggy IDE to write their code for them.
Like vim, for example? Which supports replacing tab inputs with spaces...
Tab indentation has no bugs or corner cases.
Earlier quoted context omitted.
Then what alternative do you recommend for content creators? Do you use the alternative in Markdown front matter?
You should make what you do / don't do less of your identity. You're limiting yourself because you identify as "not the kind of person who does that".
Earlier quoted context omitted.
It'd generate same set of problems in INI, YAML, TOML, XML, JSON, BICF (bayindirh's imaginary configuration format). Because these are not related to how you write the file, but how your software operates in your mind.
How the software operates is of course dependent on the expressiveness of the configuration format, so it is clearly false in most practical senses to claim that the flat key-value format of INI and BICF will generate the same set of problems as formats that allows for list and nesting. If we accept the assertion that the complexity of a configuration file for the stated scenario is constant across all configuration…
You stated a problem: Configure ~6 servers where they share variables.
I can implement it in plethora of ways. The most sensible one for me is to have a general or globals or defaults area where every server overrides some part of this defaults. The file format has nothing to do with the sectional organization of a configuration file. Because none of the files force you to a distinct section organization.
e.g.: Nesting is just a tool, I don't care about its availability. I don't guarantee that I'll be using if that's available.
I can write equally backwards and esoteric configuration file in any syntax. Their ultimate expressiveness doesn't change at the end of the day.
It can be
192.168.1.1
iface_eno1_ipv4_address = 192.168.1.1
iface.eno1.ipv4.address = 192.168.1.1
If you know both languages equally well, LISP becomes as complex as x86 assembly and x86 assembly becomes as easy as LISP. Depends on your perspective and priorities.
If you don't know how to use the tool you have at hand, even though it's the simplest possible, you blow your foot off.
I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. If you need complex logic, use a programming language and generate the YAML/JSON/whatever with it. There you go. Fixed it for you. Ruby, Python, or any other language really (I only favor scripting ones because they're generally easier to run), will give you all of that wi…
There are many graveyards filled with places that tried to start writing logic into their IaC back in the Chef/Puppet era and made a huge mess that was impossible to upgrade or maintain (recall that Chef is more imperative/procedural, whereas in Puppet you describe the desired end state). The Chef/Pulumi approach can work, but it requires one person who is draconian about style and maintenance. Otherwise, it turns into a pile of garbage very quick.
Terraform/Puppet's model is a lot more maintainable for longer terms with bigger teams. It's just a better default for discouraging patterns that necessitate an outsized investment to maintain. Yes HCL can be annoying and it feels freeing to use Python/TS/whatever, but pure declarative code prevents a lot of spaghetti.
Earlier quoted context omitted.
This e-mail enters to my "favorite quotes from internet" list directly from the top.
It is a funny quip, but I wish they'd consider the reformatting. I find using an autoformatter reduces cognitive load while reading and writing.
I always reformat all my code before all commits. It's just good hygiene.
The funny part is the fussing and the answer they get.
I'd just autoformat the area of my patch and send in the patch that way, maybe plus some autoformatted blocks here and there, slowly fixing the stuff as I go.
If something is too bothersome, first try doing something, and figure out the rest of the process as you go.
Edit: blocks became blogs without my knowledge. Maybe I should write a blog post about it. Don't know.
To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it. I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel ( https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... ). Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”,…
If support for JSON with comments was more widely available / in use, we'd use that. But it's not, so we don't.
Earlier quoted context omitted.
Shall we bet on what would happen if we asked 10 random people of any IT stripe to write a small sample INI file? Come on.
The problem isn't with the small configuration files, those are just argv put into a file. Here's an experiment actually worth doing: ask ten people to write a ini file for configuring between 3 and 6 servers where some properties are the same for several servers.
One may write a single value containing a CSV, another may use a convention of namespaced keys, whatever. One may base64, one may urlencode, whatever.
The differences don't change the fact that they will all have the same things in common.
Even without a formal spec, we all know what we are free to change and not free to change, and free to assume and not free to assume. The unwritten spec specifies very little, so what? That means maybe it isn't a good choice for some particular task that wants more structure, but that was not what you said and not what I'm ridiculing.
Or was that all you meant in the first place? That without some more to it to define standardized ways to do things, it's not good for these kinds of jobs? I confess I am focusing on the literal text of the comment as though you were trying to say that the term is not meaningful because it is not defined in a recognized and ratified paper.
I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. If you need complex logic, use a programming language and generate the YAML/JSON/whatever with it. There you go. Fixed it for you. Ruby, Python, or any other language really (I only favor scripting ones because they're generally easier to run), will give you all of that wi…
You shouldn't need the full complexity and power of a Turing complete programming language to do config. The point of config is to describe a state, it's just data. You don't need an application within an application to describe state. Inevitably, the path of just using a programming language for config leads to your config becoming more and more complex until it inevitably needs its own config, etc. You wind up with…
Most of our code is plain boring declarative stuff.
However, tooling is lightyears ahead of YAML (we have types, methods, etc...), we can encapsulate best practices and distribute as libs and, finally, escape hatches are possible when declarative code won't cut.
Can someone help me understand what is the advantage of using jsonnet, cue, or something else vs a simple python script (or dialect, like starlark), when you have the need of dynamically creating some sort of config? I've used jsonnet in the past to create k8s files, but I don't work in that space anymore. I don't remember it being better or easier than writing a python script that outputs JSON. Not even taking into…
But ultimately this was a minor issue and I think it's far more important that you use something like this (whether a DSL or a mainstream PL) and that you're not trying to do string templating of YAML.