9 ms·
> is that for a long time it was the only viable configuration format Actually, this is not the case. We had INI format for simple stuff and XML (protected wit
by dig1 4y ago
> is that for a long time it was the only viable configuration format
Actually, this is not the case. We had INI format for simple stuff and XML (protected with entire schema) for complex things many years ago, which worked. Yet, we wanted something readable (like INI), but able to express complex types (XML).
I don't think Toml is a viable replacement - for me, it has an INI-level of simplicity with even worst hacks to have nested structures. But, give it time and you'll have another YAML.
But yes, YAML is confusing for edge cases (true/false, quoting), but I'm going to find a powerful replacement that is not XML. Maybe EDN can jump in, but for anything more complex, I'd rather have a Lisp interpreter and structures around than any of mentioned and upcoming formats.
Thinking that JSON is a suitable replacement, imagine writing Ansible or k8s stuff in it; that would be fun ;)
- CipherThrowaway 4y ago> Thinking that JSON is a suitable replacement, imagine writing Ansible or k8s stuff in it; that would be fun ;) Writing in YAML doesn't feel much better. YMMV but I've been on teams using Pulumi for k8s and the developer experience has been significantly better. I can automate, type check, lint, click through to definitions the same way I do with other typescript. Pulumi is a young product with many rough edges but it's already been a game changer for me.
- ilyt 4y agoIt's very simple actually. ... just fucking don't, generate config in your configuration management tool of choice and then serialize it to YAML. You get all of the advantages (nice to read)and none of the disadvantages (need editor or it is PITA)
- cocochanel 4y agoI checked the sample Kubernetes project in Java [0] and it looks hideous. YAML looks much better in comparison. [0] https://www.pulumi.com/docs/get-started/kubernetes/review-project/ https://www.pulumi.com/docs/get-started/kubernetes/review-pr...
- CipherThrowaway 4y agoDon't disagree there. Java support is less than a year old and the Java API is.. not great. TypeScript is the more popular and mature choice.
- danudey 4y agoWhat, you mean you don't want to write code like Deployment("nginx",DeploymentArgs.builder().spec(DeploymentSpecArgs.builder().selector(LabelSelectorArgs.builder().matchLabels(labels).build()).replicas(1).template(PodTemplateSpecArgs.builder().metadata(ObjectMetaArgs.builder().labels(labels).build()).spec(PodSpecArgs.builder().containers(ContainerArgs.builder().name("nginx").image("nginx").ports(ContainerPortArgs.builder().containerPort(80).build()).build()).build()).build()).build()).build());
- lifehasleft 4y agoI actually laughed out loud when I looked at the example and just saw a bunch of carefully-indented “.build()”s
- brnewd 4y agoI would love to swap Pulumi for Ansible, but it's cloud-only for the most part.
- PaulHoule 4y agoJSON has no comments. That disqualifies it immediately.
- bogwog 4y ago{ “/*These are the ports we use”: “*/”, “ports”: [22, 80, 443] }
- ok123456 4y agoNow, write a json-schema for that.
- deterministic 4y ago“Comment”: ”This is a comment that is optional and ignored by code”
- zvr 4y ago"Comment": "but you can only have one per object"
- deterministic 4y ago
- revskill 4y agoThis is exactly what i'm doing with this YAML to SQL converter: https://gist.github.com/revskill10/57ecd8efb72f361b93e6d9d9f8a1bfda https://gist.github.com/revskill10/57ecd8efb72f361b93e6d9d9f...
- eru 4y agoUse S-Expressions?
- usrnm 4y agoWith each tool using its own macro-based DSL for managing them. That would be fun
- jerf 4y agoI know what s-expressions are, vaguely. Vaguely in terms of "I couldn't write a grammar for them off the top of my head.", that is, not "what are they". Is there a single agreed-upon defined grammar that everyone can use? Preferably one simple enough that like JSON's it is at least capable of being used as a graphic on the home page for the format? https://www.json.org/json-en.html https://www.json.org/json-en.html This is an honest question, because there may well be and I don't know it. However, I will put this marker down in advance: If multiple people jump up to say "oh, yes, of course, it's right here", and their answers are not 100% compatible with each other, then the answer is no. The other marker I'll put down is "just use common lisp", I want verification that it really is 100% standardized, no question what any construct means, ever, and I still bet we get people who would rather see Scheme or Clojure, and I bet there's some sort of difference. Neither of these objections is fatal to the idea. JSON is technically not just "javascript objects", so if someone carved out a defined format from s-expressions, then held it up as a standard, that would be as valid as what Crockford did. But at least as of right now, I'm not aware of anyone having done that standardization work. Replies welcome.
- urbandw311er 4y ago> YAML is confusing for edge cases (true/false, quoting) I'm not sure I would consider booleans an 'edge case'
- esrauch 4y agoBooleans aren't an edge case, on is an edge case way to spell false.
- 411111111111111 4y agospecifically according to https://yaml.org/type/bool.html https://yaml.org/type/bool.html: y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF Not all parsers support all of these options, but true|false is always supported as YAML is a superset of JSON which makes these mandatory.
- xmonkee 4y agoI can't imagine thinking this is a good idea if you've done any programming whatsoever. What happened here?
- randomswede 4y agoIf you aim to be "human-friendly" (and that is, as I understand, the raison d'etre for YAML), there is a subtle semantic difference between "true" and "on" (and "false" and "off") and as a human it may be nice to express that semantic difference. As for that semantic difference, if we expect the light source to have one of exactly two states (that is, "not a dimmable light"), we probably want to express that as "lightsource: on" rather than "lightsource: true". And that is where the friction between "humanfriendly" and "computer-friendly" starts being problematic. Computer-to-computer protocols should be painfully strict and non-ambiguous, human-to-computer should be as adapted as they can to humans, erring on "expressive" rather than "strict". I am also not sure if I am happy or sad that the set of configuration languages in the original article didn't include Flabbergast[1], which was heavily inspired by what may be simultaneously the best and worst configuration language I have seen, BCL (a language that I once was very relieved to never have to see again, and nine months later missed so INCREDIBLY much, because all the other ones are sadly more horrible). [1] https://www.flabbergast.org/ https://www.flabbergast.org/
- GauntletWizard 4y agoJsonnet and Cue are the places to be looking.
- chazu 4y agoCue is one of the most exciting developments that's impacted me professionally in recent years. I can't advocate for it enough.
- tremon 4y agoCue is interesting, but why is it only available as a command-line tool rather than a library? I'd want to integrate such a configuration language in my programs, so I could use its evaluation and validation capabilities rather than writing a custom parser/validator.
- IshKebab 4y agoAlso their website is terrible. One of those projects that assumes you've already decided (or been forced) to use it and have cleared out a week of your schedule to learn how to use it.
- mirekrusin 4y agoI learned cue from it during one weekend with plenty of time to play with kids, using it in production since 2020, it's been absolutely great, zero problems, very terse configs, intuitive formalism.
- IshKebab 4y agoI took another look and eventually found the bit of the website that they should put front and centre in the Tutorial page. Still difficult to navigate (why doesn't the page tree show up on the left?) but it is at least well written and to the point. The "learn more" button on the front page should link to that, perhaps with a single paragraph giving motivation. And the main page breaks the fundamental rule of programming languages/formats. Put examples on the front page! I assumed they hadn't done that because the examples would be too complex or maybe the concepts were too difficult to demonstrate with small examples but having gone through the tutorial that isn't there case at all.
- wyuenho 4y agoINI has no spec, and there are many variations all slightly incompatible with each other, kinda like Markdown. YAML is really the only sane configuration language that lets you denote nested structures while keeping them look nested. Basically, all of the problem identified in the article can be dealt with 1 rule - always quote your strings. I agree with the author we should have reduced, safe and minimalist subset of yaml, which is basically YAML 1.2, released in 2009. P.S. Please just stop using PyYAML.
- jwilk 4y ago> Please just stop using PyYAML. Why?
- wyuenho 4y agoFrom the article: Although yaml 1.2 is more than 10 years old by now, you would be mistaken to think that it is widely supported: the latest version libyaml at the time of writing (which is used among others by PyYAML) implements yaml 1.1 and parses 22:22 as 1342.
- talideon 4y agoI second that. And if people need to deal with YAML in Python, they should be using ruamel.yaml, which is a far superior library on just about every level: https://pypi.org/project/ruamel.yaml/ https://pypi.org/project/ruamel.yaml/
- wyuenho 4y agoOr if you want to go really minimalist there's also https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml
- lylecheatham 4y agoExcept that the author of ruamel.yaml: refuses to use git [0] refuses to take community submissions (except through Stack Overflow? Seems like a misuse of SO) [1] and refuses to implement .dumps() [2]. He is difficult to work with, and any time I need to debug code that intimately deals with ruamel.yaml types, I wince. [0] https://github.com/pycontribs/ruyaml/issues/1 https://github.com/pycontribs/ruyaml/issues/1 [1] https://yaml.readthedocs.io/en/latest/contributing.html https://yaml.readthedocs.io/en/latest/contributing.html [2] https://stackoverflow.com/a/63179923/15170511 https://stackoverflow.com/a/63179923/15170511
- Normal_gaussian 4y ago> Thinking that JSON is a suitable replacement, imagine writing Ansible or k8s stuff in it; that would be fun ;) k8s via helm is often templated via go template strings; which works by creating an unreadable and unhighightable mess, introducing lots of its own bugs.
- jimmaswell 4y agoXML did everything and it's perfectly readable if it's formatted and structured well. This zoo of different markup/object/whatever languages we have to deal with now is largely a mistake.
- bogwog 4y agoXML is too much of a pain to write by hand.
- wombatpm 4y agoXML is like violence. If it’s not solving your problem, you need to use more
- berniedurfee 4y agoIt’s not that bad really. About the same as HTML, yet more difficult to mess up. Has comments, unlike JSON. More difficult to mess up than YAML.
- tetraca 4y agoXML is pretty tolerable with a slightly more sophisticated editor that supports completion. The things that make YAML awful never get any better.
- jimmaswell 4y agoThrow in copilot to anticipate all the boilerplate and repetition for you and it's downright pleasant.
- wyuenho 4y agoXML is a mistake. 80% of every XML document is just redundant noise because the IBM lawyer who invented the SGML syntax had never heard of S-expression.
- sam_lowry_ 4y agoSGML is way shorter than XML. But as complex as YAML to understand
- berniedurfee 4y agoIf JSON and YAML were first on the scene; XML would be invented as an answer. Hard to mess up. Robust schema language. Very flexible. Easy to process. Yeah, it’s verbose, but that’s the trade-off between usability and robustness. Now get off my lawn!
- lanstin 4y agoWhat XML replaced was a combination of custom designed (often binary) formats and HTTP query-string like syntaxes. It is quite verbose compared to either of them, and explodes both your bandwidth and serialize/deserialize times, but it is arguably easier for your new co-worker to guess that the address line 2 goes in <address2>...</address2> rather than prefix tagged with 13, or worse yet at offset 42-61. I got used to XML, tho I never could quite understand XSLT and the desire to program in it. I got used to json, but yaml I just can't bring myself to parse. YAML is 90% stuff you can't guess and just 10% data. And why so many?
- throwawaymaths 4y agoNo. XML is broken for structured data that isn't HTML because it's not really clear (there aren't even "best practices" afaict) what should be a text node, what should be an attribute node, and what should be a subtag node.
- int_19h 4y agoIt's not like other formats don't face similar questions. E.g. if you have a list of key-value pairs to serialize to JSON, do you translate those keys to JSON properties in an object, or do you translate each pair as an object in an array?
- throwawaymaths 4y agoThe motivation for doing that in JSON comes with best practices: you use the key-value objects thing if and only if you have an ad-hoc list of items that you'd really really like to shove into a well-typed schema.
- mirekrusin 4y agoJSON is good because it doesn't let you do stupid things like writing programming languages in it.
- anonymoushn 4y agoIs INI a format in the sense that it has a formal grammar and a bunch of compatible parsers and serializers, or is it more of a convention?