[HN Gopher] Abstraction, not syntax
___________________________________________________________________
Abstraction, not syntax
Author : unripe_syntax
Score : 42 points
Date : 2025-10-13 08:45 UTC (14 hours ago)
(HTM) web link (ruudvanasseldonk.com)
(TXT) w3m dump (ruudvanasseldonk.com)
| JohnMakin wrote:
| As someone who's spent most of their career in cloud IAC, and
| likes to think they are pretty read up on the latest going on in
| that world, if you didn't know better you'd think YAML is one of
| the greatest threats facing mankind. There are plenty of things I
| certainly hate about it, but every configuration syntax I've ever
| used I have similar gripes about. It's like once a month this
| kind of "The world is growing tired of yaml" claim is just thrown
| out there like everyone just agrees with it. Choose something
| that works for you. This author repeatedly mentions TOML but
| there are plenty of issues with that one I could point out too.
| Syntax is one very small part of what makes an ecosystem great or
| not so great. Most of my exposure to yaml is helm chart
| templates, which admittedly is not pure YAML, but it works fine
| enough for me, at least to where I don't feel like writing
| lengthy blog posts about how much I hate it. I even wrote a
| library that converts yaml templates to HCL for internal use
| because I got so sick of people having this exact same argument
| like it deeply mattered. And guess what? They hate the HCL too.
| compyman wrote:
| I also think that a lot of the problems with yaml specifically
| are overblown, but this post is actually not about that!
|
| It is specifically saying the same problem exists in
| JSON/YAML/TOML, etc, which is that all these configuration
| languages don't have any real means of abstraction, and
| ultimately aren't expressive enough do to the job we require of
| them.
|
| as soon as you are templating config files with other configs,
| I agree, I have sorely felt this limitation with helm charts
| kmoser wrote:
| Serious question: do people who work with these config files
| frequently, or on large such files, use simple text editors,
| or are there "smart" editors that do things like prevent you
| from making typos or inserting the wrong data type, similar
| to an HTML form that does basic validation or a DB schema
| that rejects bad data?
|
| There is no single cure-all, of course, but surely we should
| be relying on computers to do much of the heavy lifting when
| it comes to validation and verification of these files, not
| just as linters after the fact but in realtime while we're
| editing, and with some sort of knowledge (even if derived
| programmatically) of what is right and what is wrong so we no
| longer have to worry about simple footguns.
| kokada wrote:
| I think one of the problems of those "configuration
| languages" is that you can extract semantic information
| without knowing the target, e.g., with has a specific
| meaning in GitHub Actions but it is otherwise an
| unremarkable word in the YAML specification.
|
| But when working with real programming languages it is
| completely different, you can take semantic information
| from the current code, and you can have things like types
| to give you safety.
| taeric wrote:
| I'm trying to remember the phrase. Something like, "there is
| nothing as vicious as low stakes fights."
|
| Trying that on Google gets me
| https://en.wikipedia.org/wiki/Sayre%27s_law. Is about right. :D
| skywhopper wrote:
| HCL is generally great, but has some issues with clarity of
| transformation to the underlying data structures.
|
| But anytime someone suggests TOML I have to double check to be
| sure they are serious because the TOML syntax for anything more
| complicated than single-layer maps is mind-bogglingly confusing
| to me. This is not a serious alternative to YAML.
| Defletter wrote:
| Really wish people would just bite the bullet and do
| configuration as code instead of trying to make all these config
| petlangs.
| patrickmay wrote:
| Exactly. Emacs Lisp is an existence proof that this can be done
| well.
| taeric wrote:
| You beat me to it!
|
| And for those that haven't taken a look at it, the
| "customize" menu and everything it supports is silly
| impressive. And it just writes out the results out, like a
| boss.*
|
| * Obviously, it has a lot of "don't edit below this line"
| complexity to it. But that doesn't change that it is right
| there.
| skydhash wrote:
| My preference is towards simpler formats like:
| option value
|
| Easy to edit and manipulate. JSON and YAML is always a
| nightmare if it's user facing. As for ansible, I'd love to see
| some scheme/lisp variants.
| horsawlarway wrote:
| I appreciate that the ts/js ecosystem seems to be moving in
| this general direction.
|
| Lots of config.json is being replaced by the nicer config.ts.
| frou_dh wrote:
| When Python projects used that approach (setup.py files) that
| meant to just know what a package's dependencies were,
| arbitrary code had to be run. Now it's pyproject.toml
| nickelpro wrote:
| pyproject.toml calls into a build backend which is... Python.
|
| It is good to have a simple, declarative entry point to the
| build system which records declarative elements of the build.
| The non-declarative elements of the system are configuration-
| as-code.
| lenkite wrote:
| Yes, though languages need to develop and provide restricted
| execution modes for "configuration as code" for security
| enforcement.
| tekbruh9000 wrote:
| This year I started using an SQLite file specifically for
| config values
|
| Have used everything from Json to Cue and in-between. Tired of
| the context switch. Need to use SQL anyway. Fewer dependencies
| overall required.
| mrmrcoleman wrote:
| Curious - how do you version the config?
| apalmer wrote:
| I don't think the title and the article really communicates it's
| case well. Did not understand the goal until 90% through the
| article when they showed the source code of RCL with the loops.
|
| This isn't syntax vs abstraction. This is how much programming
| language power do you want to enable in your configuration
| language. This is a big difference and I think we miss the
| interesting part of that discussion because we dip into this
| 'abstraction angle.
| dvrp wrote:
| Should be titled "the power spectrum of data" or something
| similar
|
| the article talks about the trade off between plain data
| structure versus abstract ones and that's the main issue
| nickelpro wrote:
| Yes, one more DSL on your Tower of Babel tech stack will save
| you.
|
| If you want configuration-as-code use Python. Please. Or Tcl if
| you must. Do not invent N+1 DSL for your engineers to waste time
| learning.
___________________________________________________________________
(page generated 2025-10-13 23:00 UTC)