Live data from Hacker News

Why are we templating YAML? (2019)

leebriggs.co.uk

611–620 of 667 posts

Re: Why are we templating YAML? (2019)

#611
post #372

Earlier quoted context omitted.

That's fine, you can pick whatever XML ugliness you like, I was just pointing out that you can't solve the basic fail of JSON with comments by making them data

> I was just pointing out that you can't No, you were pointing out that some people won't like that solution. Which is completely fine. And yes, that solution is ugly as hell, and it is a dirty hack, and I don't recommend actually doing that if there is a better way (like TOML). But it does work. https://www.youtube.com/watch?v=C5kGCwJ25Yc

> ugly as hell, and it is a dirty hack, and I don't recommend actually doing that

you're just paraphrasing the obvious - it's not a solution. And YAML is a better way and addresses the problem you choose to ignore as such - ugliness.

Re: Why are we templating YAML? (2019)

#612

Earlier quoted context omitted.

> I don’t understand why people are still using it It's a good comaparator, there are indeed a lot of similarities, but I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. It's more like Python than Coffeescript really: it's not just about simplicity & brevity, it's about terminators. Whitespace-dependent languages are often a pain to format / p…

>by being extremely strict about indentation, both in terms of the parser & also community convention. YAML hasn't This is why I created StrictYAML. A lot of the pain of changing YAML goes away if you strictly type it with a schema but you keep the readability. Counterintuitively that also includes most indentation errors - it's much easier to zero in on the problem if the error was "expecting status code or content…

StrictYAML is a great initiative. On the other side of the fence I also love JSON5, for opposite reasons - it's essentially "UnstrictJSON".

JSON5 has achieved a reasonably high level of adoption (though I think it's plateaued & I don't see it ever becoming the standard way people do JSON). Would be great to at least see StrictYAML hit a similar level of adoption though - the network effect is so hard to overcome.

Re: Why are we templating YAML? (2019)

#613

Earlier quoted context omitted.

However they want to. One may write a single value containing a CSV, another may use a convention of namespaced keys, whatever. One may base64, one may urlencode, whatever. The differences don't change the fact that they will all have the same things in common. Even without a formal spec, we all know what we are free to change and not free to change, and free to assume and not free to assume. The unwritten spec speci…

My point is indeed that it is not meaningful to speak of the INI culture as something directly comparable to a standardised format. > One may write a single value containing a CSV, another may use a convention of namespaced keys, whatever. One may base64, one may urlencode, whatever. > The differences don't change the fact that they will all have the same things in common. I think this is the first time I've seen thi…

That's all any communication is, is two or more parties using symbols who's meanings a majority agrees on. It does not require a dictionary.

I refer back to the simple fact that the original commenter felt it reasonable to speak the words, believing that others had the same idea what the words meant as they themselves did, and to the fact that I and others did in fact have that same understanding. That means it is utterly silly to be trying to say that the term has no meaning. Does everyone else have telepathy and only poor you are left out of the club? It's even silly to claim that merely you individually just don't know what the term meant, if you would claim to work in any remotely IT related field.

It basically looks like an attempt to look smart backfiring badly.

The reason the things the term doesn't define don't matter is the same reason as for all other terms or symbols. No term is a complete description of anything. It defines what it defines and does not define anything else.

When you say "XML", you still have not said an infinity of things. XML merely defines more than INI. INI defines a certain structure, and you are free to do whatever you want within that structure, exactly like XML and all other formats & protocols.

If they defined everything, then they wouldn't be general purpose frameworks for packaging data, they would be snapshots of specific particular data. In fact they would not even be snapshots but one specific physical instance taking one specific form as it exist in one place at one time somewhere.

There is no way you don't already know all of this, I absolutely credit you with having this much understanding of how symbols work, which makes your argument disingenuous.

If you didn't and your argument was sincere, then you are embarrassingly illiterate for trying to partake in a conversation in this area. Not a crime to be that ignorant, and if so then I apologize for ridiculing a 6 year old who somehow found their way onto HN, but consider yourself now better informed than you were. That a ratified rfc or iso for INI, or any other term, is not required for a term to be valid communication. All that's required is for speaker and listener to both understand it, and such definitions are merely one of many ways for a term to have meaning and for all involved parties to have that mutual understanding.

Wait, I suppose I have to explain what rfc and iso and ieee all mean in this context. Anyone who did not know what .ini meant surely can not recognize any of those either.

Re: Why are we templating YAML? (2019)

#614
post #404

I'm completely done with configs written in YAML. Easily the worst part of Github Actions, even worse than the reliability. When I see some cool tool require a YAML file for config, I immediately get hit with a wave of apprehension. These same feelings extend to other proprietary config languages like HCL for Terraform, ASL for AWS Step Functions, etc. It's fine that you want a declarative API, but let me generate my…

