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

581–590 of 667 posts

Re: Why are we templating YAML? (2019)

#581

Post by MathMonkeyMan »

throwaway894345 wrote: post #512
matsemann wrote: post #505

Earlier quoted context omitted.

At work we're currently expanding to another country. Which means that many services now need a country label etc., which is fun when you're adding "no" to all our existing services. Luckily it's quick to catch, but man... why?

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 Javascript, but with comments, and convert it to JSON by running it through a JS minifier. I think you need parens around the object, though, or else it looks like a code block (boooo...):

    ({
      // This is very much like JSON
      "foo": [1, 2, "bar"]
     })
Python also has JSON-like syntax, so you could use config.py:

    {
      'foo': [1, 2, 'bar']
    }
That would require a wrapper script. Or, you can have the self-contained convention:

    import json
    import sys
    
    # Yay, comments!
    json.dump({
      # more comments!
      'foo': [1, 2, 'bar']
    }, sys.stdout)

Re: Why are we templating YAML? (2019)

#582

Post by hnlmorg »

lamontcg wrote: post #525
hnlmorg wrote: post #520

Earlier quoted context omitted.

There’s plenty to choose from that support embedding: Python, Perl, Lua. Heck, even EMCAScript (JavaScript, VBA, etc). As another commenter rightfully stated, this used to be the norm. I wouldn’t say LOGO is the right example though. It’s basically a LISP and is tailored for geometry (of course you can do a heck of a lot more with it but its strength is in geometry).

You're really missing the point. Logo was super simple and we learned it in elementary school as children, that's all that I'm talking about. And those other languages have accreted way too many features to be simple enough.

> You're really missing the point.

I got your point. I think it is you who is missing mine:

> You're really missing the point. Logo was super simple and we learned it in elementary school as children

You wouldn't have learned conditionals and other such things though. That stuff wasn't as easy to learn in LOGO because LOGO is basically a LISP. eg

    IFELSE :num = 1 [print [Number is 1]] [print [Number is 0]]
vs

    if { $num == 1 } then { print "number is 1" } else { print "number is 0" }
or

    if num == 1:
        print "number is 1"
    else:
        print "number is 0"
I'm not saying these modern languages don't have their baggage. But LOGO wasn't exactly a walk in the park for anything outside of it's main domain either. Your memory of LOGO here is rose tinted.

> And those other languages have accreted way too many features to be simple enough.

I agree (though less so with Lua) but you don't need to use those features. Sure, my preference would be "less is more" and thus my personal opinion of modern Python isn't particularly high. And Perl is rather old fashioned these days (though I think modern Perl gets more criticism than it deserves). But the fact is we don't need to reinvent the wheel here. Visual Basic could make raw DLL calls meaning you had unfettered access to Win32 APIs (et al) but that doesn't mean every VBScript out there was making DLL calls left right and centre. Heck, if you really want to distil things down then there's nothing even stopping someone implementing a "PythonScript" type language which is a subset of Python.

I just don't buy "simplicity of the language" as the reason languages aren't often embedded these days. I think it's the opposite problem: "simplicity of the implementation". It's far easier to load a JSON or YAML document into a C(++|#|Objective|whatever) struct than it is it to add API hooks for an embedded scripting language. And that's precisely why software written in dynamic languages do often expose their language runtime for configuration. Eg Ruby in Puppet and Chef, half of PHP applications having config written in PHP, XMPP servers written in Haskell, etc. In those kinds of languages, it is easy to read config from source files (sometimes even importing via `eval`) so there often isn't any need to stick config in JSON documents.

Re: Why are we templating YAML? (2019)

#583

Post by [deleted] »

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…

[deleted]

Re: Why are we templating YAML? (2019)

#584

Post by Dylan16807 »

PH95VuimJjqBqy wrote: post #566
Dylan16807 wrote: post #559

Earlier quoted context omitted.

I've used it a moderate amount. But I'm not here to argue about how fluid functional code is, I'm here say that OOP works fine, and making slight changes to improve that experience is good. We don't need to actively discourage OOP by making it awkward. Especially when you're not dealing with the DOM, sometimes objects work quite well. The original awkwardness does not show that javascript "was never designed to be us…

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

Re: Why are we templating YAML? (2019)

#585

Post by m463 »

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…

I like json a lot.

That said, I think json would benefit from only two things:

1) comments

