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

641–650 of 667 posts

Re: Why are we templating YAML? (2019)

#641

Post by smaudet »

PH95VuimJjqBqy wrote: post #636
smaudet wrote: post #631

Earlier quoted context omitted.

> oh look, the internet denizen was able to weave their way through a rationalization, that's certainly never been done before! Yes, I gathered a couple replies ago you weren't interested in meaningful discussion...and probably hadn't even read anything I'd said. > You've destroyed your _own_ point What point? I asked you a question. You continually divert and misdirect. Now the only point of contention I have left w…

> And yet you never made a claim about what works well. I certainly did and I also clarified it a second time. I'm not doing it a 3rd time, you can re-read this chain. > Configuration and Serialization are the same thing, at the format layer. CSAM and the text of the bible are the same thing at the storage layer. My cats and I are the same thing at the atom layer. And you say this inane thing unironically. Let me quo…

You provided a nonsensical answer.

And have since insisted on spouting nonsense.

I have nothing further to say on the matter, clearly I'm conversing with a brick.

Re: Why are we templating YAML? (2019)

#642

Post by m463 »

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 wonder if there isn't a place for both:

1. a full-blown language that can generate complex output

2. a declarative static data file

I hope I'm not just pulling my punches with #2

on the other hand, some complexity spirals out of control, especially when people use it without any need. Some great things come out of creating boundaries.

Re: Why are we templating YAML? (2019)

#643

Post by usrbinbash »

eviks wrote: post #611
usrbinbash wrote: post #608

Earlier quoted context omitted.

> 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.

> And YAML is a better way and addresses the problem you choose to ignore

I haven't ignored it, as shown by us discussing it here.

And no, YAML isn't a better way. It does commenting better, true, and at the same time, it does so many things wrong, that are absolutely no problem in JSON, that it becomes a treatment worse than the disease.

Re: Why are we templating YAML? (2019)

#644

Post by gofreddygo »

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…

> let me generate my declaration programatically

this sort of thing looks and sounds like the right thing to do. Till you do it, on a largeish project with multiple teams that have experienced attrition.

I quietly added a layer of yaml generating code to make it bearable.

Re: Why are we templating YAML? (2019)

#645

Post by LorenzoGood »

MathMonkeyMan wrote: post #581
throwaway894345 wrote: post #512

Earlier quoted context omitted.

Yeah, I'm pretty sure there are exactly two substantive problems with JSON for (static) configuration file use cases, which are comments and multiline strings (especially with sane handling of indentation). YAML fixes these, but it adds so much complexity in the process including such a predictable footgun of unquoted strings (the no/false problem is particularly glaring/absurd, but it's also easy to forget to quote…

Solutions abound, but one option is to use either Javascript (config.js): // comments! ({ no_quotes: [1, 2, (() => /* code! */)()], ... }) Or, let the whole thing be a function. Then your config can have parameters, maybe mapped from environment variables or something. ({foo, bar, ...kwargs}) => ({ datacenter: foo === 'old' ? 'useast1' : 'uswest', ... }) Can do as Crockford says, and write in the JSON subset of Javas…

Or you can produce Configuration with nix

Re: Why are we templating YAML? (2019)

#646

Post by eviks »

usrbinbash wrote: post #643
eviks wrote: post #611

Earlier quoted context omitted.

> 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.

> And YAML is a better way and addresses the problem you choose to ignore I haven't ignored it, as shown by us discussing it here. And no, YAML isn't a better way. It does commenting better, true, and at the same time, it does so many things wrong, that are absolutely no problem in JSON, that it becomes a treatment worse than the disease.

You've argued that ugliness is a solution while the problem that needs to be solved is ugliness. You can't have it both ways, either it's a solution, then don't call it ugly as hell, or it's ugly, then not a solution (or it is but that means you ignore that ugliness is the problem)

This specific brand of cleanliness does have a bunch of issues, but that's a trade-off depending on a use case

Re: Why are we templating YAML? (2019)

#647

Post by usrbinbash »

eviks wrote: post #646
usrbinbash wrote: post #643

Earlier quoted context omitted.

> And YAML is a better way and addresses the problem you choose to ignore I haven't ignored it, as shown by us discussing it here. And no, YAML isn't a better way. It does commenting better, true, and at the same time, it does so many things wrong, that are absolutely no problem in JSON, that it becomes a treatment worse than the disease.

You've argued that ugliness is a solution while the problem that needs to be solved is ugliness. You can't have it both ways, either it's a solution, then don't call it ugly as hell, or it's ugly, then not a solution (or it is but that means you ignore that ugliness is the problem) This specific brand of cleanliness does have a bunch of issues, but that's a trade-off depending on a use case

> You've argued that ugliness is a solution

I think I speak for basically the entire history of programming when I say that ugly solutions exist and are widely used throughout our profession.

