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

631–640 of 667 posts

Re: Why are we templating YAML? (2019)

#631

Post by smaudet »

PH95VuimJjqBqy wrote: post #620
smaudet wrote: post #601

Earlier quoted context omitted.

> 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 encodi…

> 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 with you: Configuration and Serialization are the same thing, at the format layer. You mumble some nonsense about an abstraction ladder, but the truth is you're climbing it. The difference between only appears at higher levels of abstraction.

> I've never claimed ini works well for complex configuration

And yet you never made a claim about what works well. This is precisely the reason JSON/YAML are popular, and most people ditched INI, people don't care about your higher order abstraction, they just want a format that gets the job done, and doesn't get in your way.

Re: Why are we templating YAML? (2019)

#632

Post by eternityforest »

btown wrote: post #487
tomjakubowski wrote: post #472

Earlier quoted context omitted.

"because you are trying to describe a program in a data structure" (cries in lisp)

I often wonder if the only reason we haven't used lisp more as a society, and certainly in the devops world, is because our brains find it easier to parse nested indentation than nested parentheses. But in doing so, we've thrown out the other important part of lisp, which is that you can use the same syntax for data that you do for control flow. And so we're stuck in this world where a "modern-looking" program is see…

To me it seems a lot of the benefit of declarative programming is just that you can use less powerful tools that don't allow constructs you don't want to have to deal with .

LISP seems great for tinkerers and researchers, but not so much corporate devs who want extreme amounts of consistency and predictability, but don't need the absolute most elegant solution.

Re: Why are we templating YAML? (2019)

#633

Post by eternityforest »

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…

I think I'd rather just have logicless templates than use anything dynamically typed...

Jinja2 makes a lot of sense when you're trying to make it hard to add bugs, and you also don't want everyone to have to learn Rust or Elixir or something.

It would be interesting to extend a template language with a minimal FP language that could process data before the templated get it.

Re: Why are we templating YAML? (2019)

#634

Post by eternityforest »

Draiken wrote: post #126
krapp wrote: post #97

Earlier quoted context omitted.

You shouldn't need the full complexity and power of a Turing complete programming language to do config. The point of config is to describe a state, it's just data. You don't need an application within an application to describe state. Inevitably, the path of just using a programming language for config leads to your config becoming more and more complex until it inevitably needs its own config, etc. You wind up with…

The complexity is already there. If you only need static state like you say, then YAML/JSON/whatever is fine. But that's not what happens as software grows. You need data that is different depending on environments, clouds, teams, etc. This complexity will still exist if you use YAML, it'll just be a ridiculous mess where you can break your scripts because you have an extra space in the YAML or added an incorrect `Tr…

Why are we writing software that needs so much configuration? Not all of it is needed. We could do things more like consumer software, which assumes nobody will even consider your app if they have to edit a config file.

Re: Why are we templating YAML? (2019)

#635

Post by sanderjd »

TheFuzzball wrote: post #26

I just knew this would be about Kubernetes when I saw the title. The Kubernetes API is fairly straightforward, and has a well-defined (JSON) schema, people should be spending a bulk of their time learning k8s understanding how to use the API, but instead they spend it working out how to use a Helm chart. I don't think Jsonnet, Ksonnet, Nu, or CUE ever gained that much traction. I'm convinced most people just use Kust…

Yep, I find kustomize and (especially) helm so confusing, while finding kubernetes yaml files very easy to use and understand.

Re: Why are we templating YAML? (2019)

#636

Post by PH95VuimJjqBqy »

smaudet wrote: post #631
PH95VuimJjqBqy wrote: post #620

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! 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 encodi…

> 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 quote an earlier comment I made

> 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

stop being an architecture astronaut.

But this just takes the cake.

> they [people] just want a format that gets the job done, and doesn't get in your way.

TFA is very clearly stating that if you're having to template it, it's not getting the job done.

Re: Why are we templating YAML? (2019)

#637

Post by PH95VuimJjqBqy »

Dylan16807 wrote: post #629
PH95VuimJjqBqy wrote: post #617

Earlier quoted context omitted.

do not speak with authority if you do not know. do not try and downplay something just because you want it to be true.

"I'm not sure what you mean." isn't speaking with authority. And I stand by saying there was no need for the awkwardness with classes. What did I downplay? You still haven't said what they did. I can't be downplaying a thing that isn't part of the conversation.

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 functions. That's a large part of _why_ javascript has prototype inheritance.

javascript was primarily functional with some features that allowed a bit of OOP sprinkled in.

Re: Why are we templating YAML? (2019)

#638

Post by xdennis »

mekster wrote: post #597
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…

Not sure why people just don't settle with TOML.

It has atrocious arrays. Example: https://youtu.be/n9mGk8_tQtM?t=367

Re: Why are we templating YAML? (2019)

#639

Post by Dylan16807 »

PH95VuimJjqBqy wrote: post #637
Dylan16807 wrote: post #629

Earlier quoted context omitted.

"I'm not sure what you mean." isn't speaking with authority. And I stand by saying there was no need for the awkwardness with classes. What did I downplay? You still haven't said what they did. I can't be downplaying a thing that isn't part of the conversation.

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 you definitely misread me there.

But when you talked about "hammering" it into a more OOP language, I thought you were talking about big changes or many changes.

> 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 functions. That's a large part of _why_ javascript has prototype inheritance.

Does it matter if the "class" itself is a function or an object or something else entirely? It makes thingies that have the prototype applied and you can do .foo on.

But classes you make with the keyword are still functions, aren't they? So what's the big betrayal?

Re: Why are we templating YAML? (2019)

#640

Post by reissbaker »

orwin wrote: post #193
reissbaker wrote: post #172

I think Steve Yegge got it right when he wrote: I know, I know — everyone raves about the power of separating your code and your data . . . But it's [not] what you really want, or all the creepy half-languages wouldn't all evolve towards being Turing-complete, would they? https://sites.google.com/site/steveyegge2/the-emacs-problem Templating YAML is the same, but... Honestly, Jsonnet is too. If you're going to genera…

Does it mean that Lisps 'code is data' is the right idea in the end?

IMO yes, although sadly Lisp is a pretty unwieldy language to do it in — it truly needs a little more syntax sugar for readability's sake. (Also a decent type checker would help.)
Post reply on HN