At this point, I even prefer plain JSON to YAML. What pushed me over the edge is that "deno fmt" comes with a JSON formatter, but not a YAML formatter. It's a single binary that runs in milliseconds. For YAML auto-formatting you basically have to use Prettier, and Prettier depends on half of NPM and takes a good 2 seconds to startup and run. So, I literally moved every YAML file in our repository at work that could b…

AFAIK Prettier has 0 dependencies and runs fast enough that triggering formatting on save wasn't ever noticeable (granted I've never tried it with YAML specifically). Curious what kind of setup you had to push it to 2 seconds - maybe bulk formatting in CI for whole repository?

Re: Why are we templating YAML? (2019)

#615
I'm no fan of YAML but for an example of templating YAML that is tolerable, take a look at esphome[1] (and I suppose also home assistant).

In your main yaml file you have something like this:

  packages:
    left_garage_door: !include
      file: garage-door.yaml
      vars:
        door_name: Left
        door_location: left
        open_switch_gpio: 25
        close_switch_gpio: 26
Then in garage-door.yaml you can reference the vars directly with ${door_name} syntax.

It's the best version of templating YAML that I have experienced.

1. https://esphome.io/guides/configuration-types#packages-as-te...

Re: Why are we templating YAML? (2019)

#616

The problem is very specifically the fact that YAML, as a config language, sucks. I have no idea why people started using it. "bUt jSOn dOeSn'T HaVe cOmMenTS" ... oh gimme a break! You want a comment in JSON? { "//": "This is a comment explaining key1.", "key1": "value1", "//": "This is a comment explaining key2.", "key2": "value2" } There. Not so hard. Writing a config parser that just ignores all keys starting with…

[deleted]

Re: Why are we templating YAML? (2019)

#617

Earlier quoted context omitted.

> And adding these slight changes is not trying to "hammer" javascript into being "more typical OOP". this is disingenuous and I'm ending it here. MS spent years trying, and initially failing, to get javascript to work in a more traditionally OOP way. describing that as slight is something else.

I started off with "I'm not sure what you mean" and you have given zero examples. I'm not being disingenuous. Other people can't read your mind. Other people aren't experts on the same things you are. And specifically, I described the class keyword as slight. Don't be an asshole by accusing people of things they're not doing.

do not speak with authority if you do not know.

do not try and downplay something just because you want it to be true.

Re: Why are we templating YAML? (2019)

#618

Earlier quoted context omitted.

ISO-8859-1 is Latin-1, there's nothing specifically "Windows" about it.

You're correct.

You were probably thinking of Windows-1252, which is an extension of ISO-8859-1 that supports more European character sets.

Re: Why are we templating YAML? (2019)

#619

Earlier quoted context omitted.

No, significant whitespace is the problem.

So - you're saying that mixing tabs and spaces in the same file is entirely unproblematic outside of languages with significant whitespace? Are you sure about that?

mixing tabs and spaces just makes code look bad visually. But when whitespace is significant it can change behaviour.

Re: Why are we templating YAML? (2019)

#620

Earlier quoted context omitted.

I'm going to submit that if you think configuration and serialization are the same problem it's time to step back and re-evaluate what you're doing, which is really the authors point. As Joel Spoelsky said years ago, if you abstract far enough up everything starts to look the same but that doesn't make it so https://www.joelonsoftware.com/2008/05/01/architecture-astro... At the end of the day you could claim that all…

> if you think configuration and serialization are the same problem Except that's precisely not the point...rather the formats they are written in are the same, they are indistinguishable. Reductio-ad-absurdum, if all data exchange is the same then there is no benefit to any format, just write binary strings with null-terminal characters. Except for the many downsides to that approach, so it turns out that they are n…

oh look, the internet denizen was able to weave their way through a rationalization, that's certainly never been done before!

What makes it even more absurd is that we do, in fact, have binary serialization protocols and they're very popular especially amongst companies dealing with scale.

https://en.wikipedia.org/wiki/Cap%27n_Proto

> Values in Cap'n Proto messages are represented in binary, as opposed to text encoding used by "human-readable" formats such as JSON or XML. Cap'n Proto tries to make the storage/network protocol appropriate as an in-memory format, so that no translation step is needed when reading data into memory or writing data out of memory.

---

But that's actually the fucking point, serialization only looks the same as configuration if you've gone too high up the abstraction ladder and lost your perspective and that _is_ the point of TFA. At some point you need to stop and ask if what you're doing is really the right approach.

You've destroyed your _own_ point with your long-winded, weaving, rationalization.

and to top it all off, you've strawmanned a point I've clarified already. It makes you look like an asshole. I've never claimed ini works well for complex configuration, I said the opposite in fact.

Post reply on HN