2) allow extra commas, like ["a", "b", "c",] or {"a":"b", "c":"d", }

or more properly:

  {
    "a":"b",
    "c":"d",
  },
EDIT: and json5 does both, plus a few more niceties. (hmm. too much?)

Re: Why are we templating YAML? (2019)

#586

Post by dragonwriter »

tristan957 wrote: post #427
dragonwriter wrote: post #334

Earlier quoted context omitted.

> Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants)? ”on”, ”off”, ”yes”, ”no”, “y”, and ”n”, and case variants thereof, are not boolean literals in YAML since YAML 1.2 (2009).

As far as I know, not even libyaml supports 1.2. What YAML parsing libraries support 1.2?

https://www.yaml.info/libraries/index.html

Re: Why are we templating YAML? (2019)

#587

Post by lamontcg »

hnlmorg wrote: post #582
lamontcg wrote: post #525

Earlier quoted context omitted.

You're really missing the point. Logo was super simple and we learned it in elementary school as children, that's all that I'm talking about. And those other languages have accreted way too many features to be simple enough.

> You're really missing the point. I got your point. I think it is you who is missing mine: > You're really missing the point. Logo was super simple and we learned it in elementary school as children You wouldn't have learned conditionals and other such things though. That stuff wasn't as easy to learn in LOGO because LOGO is basically a LISP. eg IFELSE :num = 1 [print [Number is 1]] [print [Number is 0]] vs if { $nu…

I'm deeply uninterested in continuing to have this discussion with you.

Re: Why are we templating YAML? (2019)

#588

Post by trealira »

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. It probably needs to be dynamically typed, have control structures that you can learn in a weekend, not have any threading or concurrency, not be object oriented or have inheritance and be functional/modular in design. And have a very easy to use FFI model so it can call out to / be called from other languages and frameworks.

I think Scheme would work, as long as you ban all uses of call/cc and user-defined macros. It's simple and dynamically typed, and doesn't have built-in classes or hash maps. Only problem is that it seems like most programmers dislike Lisp syntax, or at least aren't used to it.

There's also Awk, although it's oriented towards text, and doesn't have modules (the whole program has to be in one file).

It probably wouldn't be that hard to make this language yourself. Read the book Crafting Interpreters, which guides you through making a toy language called Lox. It's close to the toy language you describe.

Re: Why are we templating YAML? (2019)

#589

Post by kazinator »

trealira wrote: post #588
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…

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. It probably needs to be dynamically typed, have control structures that you can learn in a weekend, not have any threading or concurrency, not be object oriented or have inheritance and be functional/modular in design. And have a very easy to use FFI…

If you combine Awk with the C preprocessor, you have a way for an Awk program to load modules, relative to where that file is located.

There is such a combination project: cppawk.

https://www.kylheku.com/cgit/cppawk/about/

Re: Why are we templating YAML? (2019)

#590

Post by trealira »

kazinator wrote: post #589
trealira wrote: post #588

Earlier quoted context omitted.

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. It probably needs to be dynamically typed, have control structures that you can learn in a weekend, not have any threading or concurrency, not be object oriented or have inheritance and be functional/modular in design. And have a very easy to use FFI…

If you combine Awk with the C preprocessor, you have a way for an Awk program to load modules, relative to where that file is located. There is such a combination project: cppawk. https://www.kylheku.com/cgit/cppawk/about/

Thanks for the link! It seems interesting.
Post reply on HN