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

Why are we templating YAML? (2019)

leebriggs.co.uk

Post reply on HN
Print view View original

541–550 of 667 posts

Re: Why are we templating YAML? (2019)

#541

Post by kadoban »

wkat4242 wrote: post #453
da39a3ee wrote: post #297

Earlier quoted context omitted.

Your problem, and I mean this sincerely and respectfully, is that you're not using your text editor / IDE correctly. Adding two or four spaces of indentation is done by pressing TAB! Once. Most editors will do know how to do this out of the box, but if yours doesn't you need to change it.

You still have to mess around with a bunch of spaces when you're editing or copy/pasting, and not having exact even numbers makes for ambiguous situations. Especially if something is 5 levels deep, it's really hard to see if you have 12 or 11 spaces (so 5 levels + 1 space or 6 levels) indentation.

This is not true in a correctly configured editor.

Re: Why are we templating YAML? (2019)

#542

Post by treflop »

bilalq wrote: post #536
treflop wrote: post #470

Earlier quoted context omitted.

If configs had well-adopted schema support, it wouldn't be so bad.

Even then, it gets messy. From a tooling standpoint, how will I load your schema? How will my editor respect it? How do I run a validator against it? I know XML kind of solves some of these problems, but it has its own thorns and despite what anyone says, it is not easy to work with. XSD, XSLT, etc. So much complexity that needs to be managed in a different way in every runtime. And then type safety goes out at the b…

That's how it used to be for your suggestion too.

We're living in a dream state now where the creators of IDEs like Visual Studio (Code) or IntelliJ actively implement common languages and frameworks. It used to be 'find a half-baked community plugin so JSON works.'

If someone made a standard schema and people used it, I can assure you the magic you are expecting from your tooling would suddenly pop in just like how JSON support appeared one day. But they can't do nothin' if there is no community support for it.

XSD and XSLT are complicated because XML is complicated.

Re: Why are we templating YAML? (2019)

#543

Post by PH95VuimJjqBqy »

Dylan16807 wrote: post #517
PH95VuimJjqBqy wrote: post #510

Earlier quoted context omitted.

right, it's awkward, so don't do that, be functional instead. jquery vs mootools/scriptaculous/etc. jquery won for a reason, it's just flat out a better experience in terms of code specifically because it uses a functional approach in its api rather than an OOP approach.

> right, it's awkward, so don't do that, be functional instead. I feel like you're just saying that because you like functional code. I'm sure that when they've added syntax to make certain functional things easier to type, you didn't respond "it's awkward, so don't do that, write it in an entirely different way instead". Regardless of what is "better", which tends to differ based on situation, there was no need for…

implicit in my responses is an assumption that you've worked extensively with jquery so you understand the syntax and how it's functional.

If you don't the only response I can have is to go learn it.

This isn't about functional being better, it's about functional being more fluid to use in javascript.

Re: Why are we templating YAML? (2019)

#545

Post by oever »

unshavedyak wrote: post #432
zamalek wrote: post #378

Earlier quoted context omitted.

The problem goes deeper. I can't remember who coined the term, but all "implerative" (imperative declarative) languages share the same issue. I don't care if it's JSON, XML, TOML, or YAML, we shouldn't be interpreting markup/data languages. GitHub actions are a good example of everything wrong with implerative languages. Use a real programming language, you can always read in JSON/YAML/whatever as configuration. Goog…

Oh man, i have a similar issue with NixLang. Though i know it's not "implarative". Many days i just want to write Nix in my preferred language. I wish Nix had made a simple JSON based IO for configuration, because then i could see what the output of something is - and generate the input state from some other language. Really frustrating. Nix works.. but i just don't see the value, personally. And this is after living…

I see Nix as a powerful way to write config files. It is purely functional, so the only thing it does is create a build recipe. That build recipe is then run by other Nix tooling.

A .nix file is either a config file itself or a function that returns a config file or a function. By passing in enough parameters, you get the configuration. I've not seen as clean a way of doing this anywhere else. Guix uses Guile which is a full programming language and can probably have side effects. They use something called G-Expressions which is not quite clear to me.

