Live data from Hacker News

Abstraction, not syntax

ruudvanasseldonk.com

31–40 of 67 posts

Re: Abstraction, not syntax

#31
To me the solution seems like it's adding complexity that could cause more issues further down the line.

The specific problems in the example could be solved by changing how the data is represented. Consider the following alternative representation, written in edn:

    {:aws.s3/buckets
     {:aws.region/eu-west
      {:alpha-hourly  {:lifecycle/policy {:delete-after #interval/days 4}}
       :alpha-daily   {:lifecycle/policy {:delete-after #interval/days 30}}
       :alpha-monthly {:lifecycle/policy {:delete-after #interval/days 365}}

       :bravo-hourly  {:lifecycle/policy {:delete-after #interval/days 4}}
       :bravo-daily   {:lifecycle/policy {:delete-after #interval/days 30}}
       :bravo-monthly {:lifecycle/policy {:delete-after #interval/days 365}}}}}
This prevents issues where the region is mistyped for a single bucket, makes the interval more readable by using a custom tag, and as a bonus prevents duplicate bucket names via the use of a map.

Obviously this doesn't prevent all errors, but it does prevent the specific errors that the RCL example solves, all without introducing a Turing-complete language.

Re: Abstraction, not syntax

#32
the answer seems to be both of both worlds - if you're going to do for loops why not just use python?

the answer is both a faux programming language, and really bad ux / really hard to read / scan

maybe what they need is a program that generates better readable text; and somehow you can flip between the determinism of code and ux of readable text?!

(is that possible)

Re: Abstraction, not syntax

#33
FOR loops?

YAML has a merge key The merge key is a clever little trick, but it depends of the special hash key, so lists can’t be merged.

Syntax does matter, which is why YAML matters — even if imperfect.

Re: Abstraction, not syntax

#34
The intention behind configuration languages is sound but there’s just too many of them. Not having a universally accepted one makes picking one harder. Also, migrating from one to another isn’t as straightforward. Plus,

    for database in ["alpha", "bravo"]:
        for period, days in period_retention_days:

At this point, you’re better off writing a Python script that spits out some JSON. I‘m aware that even the blog mentions it. The benefit is - having a more expressive language at your fingertips and not having to fight your peers while trying to add yet another idiosyncratic dependency.

Re: Abstraction, not syntax

#35

To me the solution seems like it's adding complexity that could cause more issues further down the line. The specific problems in the example could be solved by changing how the data is represented. Consider the following alternative representation, written in edn: {:aws.s3/buckets {:aws.region/eu-west {:alpha-hourly {:lifecycle/policy {:delete-after #interval/days 4}} :alpha-daily {:lifecycle/policy {:delete-after #…

> The specific problems in the example could be solved by changing how the data is represented.

Finding the "right" representation for a given set of data is an interesting problem, but most (all) of the time the representation is specified by someone/something else.

In the past I've written a [preprocessor][1] that adds some power to the representation while avoiding general purpose computation. For example,

    (buckets
      (let ([(regional region (name policy) ...)
             ((['name name] ['region region] ['lifecycle_policy policy]) ...)])
        (regional us-west
          (alpha-hourly (delete_after_seconds 345600))
          (alpha-daily (delete_after_seconds 2592000))
          (alpha-monthly (delete_after_seconds 31536000))
          (bravo-hourly (delete_after_seconds 345600))
          (bravo-daily (delete_after_seconds 259200))
          (bravo-monthly (delete_after_seconds 31536000)))))
Macros, basically. Arithmetic would help there, but that might be too much.

[1]: https://github.com/dgoffredo/llama

Re: Abstraction, not syntax

#36
post #30

The problem with configuration formats, is not syntax, or abstraction, it's the lack of consistent language server integration, it's problem when I can't lookup the definition for a key, the expected type, or quickly jump to definitions that clearly show which keys are available to configure.

To be frank, the clear problem with configuration format is that people have configurations so complex they probably should use something else. Example: We are programming a backend for a blog. If we were to not use templates, but instead try to get that functionality via the webservice configuration we would have to "invent" some format that gives us the flexibility of templates within let's say a YAML file. Needles…

Two examples of complex user facing configurations I can think of are pretty trivial to implement:

- Decision tree, where you only need comparison operators. The leaves are a specified list of actions.

- actions list with macros (variables). You can be fancy and add some conventions for arrays.

Anything more that that should just be a programming language. And if the relationship is adversarial (saas), you should really think hard about needing something that complex.

Re: Abstraction, not syntax

#37
post #22

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…

I still have to see a JS project where the config for each tool could not be something simple like `.toolrc`. We could have some markers to delineate plugins config.

Instead, there’s a another software in the configuration of sample projects, instead of just using good code organization and sensible conventions.

Re: Abstraction, not syntax

#39
Somewhere along the way we got lost into thinking config files were remote procedure calls, and that YAML was the only RPC interface available to us. The caller generates YAML, the receiver parses it, but more often than not the two are on the same host and use the same language*:

  def say(message):
    o = dict(f=say, v=message))
    call(yaml.dumps(o))
meanwhile elsewhere

  def eval(request):
    o = yaml.loads(request.body)
    match o[“f”]:
      case “say”:
        print(o[“v”])
Yes, referring to this as “madness” skips over the fact that you can now scale up your hello world printer across the internet, have auth, rate limit, etc etc. but for so many things the RPC just isn’t needed at all.

As this article gets at, config files are one of those things, and they benefit hugely from the rampant abstraction violation of skipping an intermediary text format between the program doing the configuration and the program doing the work.

*or have internal versions of their APIs available in matching languages.

Re: Abstraction, not syntax

#40
post #8

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

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

Post reply on HN