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

51–60 of 67 posts

Re: Abstraction, not syntax

#51

Post by radarsat1 »

Joker_vD wrote: post #47
radarsat1 wrote: post #41

I got confused reading this because I wasn't sure how I, as a reader with no knowledge of the system under discussion, was supposed to know that all the buckets should be in the same region. Nor is it clear to me how the "for loop" version would handle the case where exceptionally one bucket is different. Which is a more interesting discussion imho, that's the whole point of having it as a configuration field, after…

Like this: region = if name == "bravo-hourly" then "us-west" else "eu-west",

I see, not so clean imho but I guess it works.

Re: Abstraction, not syntax

#52

Post by saurik »

texuf wrote: post #43

Yeah no. The reason we don't write code in config files is that, if we did, in order to know what you are deploying you have to run the code in your head. Not just this code, the code that Steve wrote six months ago before people noticed he was grossly incompetent and fired. Also worth mentioning, I can run this code in my head. The author can run this code in their head, but not everyone can. And finally, if the aut…

Or you could run the code on the computer, instead of your head, and then view it on the computer as well... the same computer you were going to view the file in the first place? These files aren't being printed on paper... you have access to a computer: use it!

Re: Abstraction, not syntax

#53

Post by skydhash »

mrheosuper wrote: post #40
skydhash wrote: post #8

Earlier quoted context omitted.

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.

then how you distinguish between string "52" and number 52 ? Keep adding more edge cases and you have something resembles JSON

Why do you need to differentiate between the two as an input? It’s config, not random data. If you have

  email test@example.com
  logo-size 100
  background #adadaf
  modules auth
  modules db
  modules files
The only reason to have special token here is if you multiple line values. Types are not a concern.

Re: Abstraction, not syntax

#54

Post by bandie91 »

mrheosuper wrote: post #40
skydhash wrote: post #8

Earlier quoted context omitted.

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.

then how you distinguish between string "52" and number 52 ? Keep adding more edge cases and you have something resembles JSON

i don't. and neither my perl-based softwares. there should not be the possibility whereas a given parameter can have both string or a numeric value too at the configuration level which the user interfaces with - as of the "real-world analogy" programming paradigm suggests. json and stuff still do have their place but in a lower, machine-to-machine layer.

Re: Abstraction, not syntax

#55

Post by your_fin »

nikeee wrote: post #22
horsawlarway wrote: post #13

Earlier quoted context omitted.

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.

I really dislike it when a turing-complete language is used for configuration. It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it. Also I've been in projects where I had to debug the config multiple levels deep, tracking side-effects someone made in some constructor trying to DRY out the code. We already have these issues in the…

> It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it.

Counterpoint: 95% of config-readers are or could be checked in with all the config they ever read.

I have yet to come across a programming language where it is easier to read + parse + type/structure validate a json/whatever file than it is to import a thing. Imports are also /much/ less fragile to e.g. the current working directory. And you get autocomplete! As for checks, you can use unit tests. And types, if you've got them.

I try to frame these guys as "data values" rather than configuration though. People tend to have less funny ideas about making their data 'clean'.

The only time where JSON.parse is actually easier is when you can't use a normal import. This boils down to when users write the data and have practical barriers to checking in to your source code. IME such cases are rare, and most are bad UX.

> Side effects in constructors

Putting such things in configuration files will not save you from people DRYing out the config files indirectly with effectful config processing logic. I recently spent the better part of a month ripping out one such chimera because changing the data model was intractable.

Re: Abstraction, not syntax

#56

Post by dapperdrake »

A "universal language" is a language with (a) sequences of instructions, (b) conditionals, ifs, branches, and (c) loops, repetition, iteration, y-combinator (the math one), recursion.

They are Turing complete. Leaving off any of the three features (difficult for the y-combinator) yields a non-Turing complete language, for example Sieve Script for filtering email lacks (c).

What the definition doesn’t cover is parameterization. Some people call this abstraction. Technically, lisp macros also fall under parameterization.

With parameterization it really seems like any and all functions, mappings, and operators that fail to be injective and composable are counter-productive in practice. The math term is "generative effects".

There seems to be this continuous contention between one side that wants its configuration files to basically be CSV and another side that, effectively, wants a full-blown programming language as their "configuration language".

Both sides have a point. Just happen to land in the "essentially CSV" camp myself. Even a lisp macro can generate CSV.

(Yes the phrase "universal language" is very difficult to search for if the specific academic term above is under consideration.)

Re: Abstraction, not syntax

#57

Post by dapperdrake »

apalmer wrote: post #7

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

The "abstraction angle" seems to be a different encoding for "power of configuration language."

Re: Abstraction, not syntax

#58

Post by qezz »

nickelpro wrote: post #18

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.

Luckily, the main point of the article is that syntax doesn't matter, but abstractions do. In other words, you can use your favorite DSL, that being Python or TCL or something else.

Re: Abstraction, not syntax

#59

Post by Twey »

When Kubernetes exposed its APIs as declarative configuration objects, I get the impression that they didn't originally mean for people to write the configuration by hand. The YAML/JSON/… is a conveniently universal interchange format for interfacing with Kubernetes from bindings, and representing target state as documents is just a good way to encode idempotence in the API.

I'd be interested to hear from someone involved with early Borg/K8s development what the original intention was.

Re: Abstraction, not syntax

#60

Post by qezz »

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…

> And guess what? They hate the HCL too.

Don't want to sound too harsh, but to me HCL is even worse than plain YAML.

By expressiveness, HCL is somewhat similar to Ansible-flavoured YAML - in both you need to use magic keywords to create any kind of abstraction (e.g. a loop).

HCL is worse than regular YAML because there's only one "true" parser for it, that is official Hashicorp's HCL parser. So if you are locked into Golang ecosystem, then sure it can work for you, otherwise you are out of luck.

There are a couple of tools that convert HCL into JSON, I tried both, they somewhat work, but in the end of the day it's a big hack. At that point I just gave up on using HCL and started using something else that generates JSON.

Hope you find some configuration layer that fits your users more than HCL or YAML.

Post reply on HN