1. 5
  1.  

  2. 4

    Far too many package managers.

    If a disease has many treatments, it has no cure.

    I was trying hard to see what advantage the embed JSON-LD in html gave me…. and not finding. I think that is because I’m on Firefox 50… And I think support got removed in 49 (See table at bottom of page… https://developer.mozilla.org/en-US/docs/Web/HTML/Microdata)

    Config items are another disease.

    Config Items are what happens when a Developer says, “This setting, should it be X or Y? I don’t know, I will make it a config item.”

    Bang! He has just increased the dimension of his configuration space, usually for sole reason that “Thinking Hurts, and Thinking Like A User Doubly Hurts”…. and has just massively reduced his test coverage of that space.

    I strongly favour ‘sensible defaults and hide a config items somewhere not visible to a non-source code reading user behind a 'this may break things" warning.’.

    I didn’t need convincing that there are too many config files everywhere….

    ….but you haven’t convinced me that you have a solution to them, or indeed how JSON-LD might be such a thing.

    “Dumb Data Only” configs inevitably give rise to more and more arcane config items until it meets the criteria for Greenspun’s tenth rule.

    A hard immovable insistence on remaining only “dumb data” results in things like Sass and Less to make CSS less dumb.

    The other approach is to swing hard in the opposite direction and declare “your config file is a script” ala use Scheme (guile) or Lua.

    1. 3

      There was also the quite recent post on a rich-but-not-turing-complete config language (dhall was the name, IIRC).

      1. 1

        dhall

        I saw that… sort of interesting for the use case where whoever is writing your config file is possibly intelligent AND possibly actively malicious.

        Another use case would be “hot swap” config on a mission critical app where re-reading the config MUST succeed and Do Good Things.

        Not so good if you are intelligent and writing the config file for yourself, or you are not intelligent( and/or time limited (sort of the same thing)) and just trying to get the damn thing to work.

        1. 1

          re-reading the config MUST succeed and Do Good Things

          How does that work if parsing fails?

          1. 2

            The usual policy is “Keep going on the old config”.

            ie. Once the system “accepts” the config it shifts it somewhere non-writable by the user.

      2. 1

        OP/author here: Great feedback. Will take into consideration. Thanks!

        1. 1

          I’d really like a bit more detail on exactly how you’d use JSON-LD…..

          …I think I glimpse the tail of the idea… but I don’t think I’m seeing / understanding the whole beast.

      3. 2

        For my own build infrastructure software I’ve been trying to make it possible to generate as much as possible from the build definition. I have a TOML file which defines a build and then I can generate package definitions from that. I could probably generate a Dockerfile from that, if I wanted. I only added another config file to express metadata for the package, like URLs where it can be downloaded, so that doesn’t affect the “correctness matrix”, it’s just extra info to dump into the package. So far it works well for me but I have explicitly forsaken features to keep it simple, so YMMV. But all of the source-code for this is like 800 lines of Ocaml (from build system, which generates Makefiles for me, to everything to generate the packages) so it’s not too expensive to rebuild for specific usecases.