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

Dhall: A Non-Repetitive Alternative to YAML

dhall-lang.org

Post reply on HN
Print view View original

91–100 of 181 posts

Re: Dhall: A Non-Repetitive Alternative to YAML

#91

Post by ignaloidas »

codebje wrote: post #72
cryptonector wrote: post #60

If you have functions that can call functions, you'd better not have recursion if you want to not be Turing-complete. Non-Turing-completeness is certainly very important in many cases (e.g., in DTrace and eBPF), but I'm not sure that it's so important for configuration . Assuming for a moment that I don't need non-Turing-completeness for configuration, my choice of DSL would be jq[0]! Using jq for configuration means…

Recursion is fine, as long as an argument gets smaller at every iteration, since that guarantees termination.

Oh, like Ackermann function[0]? Because I wouldn't want my server try to evaluate that.

[0] https://en.wikipedia.org/wiki/Ackermann_function

Re: Dhall: A Non-Repetitive Alternative to YAML

#92

Post by nikolay »

Thorrez wrote: post #77
nikolay wrote: post #6

Dhall keeps popping up on HN. Here what I don't like about it: - Why use '=' instead of ':' for attributes? If you used ':', then '=' could be variable assignment and eliminate the need for 'let'. - Why is there a need for commas? - Why quote via ticks?! Gee! - What's with the '{-' and '-}' for comments?! It's like its author decided to differ at any price ! In general, good ideas, but it's too weird and unnecessaril…

None of the examples show quoting via ticks, that seems to be a pretty obscure feature.

Actually, at least one does and for the wrong reason (an attribute named True, for example, needs to be quoted):

  { -- Unlike YAML, Dhall does not accept YES|NO|ON|OFF
    validDhallBools = [ True, False ]
      , someNumbers = [ 1
    ,
  -- Dhall is not indentation-sensitive
  2, 3 ]
    -- Field names that conflict with reserved identifiers must be quoted
  , `True` = True
  , version = "9.3"  {- Strings must be quoted

                        All Dhall literals have unambiguous types -}
  }

Re: Dhall: A Non-Repetitive Alternative to YAML

#93

Post by nine_k »

desc wrote: post #84

Programmable configuration is always and without exception a monumentally stupid idea. Programmatic generation of static configuration files can be very useful. Sufficiently complex examples of the latter might as well be the former as far as maintenance is concerned. If you need to write a program to configure your program, you're probably doing it wrong.

Configs allow to add flexibility past compile time, often dynamically at runtime.

Re: Dhall: A Non-Repetitive Alternative to YAML

#94

Post by GordonS »

nikolay wrote: post #55
mcaruso wrote: post #43

Earlier quoted context omitted.

Seems like you're criticizing it just because it's different from what you're used to.

Yeah, it deviates from the norm and the expectations of most people, most of who are not even developers - lots of BAs today configure apps via such files.

Sorry, "BAs"?

Re: Dhall: A Non-Repetitive Alternative to YAML

#95

Post by GordonS »

andybak wrote: post #10

Immediate response? I hate commas at the start of lines and I would prefer not to have curly braces in a human editable/readable format. Neither reason is terribly rational but my first impressions weren't great.

I get that this makes diffs a tiny bit nicer when adding new lines, if you don't use trailing commas, but christ it's ugly!

Re: Dhall: A Non-Repetitive Alternative to YAML

#96

Post by desc »

nine_k wrote: post #93
desc wrote: post #84

Programmable configuration is always and without exception a monumentally stupid idea. Programmatic generation of static configuration files can be very useful. Sufficiently complex examples of the latter might as well be the former as far as maintenance is concerned. If you need to write a program to configure your program, you're probably doing it wrong.

Configs allow to add flexibility past compile time, often dynamically at runtime.

Yes, that's the problem. I'd like to be able to look at a config file, on disk, loaded at startup, which defines the initial state of the server without having to think through how it was evaluated.

Generating the config during deployment, eh... often necessary. Best done with transforms and templates because they're simple.

Executable config, run during startup or, worse, on each request? NO.

[edit] I think that's the main disconnect here: 'past compile time'. The whole point of testing, strong type systems, etc is to lock down the set of states the system can be in. If your configuration is so 'dynamic' you are essentially abandoning all those benefits and saying 'yeah, do what you like to our live servers'.

In short, configuration which is that powerful is indistinguishable from running untested code in production.

Re: Dhall: A Non-Repetitive Alternative to YAML

#98

Post by GordonS »

isoprophlex wrote: post #13

To me, worrying about config files seems like the ultimate exercise in bikeshedding. You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever. Or you need templating, the use of functions, etc, like dhall provides. But then, why not use the language you're already using for the rest of your project, or a bash script to export some variables? Might sound…

I kind of agree, to a point (e.g. Erlang config is, usually, a complete shitshow).

I wonder if JSON had allowed for comments if we'd see such a proliferation of config system? At least IME, that seems to be the biggest pain point with JSON.

Re: Dhall: A Non-Repetitive Alternative to YAML

#99

Post by jose_zap »

desc wrote: post #96
nine_k wrote: post #93

Earlier quoted context omitted.

Configs allow to add flexibility past compile time, often dynamically at runtime.

Yes, that's the problem. I'd like to be able to look at a config file, on disk, loaded at startup, which defines the initial state of the server without having to think through how it was evaluated. Generating the config during deployment, eh... often necessary. Best done with transforms and templates because they're simple. Executable config, run during startup or, worse, on each request? NO. [edit] I think that's t…

Dhall give you exactly that, since you can store the normalised version of any configuration. Or inspect it at will by running it.
Post reply on HN