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

Abstraction, not syntax

ruudvanasseldonk.com

Post reply on HN
Print view View original

11–20 of 67 posts

Re: Abstraction, not syntax

#11

Post by kmoser »

compyman wrote: post #4
JohnMakin wrote: post #2

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 tire…

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,…

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.

Re: Abstraction, not syntax

#12

Post by skywhopper »

JohnMakin wrote: post #2

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 tire…

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.

Re: Abstraction, not syntax

#13

Post by horsawlarway »

Defletter wrote: post #5

Really wish people would just bite the bullet and do configuration as code instead of trying to make all these config petlangs.

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.

Re: Abstraction, not syntax

#14

Post by kokada »

kmoser wrote: post #11
compyman wrote: post #4

Earlier quoted context omitted.

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,…

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…

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.

Re: Abstraction, not syntax

#15

Post by frou_dh »

Defletter wrote: post #5

Really wish people would just bite the bullet and do configuration as code instead of trying to make all these config petlangs.

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

Re: Abstraction, not syntax

#16

Post by lenkite »

Defletter wrote: post #5

Really wish people would just bite the bullet and do configuration as code instead of trying to make all these config petlangs.

Yes, though languages need to develop and provide restricted execution modes for "configuration as code" for security enforcement.

Re: Abstraction, not syntax

#17

Post by dvrp »

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

Re: Abstraction, not syntax

#18

Post by nickelpro »

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.

Re: Abstraction, not syntax

#19

Post by nickelpro »

frou_dh wrote: post #15
Defletter wrote: post #5

Really wish people would just bite the bullet and do configuration as code instead of trying to make all these config petlangs.

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

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.

Re: Abstraction, not syntax

#20

Post by tekbruh9000 »

Defletter wrote: post #5

Really wish people would just bite the bullet and do configuration as code instead of trying to make all these config petlangs.

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.

Post reply on HN