Re: Why are we templating YAML? (2019)

#546

Post by oever »

anon291 wrote: post #514
lamontcg wrote: post #488

Earlier quoted context omitted.

> I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. The problem is language nerds write languages for other language nerds. They all want it to be whatever the current sexiness is in language design and want it to be self-hosting and be able to write fast multithreaded webservers in it and then it becomes conceptually com…

I mean... Nix satisfies every single one of what you mentioned and people say its too complicated. It's literally just the JSON data structure with lambdas, which really is basic knowledge for any computer scientist, and yet people complain about it. It's fairly straightforward to 'embed' and as a bonus it generates json anyway (you can use the Nix command line to generate JSON). Me personally, I use it as my templat…

I agree with the point's in Nix's favor except for 2. dynamically typed. Defining structs as part of the language would be nice. In fact, type checking is done ad-hoc now by passing data through type checking functions.

Re: Why are we templating YAML? (2019)

#547

Post by PH95VuimJjqBqy »

smaudet wrote: post #522
PH95VuimJjqBqy wrote: post #500

Earlier quoted context omitted.

you cut off the part of my statement that answers your question > if you can get away with not needing a full-blown turing complete language then convention based ini files are vastly easier on the human than yaml or json. My claim isn't that ini files solve for every use case, it's that if your needs are simple enough ini files are superior to json/yaml, but that full-blown turing complete languages are superior to…

> you don't have a configuration format but a serialization format While I better appreciate what you are saying now (you don't have a solution), the only appreciable difference between "config" and "serialization" is that of write frequency - config is seldom updated, serialization is often updated. Otherwise, they are the same problem with the same solution - you might provision resources differently based upon "dy…

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 data exchange is exactly the same, and indeed Claude Shannon showed all information is just data, but that misses the point entirely. All humans are exactly the same and yet sex between them can look vastly different based upon such details as genitals.

Re: Why are we templating YAML? (2019)

#548

Post by int_19h »

p10_user wrote: post #532
hintymad wrote: post #511

Earlier quoted context omitted.

An often-heard benefit for using YAML is that JSON does not have comment. What I don't understand is why we would switch to a whole new language. Just add a filter before loading the configuration, which can't be harder than switching to YAML, right? Another reason for YAML is that it is easier to read. That I don't understand either. The endless pain of dealing with configuration does seem come from saving a few sec…

Just make another named list key called "comment". Problem solved.

This is not always an option when JSON is propagated as is, nor does it allow for comments on specific object properties.

Re: Why are we templating YAML? (2019)

#549

Post by int_19h »

hintymad wrote: post #511
bilalq wrote: 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…

An often-heard benefit for using YAML is that JSON does not have comment. What I don't understand is why we would switch to a whole new language. Just add a filter before loading the configuration, which can't be harder than switching to YAML, right? Another reason for YAML is that it is easier to read. That I don't understand either. The endless pain of dealing with configuration does seem come from saving a few sec…

https://json5.org/

Re: Why are we templating YAML? (2019)

#550

Post by int_19h »

lamontcg wrote: post #488
Draiken wrote: post #72

I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. If you need complex logic, use a programming language and generate the YAML/JSON/whatever with it. There you go. Fixed it for you. Ruby, Python, or any other language really (I only favor scripting ones because they're generally easier to run), will give you all of that wi…

> I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. The problem is language nerds write languages for other language nerds. They all want it to be whatever the current sexiness is in language design and want it to be self-hosting and be able to write fast multithreaded webservers in it and then it becomes conceptually com…

> What we need is like a "Logo" for systems engineers / devops which is a simple toy language that can be described entirely in a book the size of the original K&R C book.

I would argue that Tcl is exactly that. It's hard to make things any simpler than "everything is a string, and then you get a bunch of commands to treat strings as code or data". The entire language definition boils down to 12 simple rules ("dodekalogue"); everything else is just commands from the standard library. Simple Tcl code looks pretty much exactly like a typical (pre-XML, pre-JSON, pre-YAML) config file, and then you have conditionals, loops, variables etc added seamlessly on top of that, all described in very simple terms.

Post reply on HN