> while the problem that needs to be solved is ugliness

That's your opinion. I never argued that this hack solves ugliness. I argued that it solves the problem of not having a way to comment in JSON...which it does. I never claimed that it does so in a non-ugly or even good way.

> This specific brand of cleanliness does have a bunch of issues

Issues so massive they, imho, make it not worthwhile to use. As in, I rather miss the ability to write comments or write them with ugly hacks, than put up with YAMLs nonsense.

The fact that better solutions exist (again, like TOML) make this worse.

Re: Why are we templating YAML? (2019)

#648

Post by PH95VuimJjqBqy »

Dylan16807 wrote: post #639
PH95VuimJjqBqy wrote: post #637

Earlier quoted context omitted.

saying the words "I'm not sure what you mean" doesn't give you a pass to speak with authority about the effort involved in getting the class keyword into javascript when you're ignorant of the history. ---- edit: But also, let me point something out. what you're calling "awkwardness with classes" is incorrect. they were _functions_ that you could attach state to, some of that state could, itself, be callable function…

I'm not interested in the effort to get that particular change in, I'm asking for you to elaborate in this broad effort you're implying beyond that. If I misread you, and you're not implying something broader and that's the only change they fought for, then yes it is quite small. To be extra direct there: I didn't say the effort was small, I said that change was small. You can have a big effort for a small change. So…

stop trying to weasel-word your way to being right, people fought MS and largely ignored them for years. There was a time when you didn't use the class keyword because it was non-portable because MS wasn't collaborating with anyone.

But more importantly, this all started because I pointed out that javascript is a functional language.

This remains true, which is why writing functional code in javascript ends up with a better experience, and that's a large part of why jquery won.

Brendan Eich, the creator of javascript, was heavily influenced by. Scheme is functional so I'm not saying anything outlandish here.

https://softwareengineering.stackexchange.com/questions/1941...

> I've never used Self myself, but I believe that JavaScript's extensive use of prototypes came from Self.

> As for Scheme's influence, you need look no further than JS's first-class functions and lexical scoping (okay, so JS doesn't implement full lexical scoping in the way Scheme does, it implements function-level scoping, but still, it's close).

Re: Why are we templating YAML? (2019)

#649

Post by eviks »

usrbinbash wrote: post #647
eviks wrote: post #646

Earlier quoted context omitted.

You've argued that ugliness is a solution while the problem that needs to be solved is ugliness. You can't have it both ways, either it's a solution, then don't call it ugly as hell, or it's ugly, then not a solution (or it is but that means you ignore that ugliness is the problem) This specific brand of cleanliness does have a bunch of issues, but that's a trade-off depending on a use case

> You've argued that ugliness is a solution I think I speak for basically the entire history of programming when I say that ugly solutions exist and are widely used throughout our profession. > while the problem that needs to be solved is ugliness That's your opinion. I never argued that this hack solves ugliness. I argued that it solves the problem of not having a way to comment in JSON...which it does. I never clai…

You just persist in failing to understand the issue

> I think I speak for basically the entire history of programming when I say that ugly solutions exist and are widely used throughout our profession.

I can raise it to the level of the entire history of humanity when I say that people yearn for cleanliness and beauty

> I never argued that this hack solves ugliness.

Sure, because "you choose to ignore [the problem of ugliness] as such". People who share "my opinion" don't ignore that and use cleaner formats, so YAML is a solution that addresses the problem, your suggestion doesn't

Re: Why are we templating YAML? (2019)

#650

Post by MathMonkeyMan »

throwaway894345 wrote: post #627
MathMonkeyMan wrote: post #581

Earlier quoted context omitted.

Solutions abound, but one option is to use either Javascript (config.js): // comments! ({ no_quotes: [1, 2, (() => /* code! */)()], ... }) Or, let the whole thing be a function. Then your config can have parameters, maybe mapped from environment variables or something. ({foo, bar, ...kwargs}) => ({ datacenter: foo === 'old' ? 'useast1' : 'uswest', ... }) Can do as Crockford says, and write in the JSON subset of Javas…

Yeah, I'm mostly just not sure I want to put a full programming language interpreter in my application, especially Python which is not designed to be embeddable. Moreover, I would really want something that is typed, like TypeScript, but libraries for embedded TypeScript interpreters are even more rare :/.

I figure we'd leave it to the build/deploy/CI/development whatever system. I also don't want to extend or embed my application with a full-blown runtime if I don't have to.

"source" config --> convert to JSON config "on the fly" --> app that expects JSON

edit: I worked on a C++ team that used `std::system` to invoke the system python interpreter when loading a config file. My teammates weren't morons, either, it's just the simplest thing that worked and they knew that the config script and the surrounding file system were secure.

Post reply on HN