71–80 of 181 posts
So far, only comments complaining about syntax. You can do better, HN!
Yeah, because that's what most configuration languages differ in.
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…
There are already kubernetes bindings available https://github.com/dhall-lang/dhall-kubernetes .
The syntax in the examples looks a bit more verbose and less readable than yaml but I think building sensible abstractions on top of it will alleviate the pain (abstractions here are innocuous since you can 'normalize' the code and they disappear)
I'm not too happy with the default formatting though. I think if the formatter indented nested values similar to yaml that would look better to the human eye.
Earlier quoted context omitted.
It's not even in the same solution space. I can't replace my YAML with Dhall and consume it directly. I have to now depend on the converter to go from Dhall -> YAML/JSON. All I did was add another layer of complexity into my config. Maybe you'll benefit from the added abstraction; I see the value in having "typed" configs that are semi-scriptable but not turing complete. But it's in no way a "replacement".
> All I did was add another layer of complexity If that was in fact all you had done, it would not be worth it. But it might remove a ton of boilerplate from your YAML.
I mean what's the role of configuration? is so that installer can tune or match environments. if configuration becomes as hard as your program to understand then installation won't ever scale
Earlier quoted context omitted.
And yet, in focusing on the syntax, you missed the biggest difference between Dhall and other configuration languages: safe, termination-guaranteed non-Turing-complete computation.
How is it better than Jsonnet or Starlark?
Hmm... So the authors claim that their language is guaranteed to terminate for all well-typed programs. That is actually a nice spot for configuration languages. Yet, I wonder how a) they guarantee it, as I have seen no obvious link to the language's semantics b) useful this is in practice. Nevertheless, very nice approach, indeed.
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…
Earlier quoted context omitted.
Dhall heavily borrows both ideas and syntax from the ML family of languages. E.g. Haskell, OCaml, Elm, Purescript Colons are used for type signatures. Commas are presumably required because you can have multi line and nested records. (don't quote me on this, not a parser expert) The comment syntax is from Haskell. Not saying this syntax is familiar to everyone , but it is familiar to some. The lineage of the syntax m…
Weird that it's billed as an alternative to YAML, but effectively has zero roots or influence from YAML. Looks more like an alternative to... whatever configuration language is popular in ML language projects?
What you're left with is YAML's core expressiveness, which is that within a text file you can express the basic structures of maps, sequences, some atoms and user-typed [1] nodes.
YAML also has some limited facilities for avoiding repetition, such as aliases and anchors[2]. And a YAML parser can use tags to simulate functions[3].
Dhall is preserving all those capabilities, and then adds real functions and type declarations to further expand the ability to avoid repetition and to avoid mistakes. It's also using a proper type system rather than basically returning a parse tree back.
And whereas these advanced features in YAML are rarely useful because the parser has to go out of its way to support them, it seems like Dhall may be able to make them work properly. So I'd say seeing another project attempt something and then trying to do it right is definitely being influenced by it.
[1]: https://yaml.org/spec/1.2/spec.html#id2761292 [2]: https://yaml.org/spec/1.2/spec.html#id2786196 [3]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
Earlier quoted context omitted.
Yeah, but how is this relevant? YAML, for example, makes JSON a subset, which lets it consume existing JSON without any need for conversion. It's easy to learn, and readable. Leading commas are eyesores. Plus, not everybody is a fan of ML! These are not mass market languages.
Not everybody’s a fan of C++, yet still... YAML has its detractors and many of the criticisms against it are valid. It’s ambiguous and confusing and deeply nested significant white space, with odd indentation rules and optional syntax, is incredibly hard to follow as a human.
Given some YAML file, making any kind of automated change generally nukes the formatting entirely, let alone the comments. I'm sure there are some libraries that do it right, but there seem to be far more that are just awful.
One nice thing about Dhall is that there's a reference implementation written in Haskell where they have very good pretty printing libraries so it's likely that programs would be able to do automated updates to configuration.
Earlier quoted context omitted.
Seems like you're criticizing it just because it's different from what you're used to.
> Seems like you're criticizing it just because it's different from what you're used to. This is a valid criticism. There are already widely-used data formats; if you do something different it should be justified.
But in any case Dhall does actually follow a norm rather closely, just a different norm than the grandparent is used to. Namely, ML and other functional languages/research. Which makes sense since Dhall is a product of that community.