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

141–150 of 181 posts

Re: Dhall: A Non-Repetitive Alternative to YAML

#141

Post by dragonwriter »

markandrewj wrote: post #86

My comment isn't specifically about Dhall, but about the note on Turing completeness. I often read comments about how YAML/JSON is not turning complete. These comments normally frame the lack of Turing completeness as being a short coming of the format(s). I find this interesting because one the reasons that the industry moved away from XML was to have cleaner separation between data and logic. I generally tend to th…

> I find this interesting because one the reasons that the industry moved away from XML was to have cleaner separation between data and logic.

That's not really true or even sensible, since XML doesn't combine data and logic. Sure, there were XML-based logic languages (most notably XSLT) as well as XML-based data languages, but while all were applications of XML they were separate languages.

XML lost ground to JSON, etc., as the fashion pendulum swung away from heavyweight tooling and detailed specs for most things (though it's swinging back again), and to some closer-to-memory-layout binary formats as efficiency became a concern in some of the places where rigid specs remained important.

Re: Dhall: A Non-Repetitive Alternative to YAML

#142

Post by jose_zap »

comex wrote: post #138
nine_k wrote: post #88

Earlier quoted context omitted.

Not being Turing-complete is a feature. A Turing-complete language allows to write programs that never terminate. This is not what a config file should be capable of.

Of all the bugs you've ever dealt with in programs in general, what fraction of them of them were infinite loops? For me I'd guess maybe... 0.1%? It's definitely under 1%. Given that, it makes no sense to me that I'd want to make myself jump through hoops to express some basic coding patterns [1], just to rule out that single class of bugs. It seems like a solution in search of a problem. [1] https://github.com/dhall…

I think the Non-Turing completeness is misunderstood as "no infinite loops!". Of course, that's the obvious effect of not having it, but it has more important effects:

1. Any expression can be normalised at compile time. This means that you can remove all abstractions in your code and audit the result before running it. This is great of debugging and understanding a codebase you may not be familiar with.

2. You can be sure that the language cannot do a jailbreak and potentially read files or make network calls it was not supposed to. Not because the Dhall developers are security geniuses but because it is literally impossible without Turing completeness.

An example of a NT complete language that you would hate if it could read a file in your system and send it to attackers is Regular Expressions, for example.

3. It helps the language stay focused. This limitation is the biggest motivator to keep the language being focused on a single domain, and not try to be everything. This also helps execution performance of the language.

Re: Dhall: A Non-Repetitive Alternative to YAML

#144

Post by jholman »

jose_zap wrote: post #142
comex wrote: post #138

Earlier quoted context omitted.

Of all the bugs you've ever dealt with in programs in general, what fraction of them of them were infinite loops? For me I'd guess maybe... 0.1%? It's definitely under 1%. Given that, it makes no sense to me that I'd want to make myself jump through hoops to express some basic coding patterns [1], just to rule out that single class of bugs. It seems like a solution in search of a problem. [1] https://github.com/dhall…

I think the Non-Turing completeness is misunderstood as "no infinite loops!". Of course, that's the obvious effect of not having it, but it has more important effects: 1. Any expression can be normalised at compile time. This means that you can remove all abstractions in your code and audit the result before running it. This is great of debugging and understanding a codebase you may not be familiar with. 2. You can b…

I feel like you've made in "inverse error" here repeatedly.

If a language L1 is Turing complete then you have some potential liabilities: there's no general normalization plan, you cannot in general ensure security guarantees, etc. But another language, L2, might be not-Turing-complete and still have all the same problems. It may especially be the case that L2 has no known normalization algorithm, or no known general security audit.

For example, many interesting properties are undecidable for the general case of context-free languages (a class that I'm sure you know is much more restricted than the class for Turing-complete languages). For example universality is undecidable in this class, as is language equivalence. As for being sure that the language cannot do a jailbreak, you can't be sure until you write a proof. It's nice that Godel isn't telling you that no such proof can possibly be written, but that's still a long way from having a proof.

I agree with you that this sort of thinking seems to be why people say that they do not want certain languages to be Turing-complete, but I'm not at all convinced that those people have correctly named the property that they want.

Re: Dhall: A Non-Repetitive Alternative to YAML

#145

Post by jholman »

Fnoord wrote: post #123
dharmab wrote: post #109

Earlier quoted context omitted.

We tried to introduce Jsonnet at our org. It failed miserably because ops kept mistaking the name for JSON which they hated. (International multilingual team). It was a real shame because ops then implemented some features of Jsonnet via scripts to to parse and merge YAML. What was 0 LOC in Jsonnet is now about 300 LOC plus custom CI checkers, all because of a marketing problem.

If I go to the mentioned Jsonnet homepage it says "A simple extension of JSON". The graphic explains its relation to JSON. The example looks awfully similar to JSON. What I don't understand is the following: config files are read by text editors, and in the end, by human beings. Because of the latter they should have certain traits. We must agree on the importance of these traits before we can settle on a standard. F…

I'm a little confused by one part of what you wrote. You say that your config files must be readable by vi, and that in turn adds a no-highlighting-required constraint and a no-schema-required constraint, and that in turn adds a no-JSON-nor-anything-like-it constraint.

I deal with JSON all the time in vim, effortlessly. I'd be willing to deal with it in Notepad if necessary, and certainly in non-vim vi. Pipe it through a prettifier (lately I use `jq . file.json`) if necessary.

I don't need syntax highlighting, and I don't need a formalized schema (although I certainly appreciate an informal one, interpreted by the 1.0 Human Meatbrain I carry around). Also, if by "vi" you meant "vim", this is EVEN MORE confusing, because vim syntax-highlights JSON.

Re: Dhall: A Non-Repetitive Alternative to YAML

#146

Post by Fnoord »

jholman wrote: post #145
Fnoord wrote: post #123

Earlier quoted context omitted.

If I go to the mentioned Jsonnet homepage it says "A simple extension of JSON". The graphic explains its relation to JSON. The example looks awfully similar to JSON. What I don't understand is the following: config files are read by text editors, and in the end, by human beings. Because of the latter they should have certain traits. We must agree on the importance of these traits before we can settle on a standard. F…

I'm a little confused by one part of what you wrote. You say that your config files must be readable by vi, and that in turn adds a no-highlighting-required constraint and a no-schema-required constraint, and that in turn adds a no-JSON-nor-anything-like-it constraint. I deal with JSON all the time in vim, effortlessly. I'd be willing to deal with it in Notepad if necessary, and certainly in non-vim vi. Pipe it throu…

With vi I mean vi, not vim. If I meant vim, I'd have written vim. I use vim if its available (with my own configuration which includes syntax highlighting), but it isn't always available.

With my Human Meatbrain syntax highlighter I have far more issues with JSON than with say YAML or any other markup language.

Consider, for example, how easy the syntax is of a Wireguard configuration file. It is basically akin to a shell script or ini configuration file. And these have a proven track record. Why is that way of configuration broken in the first place? You could do things such as variables in shell scripts as well.

I also believe that the whole Systemd drama is basically because of moving away from such a proven track record. And it might very well be true that shell scripts are slow. That is why I argue for backwards compatibility and converting to/from formats. Which is something Dhall is able to (it can convert to/from YAML and JSON).

Re: Dhall: A Non-Repetitive Alternative to YAML

#147

Post by jose_zap »

nikolay wrote: post #143
mbrock wrote: post #127

Earlier quoted context omitted.

static type system

True. But isn't this also accomplished when pairing JSON with JSON Schema?

The schema applies to the generated values, but what’s the equivalent of a schema for a programming language? Types.

Jsonnet does not have a way to validate its functions without running them first.

Re: Dhall: A Non-Repetitive Alternative to YAML

#148

Post by nikolay »

jose_zap wrote: post #147
nikolay wrote: post #143

Earlier quoted context omitted.

True. But isn't this also accomplished when pairing JSON with JSON Schema?

The schema applies to the generated values, but what’s the equivalent of a schema for a programming language? Types. Jsonnet does not have a way to validate its functions without running them first.

I clearly get that, but many IDEs use the schema to help you produce valid JSON.

Re: Dhall: A Non-Repetitive Alternative to YAML

#149

Post by tedmiston »

jrudolph wrote: post #124

Dhall is an awesome tool to have in your DevOps tool belt - we're heavy dhall users at meshcloud [0] and couldn't be happier about it. We picked it after evaluating a long list of contenders (yaml madness with anchors, jsonnet, ksonnet, j2/jinja, a hacked ejs compiler [1] and some more I forgot). It's so good we're looking into how we can give back/donate to the project. Dhall elegantly solves a major challenge: conf…

Heads up - Your naked subdomain redirect to www doesn't seem to be working. If I go to www directly, I don't get the timeout.

Re: Dhall: A Non-Repetitive Alternative to YAML

#150

Post by anentropic »

Jeff_Brown wrote: post #46
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.

> commas at the start of lines are not a requirement.

OTOH I would guess it doesn't allow a trailing comma (same problem as JSON...) so you end up with weird ugly formatting conventions
Post reply on HN