Comment by Gravityloss
6 hours ago
This is partially a tangent, but the whole managing of software infrastructure is a strange culture. There would of course be lots of better ways, but it's too bad the infrastructure side of the software industry lives partially in a parallel world and many of the lessons from elsewhere in the industry are not really widespread there (at least yet). Even banks seem intelligent and innovative compared to infrastructure management mainstream practices.
It's very error prone to describe a hierarchy of versioned software packages and configuration with shell scripts and yaml. Or use text files in git as a database. Or use the CI system as a bad substitute for a proper service (in order to do a simple thing, you must first create the world from scratch). And so on. Mainstream industry knows types, programming languages, relational databases, graphs and you name it, but those have not yet penetrated sufficiently into the infrastructure world. The understanding of the value of having types has been paid in sweat and blood when developing software and databases. Even a basic CRUD application with a basic SQL database will run rings around these Frankenstein monsters: in safety, speed, and extendability.
Yeah I think the difference ultimately is the API surface of infra versus app software. If you're developing software, you get to contain and abstract everything into your own vision of how things should be done with types etc. But infra is managing a whole bunch of other people's software, each with their own vision of how things should be done, which means that often things just fall back to the least common denominator, plain ASCII
> It's very error prone to describe a hierarchy of versioned software packages and configuration with shell scripts and yaml.
We have a multitude of configuration/markup languages all doing the exact same thing.
We have solved this problem in the 60s: S-Expressions. Should have just used that for everything. Configuration, code, websites, you name it. Infinitely extendable, easy to parse.
I personally have dealt a lot with S-expressions, and at this point, given the amount of tooling, I think JSON is just almost always the right choice. It parses fast with SIMDJSON or doing various other approaches to parse sparsely. It's a little under-specified in terms of stuff like number precision, but you can honestly write your own JSON parser which does >600MB/s with an LLM in one shot and do whatever custom validation you want these days. And you get unambiguous maps without having to glean from adjacency list structure like in sexp.
And if you really love sexps, then writing a bunch of arrays in JSON is also viable. If you asked me 10 years ago I might've complained about JSON, but now I think we messed up by having a bunch of other formats, tbh. I have my own TUI JSON editor that can render in tree view, miller tree view, flat view, and inferred table view, and it makes editing JSON very easy too.
Oh and duckdb can query against compressed json and jsonl at GB/s
Going in a completely different direction, Haskell could make a nice, powerful configuration language.
If it compiles, it’s almost certainly correct.
This idea exists (as in a functional language which is used for configuration), and it's called Dhall (https://dhall-lang.org/). But they made it a total language so that it has stronger guarantees of terminating and lots of other config specific stuff.
I'm a lisp nerd, but why do you say sexps are the answer here? I think the point of a lot of configuration formats is that they don't want their configuration to also be a full-fledged programming language.
> I think the point of a lot of configuration formats is that they don't want their configuration to also be a full-fledged programming language.
That seems to be everyone's initial goal, but then it inevitably gets leaky.
I think the dominant split here that forces everything into a weird mismash is that nobody really wants to have to understand arbitrary programming language configs for third-party stuff, they want to read config and know what's going on. BUT for their own stuff, they find reasons to want more power and expressibility...
1 reply →
Sexps, on their own, are not a programming language.
> they don't want their configuration to also be a full-fledged programming language.
They say they don't want it but every configurmation format eventually ends up becoming turing complete at some point.
1 reply →