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

551–560 of 667 posts

Re: Why are we templating YAML? (2019)

#551

Post by WorldMaker »

Dylan16807 wrote: post #504
WorldMaker wrote: post #481

Earlier quoted context omitted.

The behavior described above seems to me to be exactly soft tabs at 4 in a 2-space tab document with autoindent turned on (often the default). Vim has no autodetect by default. (I'm sure there's a plugin somewhere.)

The part where the user is on a line indented by 2, hits return, and gets a line indented by 2+4=6 doesn't sound like soft tabs at 4 to me. And I wouldn't expect hitting backspace to then only remove 1 space (if it actually removed 2 that makes more sense, but is inconsistent with what what it just added). At that point, hitting return and getting a line indented by 8 might make sense but is weird. Another comment su…

2 is the base indent of the line where the : was added. Autoindent adds 4 spaces for the current tab stop. Autoindent isn't using some counts of indents, it's taking "spaces in previous line + tab stop".

Backspace doesn't unindent in vim by default, it removes spaces one at a time. That's a difference between the ts=4 (tab stop) and sts=4 (soft tab stop) is sts also applies to backspace. But the default is that it doesn't because the out of the box default believes that backspace operates on physical characters (spaces) not soft/fake ones (tabs expanded to spaces) by default.

I don't know if that is the right default, and it is definitely a baroque exercise to get all the settings right for some languages, but there is a consistency to the defaults even if those defaults don't meet some modern expectations from newer code editors.

(Also, I just realized above I confused tw [text width] and ts [tab stop]; my vim skills are rusting a little.)

Re: Why are we templating YAML? (2019)

#552

Post by vitiral »

I'm designing a simple dev environment from scratch.

My solution for this is a sandboxed lua for programatic configuration:

https://github.com/civboot/civlua/tree/main/lib/luck

I can't stand JSON (for many reasons) so I created a serialization format that combines it and CSV for nested objects

https://github.com/civboot/civlua/tree/main/lib/tso

I wish the industry would standardize on a solution like this. IMO you shouldn't use a "real" language unless you can lock it down to be determinisitic. JSON is supposed to be human readable but fails for lots of real-world data like multi-line strings or lists of records.

CSV is more readable but doesn't supported nested objects.

Re: Why are we templating YAML? (2019)

#553

Post by int_19h »

neallindsay wrote: post #120

My personal philosophy is that string interpolation should not be used to generate machine-readable code, and template languages are just fancy string interpolation. We've all seen the consequences of SQL injection and cross-site scripting. That's the kind of thing that will keep happening as long as we keep putting arbitrary text into interpreters. Yes, this means I don't think we should use template files to make H…

Not all template languages are string template languages, though. If you consider PHP a templating language for text, for example, then by the same logic XQuery is a templating language for XML.

Re: Why are we templating YAML? (2019)

#554

Post by pseudonom- »

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…

Dhall is the FP config language you're thinking of, I think.

Re: Why are we templating YAML? (2019)

#555

Post by int_19h »

Leo_Verto wrote: post #15
embik wrote: post #3

I am really sad that jsonnet / ksonnet never really took off. It’s a great way to template, but has a bit of a learning curve in my experience. I suspect that is why it’s niche. If you like what is presented in this article, take a look at Grafana Tanka ( https://tanka.dev ).

The fact that it's a purely functional programming language with lazy evaluation is really powerful but steepens the learning curve for devs who haven't worked with functional languages. The stdlib is also pretty sparse, missing some commonly required functions.

> The stdlib is also pretty sparse, missing some commonly required functions.

This seems to be the general curse of template languages. For some reason, their authors have this near-religious belief in removing every "unneeded" feature, which in practice results in having to write 10 incomprehensible lines of code to do something that could be easily done in one line of readable code in a proper PL.

Re: Why are we templating YAML? (2019)

#556

Post by int_19h »

Hackbraten wrote: post #23
pvorb wrote: post #13

Earlier quoted context omitted.

YAML is all but human-friendly. It has far too many special features and edge cases for most people. Something simple like Java properties files would solve something like markdown front matter perfectly fine.

Java properties files are a mess. They still require Windows encoding (ISO-8859-1), which is incompatible with UTF-8.

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

Re: Why are we templating YAML? (2019)

#557

Post by int_19h »

brodouevencode wrote: post #289

It's fashionable to hate YAML. And sometimes rightly so. But what are the alternatives? JSON, XML, INI, TOML, Dahl, Cue, JSONNET, HCL, your programming language of choice. Also let's agree on the target use case - in that YAML is largely used for configuration and operational tasks. If I were to rank-order the features necessary in a good configuration language they would be 1) readability 2) data/schema validation 3…

I'd take an XML config over a YAML one any day. This isn't to say that XML is great, but its warts are well-known, and they are generally not of the kind that makes it easy to shoot yourself in the foot. Mostly the problem is that it's verbose, and to some extend, redundant.

JSON is also fine, esp. if it is JSON5 (with comments, unquoted keys, and other such minor improvements). I find that braces, brackets, and quotes don't get in the way - if anything, they make the structure clearer.

Re: Why are we templating YAML? (2019)

#558

Post by dharmab »

awesomeMilou wrote: post #458
kimbernator wrote: post #356

Earlier quoted context omitted.

I once took a job that involved managing Ansible playbooks for an absolutely massive number of servers that would run them semi-regularly for things like bootstrapping and patching. I had used Chef before for a similar task, and I loved it because it's just ruby and I could easily define any logic I wanted while using loops and proper variables. I understand that Ansible was designed for non-programmers, but there is…

I agree. And to make matters worse, the DSL on YAML has grown so large in features, it may as well be a programming language now.

It technically is. Long ago as a junior sysadmin I created turing complete nightmares in Jinja.

Re: Why are we templating YAML? (2019)

#559

Post by Dylan16807 »

PH95VuimJjqBqy wrote: post #543
Dylan16807 wrote: post #517

Earlier quoted context omitted.

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

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 used like a classic OOP language".

Nor is it why jquery worked well.

And adding these slight changes is not trying to "hammer" javascript into being "more typical OOP".

Re: Why are we templating YAML? (2019)

#560

Post by Dylan16807 »

WorldMaker wrote: post #551
Dylan16807 wrote: post #504

Earlier quoted context omitted.

The part where the user is on a line indented by 2, hits return, and gets a line indented by 2+4=6 doesn't sound like soft tabs at 4 to me. And I wouldn't expect hitting backspace to then only remove 1 space (if it actually removed 2 that makes more sense, but is inconsistent with what what it just added). At that point, hitting return and getting a line indented by 8 might make sense but is weird. Another comment su…

2 is the base indent of the line where the : was added. Autoindent adds 4 spaces for the current tab stop. Autoindent isn't using some counts of indents, it's taking "spaces in previous line + tab stop". Backspace doesn't unindent in vim by default, it removes spaces one at a time. That's a difference between the ts=4 (tab stop) and sts=4 (soft tab stop) is sts also applies to backspace. But the default is that it do…

That doesn't explain how it then goes to 8 total spaces.
Post reply on HN