[HN Gopher] YAML: It's Time to Move On
___________________________________________________________________
YAML: It's Time to Move On
Author : firearm-halter
Score : 96 points
Date : 2021-11-14 20:25 UTC (2 hours ago)
(HTM) web link (nestedtext.org)
(TXT) w3m dump (nestedtext.org)
| Waterluvian wrote:
| My opinion only: I love JSON because it lacks so many foot guns
| of yaml. If you're doing lots of clever stuff with yaml you
| probably want a scripting language instead. Django using Python
| for configs made me fall in love with this. Spending years with
| the unmitigated disaster that is ROS xml launchfiles and
| rosparams makes me love it even more.
|
| Yaml and toml are fine if you keep it simple. JSON direly needs
| comments support (but of course wasn't designed to be used as a
| human config file format so that's kind of on us). And not just
| "Jsonc that sometimes might work in places."
|
| Beyond that, I think we generally have all the things we need and
| I don't personally think we need yet another yaml. =)
| dmitriid wrote:
| > My opinion only: I love JSON because it lacks so many foot
| guns of yaml.
|
| While true, parsing it is still a minefield because it's very
| underspecified: http://seriot.ch/projects/parsing_json.html
| BugsJustFindMe wrote:
| > _Django using Python for configs made me fall in love with
| this._
|
| I also started advocating in-language configuration files
| (Python for Python, but also Lua for Lua, etc) a number of
| years ago because it lets you do really useful things (like
| functionally generating values, importing shared subsets of
| data, storing executable references, and ensuring that two keys
| return the same values without manual copy/paste) all without
| needing to spec and use Yet Another Thing(tm) that does only a
| fraction of what the programming language you're already using
| already does.
| eptcyka wrote:
| That also implies that you can't just test a foreign config
| file without first reading and understanding what it does, as
| just using one would imply arbitrary code execution.
| kevin_thibedeau wrote:
| This is a place where Tcl excels. You can easily create
| restricted sub-interpreters that can't do anything
| dangerous. If you need more power for trusted scripts you
| just reenable selected commands.
| spacechild1 wrote:
| Same thing with with Lua!
| Jnr wrote:
| Using the programming language to do the comments works only
| when using some scripting language.
|
| Things that get compiled can't really use it without
| recompilation.
| pjmlp wrote:
| That is how our Tcl based application server was, the
| configuration files were a Tcl DSL.
| woodruffw wrote:
| These aren't foot-guns per se, but I can think of another
| handful of grievances I have with JSON:
|
| * JSON streaming is a bit of a mess. You can either do JSONL,
| or keep the entire document in memory at once. I usually end up
| going with JSONL.
|
| * JSON itself doesn't permit trailing commas. I can measure the
| amount of time that I've wasted re-opening JSON files after
| accidentally adding a comma in _days_ , not hours.
|
| * JSON has weakly specified numbers. The specification itself
| defines the number type symbolically, as (essentially)
| `[0-9]+`. It's consequently possible (and common) for different
| parsers to behave differently on large numbers. YAML also,
| unfortunately, has this problem.
|
| * Similarly: JSON doesn't clearly specify how parsers should
| behave in the presence of duplicate keys. More opportunity for
| confusion and bugs.
| spullara wrote:
| You can parse JSON in a streaming fashion with many
| libraries. You just don't know at the beginning if it is
| going to be valid or not.
| lkschubert8 wrote:
| And the flip side of that with YAML is you can stream it,
| but you don't know once you've gotten to the end if it was
| the whole document without some user defined checksum
| mechanism.
| secondcoming wrote:
| 2, 3 and 4 can be caught early with JSON schema.
| mirekrusin wrote:
| Not really, json schema validation is applied after json
| parsing on already parsed json.
| xorcist wrote:
| How someone could have decided on a subset of javascript and
| not include comments is beyond me.
| afiori wrote:
| the funny thing is that json doesn't even need commas _, they
| essentially act as whitespace, any amount or no amount would
| make no difference in the meaning of the document.
|
| _ Arrays with hole are a JS-only feature
| jrockway wrote:
| Running prettier (https://prettier.io) on each save will fix
| trailing commas for you. If you accidentally have one, it
| will just sneakily remove it and turn your document into one
| that is valid.
| timmytokyo wrote:
| JSON5 is the way to go. It supports comments and trailing
| commas. Unfortunately it's going to be difficult to supplant
| legacy JSON, which is so pervasive.
| dheera wrote:
| Except parsing JSON5 in browser is super slow. Native
| JSON.Parse doesn't support it, non-native parsnips are slow,
| and the only fast way to parse it is `eval()`.
| TheCondor wrote:
| Does the browser need JSON objects with comments?
|
| The desire to use a single interchange format for all data
| is the problem. There are plenty of reasons to support
| comments and minor syntax issues that JSON itself dislikes
| for human consumable and interactive JSON. I'd think
| software JSON could be just that.
| The_Colonel wrote:
| This shouldn't really matter for the JSON5 use case -
| config files - which are usually small enough.
|
| For machine-to-machine generated payloads JSON is good
| enough.
| gmadsen wrote:
| I work with ros extensively and have not heard of using django
| for this use case. do you know of any open source projects that
| do this?
| mongol wrote:
| There was an interesting project showcased here a while ago, it
| was some kind of very minimal language, almost the most minimal
| theoretically possible, but with some interesting properties.
| Does anyone remember it?
| kps wrote:
| I can't tell whether you're making a LISP joke.
| mongol wrote:
| Actually not.
| account-5 wrote:
| I like INI. It's simple it's readable and it leaves the data
| types up to the application to interpret. It's also really easy
| to parse, I can work out how to do it and JSON is beyond me.
|
| I like CSV (and similar delimited files) it's less verbose than
| anything else for tabular data.
|
| I like JSON for data transfer, you know the data types, it's
| succinct, and readable.
|
| I personally don't need anything else.
| zz865 wrote:
| INI is my favorite. I dont understand why it isn't the
| automatic default for everything.
| aspaceman wrote:
| This is the right answer in my view. If you need something
| structured use XML, otherwise INI.
|
| I'm more likely to Yacc my own config format than use YAML or
| JSON personally.
|
| JSON is great as an output format for data though.
| midasuni wrote:
| Not a fan of Yaml. An ini file (no space problems) for simple
| config, json for more complex structure, csv for multiple entries
| with the same fields
| morelisp wrote:
| The introduction keeps citing "no need for escaping or quoting"
| as a major advantage, but provides no examples of what a key with
| a colon, or value beginning with "[", or any datum with leading
| or trailing whitespace would look like.
|
| Also, the changelog is quite frightening!
|
| > [In 3.0], `[ ]` now represents a list that contains an empty
| string, whereas previously it represented an empty list.
| matzf wrote:
| This made my curious to find out. The "Language introduction"
| docs [1] answers these points;
|
| * keys containing leading spaces, newlines or colons can be
| represented with the multiline key form, where each line of the
| key starts with `: `.
|
| * leading or trailing space is not complicated; the string
| values are just the rest of the line after the separator from
| the key, `: `. The values are not trimmed.
|
| * a string value beginning with `[` just works in most places.
| This would not be confused with list values, as these would
| only start after a new line. Only in the compact inline list
| and inline dict form there are restricted characters for
| syntax.
|
| It seems that their claim, no escaping required, holds. The
| slightly more verbose form of the language constructs may be
| required to represent special values though.
|
| [1]: https://nestedtext.org/en/stable/basic_syntax.html
| georgewfraser wrote:
| A radically different alternative with a lot going for it is
| Starlark: https://github.com/bazelbuild/starlark
|
| It's a deterministic subset of Python. This means that if you
| have complex or repetitive configurations, you can use loops and
| functions to structure them. But it's impossible to write an
| infinite loop or recursion.
| remram wrote:
| Interesting! I started using jsonnet this year, but found that
| the language was needlessly quirky (e.g. the `::`, purely
| functional aspect, and no one wants to learn a new language to
| write configuration in the first place). More importantly, it
| is extremely slow (lazy evaluation without memoization...):
| rendering the Kubernetes YAML of my 5-container app taking over
| 10 seconds...
|
| I will look into this further.
| xiaq wrote:
| > It's a deterministic subset of Python. This means that if you
| have complex or repetitive configurations, you can use loops
| and functions to structure them. But it's impossible to write
| an infinite loop or recursion.
|
| Starlark is indeed deterministic and guaranteed to terminate
| (the Go implementation has a flag that allows recursion, but
| it's off by default), but these are two orthogonal properties.
| vlovich123 wrote:
| Have you had any experience building on top of it directly
| outside of blaze/bazel?
| dilyevsky wrote:
| I have - https://github.com/cruise-automation/isopod and more
| generally with https://github.com/stripe/skycfg
| civilized wrote:
| Not a bad idea but only implemented in Rust, Go, and Java so
| far. Meanwhile, all sorts of languages can interpret JSON and
| YAML.
|
| It's a cool idea to do configuration in a subset of Python but
| now you have to go implement that subset in every language.
| OskarS wrote:
| > Starlark is a dialect of Python. Like Python, it is a
| dynamically typed language with high-level data types, first-
| class functions with lexical scope, and garbage collection.
|
| If it has first-class functions, how can you avoid infinite
| recursion? Like, what stops me from running the omega
| combinator in it? This is why Meson (a similar language) does
| not allow those kinds of shenanigans, to keep the language non-
| Turing-complete.
| georgewfraser wrote:
| No recursion and no lambda.
| slowmovintarget wrote:
| EDN [1] and Transit [2]... Elegant weapons for a more civilized
| system.
|
| [1] https://github.com/edn-format/edn
|
| [2] https://github.com/cognitect/transit-format
| im3w1l wrote:
| So one thing I wasnt sure of is: If you have a Starlark program
| how is the value of it decided? Is it simply the value of the
| last expression? And where does the print-output end up? Is it
| just for diagnostics and has no influence on the value?
| leontrolski wrote:
| How about just nudge json a couple more notches towards js?
| https://github.com/leontrolski/dnjs
| seedless-sensat wrote:
| Plenty of tools lacking in the Starlark environment, e.g.:
| generating Starlark files, machine editting Starlark maps
| arpa wrote:
| XML above all!
| Spivak wrote:
| XML in theory is a great format for what it represents -- a
| tree of heterogeneous typed simple key/value pairs.
|
| The problem is almost no data that people want to actually
| represent has this form and every way people have tried to beat
| XML into representing other things (i.e. lists and dicts) is
| kludgy is awkward.
| badrabbit wrote:
| My opinion: I can live with yaml and json. Toml,tjson if I have
| to. Xml with a gun to my head. But I don't want yet another
| markup language (ironically that's what YAML stands for)
| adorton wrote:
| YAML stands for "YAML Ain't Markup Language"
| ashtonkem wrote:
| Which is more than a tad bit ironic, in retrospect.
| lawtalkinghuman wrote:
| Not really since it's true. It isn't markup, it's a
| configuration file format.
|
| "<em>This</em> is a markup language" since there is text
| which is marked up.
|
| YAML/JSON is a way to serialise fairly common data
| structures (arrays/lists, hashes/dictionaries, numbers,
| strings, bools, etc.)
|
| Incidentally, if you can seamlessly replace XML with
| something like JSON, then you probably aren't using the
| 'markup' bit of XML.
| PaulHoule wrote:
| What I want from YAML (or a competitor) is access to the
| concrete syntax tree.
|
| For one of my art projects I make YAML files that describe the
| front side, back side, and web side of a "three sided card". I
| generate these out of several templates, currently using
| ordinary string templating.
|
| I'd love to be able to load a YAML file and add something
| programatically to the list and have the list stay in the same
| format that it was in, so if it was a [1,2,3]
|
| list I get [1,2,3,4]
|
| if it was a - 1 - 2 - 3
|
| list I want - 1 - 2 - 3 -
| 4
|
| sadly I'm the only one who thinks this way.
| Ciantic wrote:
| You are not the only one. But even if you find a library for
| YAML AST transformations for your language. What ever other
| language uses your YAML probably doesn't have it.
|
| E.g. I tried exactly the same thing, and it was quiet
| difficult with Rust. Because the way to parse it usually is
| with serde and it just removes the AST of course.
|
| In the end I gave up, and just used JSON for my use case.
| stavros wrote:
| https://yaml.readthedocs.io/
| the_duke wrote:
| Two interesting configuration language alternatives:
|
| https://dhall-lang.org/
|
| https://cuelang.org/
| BiteCode_dev wrote:
| I've tried dhall, cue and jsonet, and cue is so far my fav.
| It's very well designed, expressive, but restrictive enough so
| that config files don't look like scripts.
|
| The way it blend types and values makes learning it super easy,
| yet you can do complex things with few lines.
|
| But the main implementation exports to yaml without quoting the
| strings, which kinda defeat the purpose :(
| mananaysiempre wrote:
| I'm kind of unsure about the way CUE achieves reuse: if I
| understand correctly, you have files in a directory tree and
| the (result of processing the) bottommost files are the
| things you're supposed to point your consuming tools at. So
| there's no way to share structure among a collection of items
| if that collection is nested inside your config, the only
| operation available is essentially the generation of a set of
| similar but separate configs. Or am I wrong here? I'd very
| much like to be.
|
| (Also, the type system is absolutely delicious, but it badly
| needs a paper with a complete description. I'm extremely
| interested in how it works, but fragmentary "notes on the
| formalism underlying" CUE are not enough.)
| BiteCode_dev wrote:
| You do have imports and functions so you can reuse what you
| want.
|
| The doc is also quite clear and rich, but the way it's
| organized means I have to read it entirely before writting
| my first CUE file. It also lacks IRL examples so trials and
| errors were my best friends.
|
| It can be discouraging.
| stillicidious wrote:
| Author seems to use misfeatures of a particular implementation to
| tar all implementations with. The round-tripping issue is not a
| statement about YAML as a markup language, much in the way a
| rendering bug in Firefox is not a statement about the web.
|
| Stepping back a bit, YAML is good enough, and this problem has
| been incrementally bikeshedded since at least the 1970s, it is
| time to move on. Human-convenient interfaces (like YAML, bash,
| perl) are fundamentally messy because we are messy. They're prone
| to opinion and style, as if replacing some part or other will
| make the high level problem (that's us) go away. Fretting over
| perfection in UI is an utterly pointless waste of time.
|
| I don't know what NestedText is and find it very difficulty to
| care, there are far more important problems in life to be
| concerned with than yet another incremental retake on
| serialization. I find it hard to consider contributions like this
| to be helpful or represent progress in any way.
| throwaway81523 wrote:
| > Stepping back a bit, YAML is good enough, and this problem
| has been incrementally bikeshedded since at least the 1970s, it
| is time to move on
|
| Nah, in the 1970s we had Lisp S-expressions that completely
| solved the problem, and everything since then has been
| regressions on S-expressions due to parenthesis phobia.
|
| After hearing that thing about the country code for Norway, I
| became convinced that YAML has to just die. Become an ex-markup
| language. Pine for the fjords. Be a syntax that wouldn't VOOM
| if you put 4 million volts through it. Join the choir
| invisible, etc.
|
| This is good: https://noyaml.com/
|
| Erik Naggum had a notoriously NSFW rant about XML (over the top
| even for him) that I better not link to here, but lots of it
| applies to YAML as well.
| Aloha wrote:
| If you use YAML in situations where it may need hand editing,
| it means you actively hate your users.
|
| YAML is patently unsuitable for any use case where the
| resulting output may require hand editing.
| AYBABTME wrote:
| It'd be bikeshedding if the status quo was good. But it isn't.
| dmitriid wrote:
| > Author seems to use misfeatures of a particular
| implementation to tar all implementations with.
|
| There's no canonical YAML implementation, and YAML spec is
| enormous (doubly so if you need to work with stuff like non-
| quoted strings etc. )
| tannhaeuser wrote:
| > _YAML as a markup language_
|
| YAML ain't markup language.
| spicybright wrote:
| I actually disagree it's bike shedding.
|
| If you can write a bad YAML document because of those mis-
| features/edge cases, I'd say you've already lost.
|
| Humans are messy, but at the end of the day the data has to go
| to a program, so a concise and super simple interface has a lot
| of power to it for humans.
|
| Working at a typical software company with average skill level
| engineers (including myself), no one likes writing YAML. But
| everyone is fine with JSON.
|
| I think it's a case of conceptual purity vs what an _average_
| engineer would actually want to use. And JSON wins that. If
| YAML was really better than JSON, we 'd all be using that right
| now.
|
| So does it really matter if YAML is superior if >80% of
| engineers pick JSON instead?
| posharma wrote:
| It's really sad to see the pervasiveness of JSON. For one thing
| its usage as a config file is disturbing. Config files _need_ to
| have comments. Second, even as a data transfer format the lack of
| schema is even more disturbing. I really wish JSON didn 't happen
| and now these malpractices are so widespread that it's hurting
| everyone.
| runarberg wrote:
| Tools that use JSON as configuration format could simply allow
| certain unused keys (e.g. all keys starting with #) and promise
| never to use them. Then author can write their comments with
| something like: { "name": "my-
| tool", "#comment-1": "Don't change the version!",
| "version": "42.1337.0" }
| posharma wrote:
| I've heard and read this multiple times. Why are you trying
| so hard to fit into a format that doesn't just support
| comments out of the box? What advantages is JSON offering you
| that you've compelled to bend over backwards to do this? It's
| exactly these kinds of workarounds that is making it super
| difficult stop such malpractices. It's just plain ugly.
| Please stop doing this.
| jackjeff wrote:
| JSONC. JSON with comments. And even if your favorite parser
| does not support it natively it's not so hard to add with a
| very simple pre-lexer step.
|
| JSON schemas exist and they're ok for relatively simple things.
| For more complex cases I find myself wishing I could just turn
| Typescript into some kind of schema validation for JSON.
| umvi wrote:
| So you prefer the "good old" XML days? I'll take comment-less
| JSON over XML any day
|
| (and it doesn't have to be comment-less... JSON with comments
| is a thing and VSCode has syntax highlighting for it - just
| strip out the comments before parsing).
| [deleted]
| zz865 wrote:
| XML is perfect. + With all the fancy editors now its very
| easy to write. Easy schema to check, comments. Perfect.
| nsonha wrote:
| not easy to read, it's the java of config, pages of code
| that express very little, by the time you find what you
| need, you forget the context and what level of nesting
| you're on already. It's also more wasteful as a transport.
| posharma wrote:
| It's simple. For config files, choose the format that has the
| best tooling in your company and that supports comments. For
| data transfer, choose that supports schemas, backwards
| compatibility and good tooling (protobufs is just one e.g.
| that I'm most familiar with).
| stavros wrote:
| > So you prefer the "good old" XML days? I'll take comment-
| less JSON over XML any day
|
| Aren't we past basic false dichotomies?
| saurik wrote:
| Nope: basic false dichotomies and JSON are both ubiquitous.
| avsteele wrote:
| I'll give my opinion as someone who has to choose among JSON,
| XML, TOML, and YAML about two years ago for a new project.
| Whatever I chose had to be easy for end-users who don't know the
| specification to to understand later.
|
| Here were my thoughts on the options.
|
| JSON - No comments -> impossible
|
| XML - Unreadable
|
| YAML - 2nd place. Meaningful indentation also made me worried
| someone was going to not understand why their file didn't work.
| The lack of quotes around strings was frustrating.
|
| TOML - 1st place. Simpler than YAML to read & parse. It truly
| seems 'obvious' like the name says.
|
| I haven't encountered any situations where I wish I had more than
| TOML offers.
| Drdrdrq wrote:
| > NestedText only supports three data types (strings, lists and
| dictionaries)...
|
| No numbers? Looks nice otherwise, but this seems like a very
| weird decision.
|
| That said, JSON with its "I might overflow your number" attitude
| is not much better in this regard.
| mongol wrote:
| Yes but I can understand the rationale. There are many numeric
| types and settling on some excludes use with others. If letting
| the application handle that, the configuration language can
| remain simple. His example where a version number 1.10 was
| round trip converted to 1.1 was enlightening.
| zmmmmm wrote:
| I have to say I hate the fact that I have low confidence when
| editing YAML that the result will be what I intend. It's kind of
| the number one job of such a format. And I routinely run into
| people using advanced features and then I have no idea at all how
| to safely edit it. It is interesting that it seems so difficult
| to pick a good tradeoff between flexibility and complexity with
| these kinds of languages.
| forrestthewoods wrote:
| Here's my dream config language:
|
| * start with JSON
|
| * add comments (obviously)
|
| * allow trailing commas (obviously)
|
| * allow left-side and right-side to be independently and
| explicitly typed
|
| * extensible type support (JSON's lack of u64 is absurd)
|
| For example the following are all equivalent:
|
| * "foo" : f32 = 13.37
|
| * "bar" : f32 = "13.37"
|
| * "baz" : f32 = 0x4155eb85 : hex
|
| And extensibility to allow:
|
| * "ham" : u64 = 123456789123
|
| I would also be inclined to allow explicit config file hierarchy
| by allowing:
|
| * configs can specify their base
|
| * configs can specify their child
|
| * must be acylic
|
| I've thought about implementing this myself. But I've never
| written a real lexer or parser. It's on my side-project TODO
| list.
| heinrich5991 wrote:
| JSON has integer types/literals AFAIK, it's just that the
| Javascript implementation doesn't support them.
| forrestthewoods wrote:
| It has numeric literals. But all JSON number types are f64.
| Which is sufficient to represent every 32-bit integer, but it
| can not represent all 64-bit integers.
|
| For code that needs a 64-bit integer, which is quite a lot,
| you have to encode the integer in a string.
|
| Lack of 64-bit integer (either signed or unsigned) is a
| pretty common and well understood pain point when using JSON
| as an interchange format.
| twobitshifter wrote:
| I wrote a program at a corporate job where all the configuration
| is in Excel files. Tables are just fed into a dictionary and
| columns on each worksheet are predefined to hold the keys. People
| loved it because they know how to use excel and "text" is scary.
| (This is all very strange because they are just entering text in
| Excel, but the familiarity goes a long way)
| foepys wrote:
| I _recently_ suffered through a meeting where we developers
| were told to use the _new_ testing framework some team at our
| corp created. It's written in Java (we use .NET exclusively in
| our branch), configured via Excel sheets and Java, and exports
| results also as Excel sheets.
|
| Whoever thought this was a good idea in 2021 has to be
| braindead. But the CEO was pleased. Probably because they know
| Excel.
| pjmlp wrote:
| I give you Robot, originally created at Nokia.
|
| https://robotframework.org
|
| Back in 2006, the testing was written in HTML tables, no idea
| how it manage to still be around.
| bluedino wrote:
| Same but ms access
| pjmlp wrote:
| I just stick to XML unless forced to use something else.
|
| Schema validation, code completion on IDEs, endless amount of
| tooling including graphical visualisation, a language for data
| transformation and queries, and.... wait for it... comments!
| sl0w0rm wrote:
| I'm working on my own (you can start the attack hahaha). I feel
| there's not many simple, generic languages that allow to write
| simple DSLs with embedded documentation. The self documenting
| part is still missing but you can take a look and say what you
| think. It's kind of like yaml format (a bit TOML) with schema and
| possibility to merge multiple files with smaller chanks of the
| data. With export to json and yaml.
| https://github.com/dadlang/dadl
| MH15 wrote:
| This looks pretty cool
| lox wrote:
| Have spent many years developing dev tools that use YAML and
| alternatives and I still think YAML wins because of its ubiquity
| relative interop with JSON. I'd pick HCL as an alternative if I
| was going to, as it's been widely battle tested in Terraform.
| andrewdubinsky wrote:
| JSON is often so hard to read I have to open a file in a
| formatting tool. It's also hard to tell if there's a simple
| missing quote or brace. Those are extra steps I don't have with
| YAML. For many things, JSON is great. For simple loaders, YAML
| gets it done quick and easy. They are functionally interoperable
| for the most part so I use what's best.
|
| I'd also add the author has a competing framework so maybe
| there's a bit of pre-existing bias.
| zamadatix wrote:
| I'm not sure I'd trust manually editing either in a plain text
| editor. YAML cares about whitespace yet will silently make most
| combinations valid and it also has surprising pitfalls on type
| interpretation if one isn't consistently on top of it when
| entering data. JSON has a bunch of additional characters but at
| least if you forget them you have a higher chance of it just
| telling you it's wrong when you try to use it.
|
| Thankfully it's very rare I ever have to open any config file
| in a text editor that isn't aware of dozens of formats so
| things like a missing brace are always suggested anyways and it
| isn't much a problem regardless of format.
| initplus wrote:
| When you miss a quote or a brace in JSON, the JSON fails to
| parse. When you make a similar minor mistake in YAML, you often
| end up with a valid but nonsensical document with completely
| incorrect structure.
|
| I don't want the language to be flexible enough that simple
| common errors go unnoticed - I WANT the parser to tell me at
| parse time if I screwed something up. It's a similar dynamic to
| dynamic/static typing.
| woodruffw wrote:
| I'm glad to see people experimenting with alternative
| document/object representations, but this one might be a hard
| sell: based on the README[1], it only has Python, Zig and Janet
| implementations so far. One of the nice things about YAML (and
| JSON, TOML, etc.) is that they have decently mature C, C++, or
| Rust libraries that other languages bind to.
|
| [1]: https://github.com/KenKundert/nestedtext
| dylan604 wrote:
| I have a client that uses a CMS of unknown origins. I just get
| stuff placed in an s3 bucket, and then attempt to parse what was
| provided. 100% of their YAML files are invalid by every single
| linter I have found/tried. Not one of them understands where the
| error is occuring to help debug. It litterally just says invalid.
| I'm at a total loss. My head doesn't think YAML. Does a string
| need quoting or not? trailing spaces at the end causes problems?
| my personal experience in YAML is limited, but it hasn't been
| pleasant.
| diob wrote:
| What is the obsession with removing braces? I will never find the
| lack of clear demarcations (relying on indent) easier than
| braces.
| rhn_mk1 wrote:
| Isn't an indent a clear demarcation?
| zmmmmm wrote:
| Only if you forbid tabs ...
| goodpoint wrote:
| Not at all.
|
| If it was code, an indentation error would often not compile
| or show errors or fail tests.
|
| Configuration in YAML is much worse: most of the time an
| indentation error goes undetected until an application starts
| misbehaving.
|
| Significant whitespace is perfectly ok for code but a huge
| footgun for YAML
| dylan604 wrote:
| tabs or spaces for that indent?
|
| it makes a difference on how it is parsed, so it's more than
| a devs preference
| kevincox wrote:
| It really doesn't matter. Just force the leading indent to
| be exactly the same bytes. If indent moves between two
| values where one isn't a prefix of the other raise an
| error.
| aimor wrote:
| Literally, yes.
|
| But I find it incredibly annoying to estimate indentation
| when lines are wrapped in an editor (or webpage). Or, to a
| lesser extent but still throws me off, when multiple blocks
| end at the same line. Or when pasting blocks into another
| block, and having to double check to make sure the
| indentation was carried over correctly. I like editors that
| visually show indentation characters.
| andybak wrote:
| Visual clutter, familiarity to non-coders. Curly braces are
| almost never used outside of programming and are ugly to boot.
|
| My benchmark for yaml/JSON alternatives is "how would I feel
| explaining it to a busy, sceptical client?"
|
| If the intended audience is purely developers, then sure. JSON
| (with the addition of comments and trailing commas) is just
| fine.
|
| White space has the additional advantage of agreeing with
| itself. Other demarcations can have issues where the
| indentation and the structure contradict each other.
| diob wrote:
| My google ability didn't see anything, but are their any case
| studies that show it's more readable? I'm happy to accept
| that it is, but I can't help wondering if research has been
| done or it's mostly gut feeling / anecdotes / aesthetics.
| zippergz wrote:
| I haven't found "this needs to be indented exactly the right
| amount or it won't work" to be much easier for non-
| programmers than "this needs to be enclosed in braces or it
| won't work." Most people have at least experienced
| parentheses in math (albeit maybe decades ago), so it's not
| an entirely foreign concept. Either one requires a bit of
| learning, but I think most people are capable of it, so any
| improvement in non-coder familiarity seems minor at best, vs.
| the very real costs.
| szastamasta wrote:
| Again the dreaded Cobol argument. We had to struggle with a
| lot of this in the past: Cobol, SQL, YAML, BDD. All this
| would be much easier without this nonsensical idea that
| nontechnical people will read code. They won't. Making code a
| bit more like prose doesn't make it readable for nontechnical
| people. Yet we again and again make our life harder - ugly
| syntax rules, no code completion, no auto-formatters.
|
| Please stop making code easy for non-coders. They don't want
| to read it. They never did. They just want this damn box to
| work.
| andybak wrote:
| Wrong use case. I'm talking about asking them to write it
| edit these files.
| gmadsen wrote:
| as a counter argument. I work in robotics, where many
| operators will look at and change settings in a yaml file
| during testing. They do not have software skills outside of
| this.
| eitland wrote:
| My educated guess then is you could have gotten them to
| change "settings" in C, Java or basically anything.
|
| Just put the file in the root folder, and keep it as
| simple as possible and you should be fine? I mean, if
| they manage to write yaml correctly and consistently C is
| no match?
| gmadsen wrote:
| maybe? the dynamic loading of the configs kind of
| restricts it to a markup language.
| forrestthewoods wrote:
| Significant whitespace is evil. It's just begging for
| copy/paste bugs.
| diob wrote:
| That's just display though, if you have to show it to a
| skeptical client, why not run it through a browser that shows
| it without braces? It's the same as showing a webpage instead
| of the html.
| andybak wrote:
| I was specifically thinking about asking clients to edit or
| write these files. Isn't that a fairly common use case for
| config languages?
| diob wrote:
| That's a good point someone brought up in a different
| comment. I haven't really dealt with those scenarios, so
| honestly I'll accept that as a reason.
|
| I wish it could be displayed with braces though, I wonder
| if someone already has built that as an extension for
| editing / viewing yaml files.
| colejohnson66 wrote:
| YAML is a superset of JSON. In other words: any
| syntactically valid JSON file is a valid YAML file. If
| you want braces like JSOM, but not quoted strings, YAML
| supports it.
| initplus wrote:
| If programmers find getting YAML indentation correct
| difficult how are non-programmers going to fair?
| deadbunny wrote:
| If the HomeAssistant subreddit is anything to go by its
| their biggest complaint (HA configuration is in YAML).
|
| With that said if they weren't complaining about white
| space they'd be complainit about missing semicolons,
| missing/extra commas, missig equals signs, missing
| closing )]} or whatever.
| CJefferson wrote:
| You could run a formatter which adds braces if you like?
| jstx1 wrote:
| This makes zero sense to me. Why do config files out of all
| things have to be accessible to non-coders?
| remram wrote:
| Because they're not code?
| andybak wrote:
| Because we are asking them to write these things in many
| cases.
| jstx1 wrote:
| I'm not buying that you genuinely have a target audience
| of "I trust this person with config files but their eyes
| are too gentle to see a curly brace".
| kesor wrote:
| 927
| it_does_follow wrote:
| > YAML is considered by many to be a human friendly alternative
| to JSON
|
| I'm not disagreeing with the author here, but as someone old
| enough to remember the rise of XML as a data transmission format
| (and Erik Naggum's masterful rant against it[0]), it's strange
| because historically speaking both XML and JSON were also
| popularized as more "human readable".
|
| I would be curious how many HNers (and even more so newer
| developers outside the HN-o-sphere) have worked extensively with
| or even written parsers for binary (or otherwise non-human
| readable) file formats. Writing an MP3 metadata parser used to be
| a standard exercise for devs looking to level up their
| programming skills a bit.
|
| It personally feels weird to me that we would keep pushing for
| more "human readable" data formats when the world is increasingly
| removed from one where non-programmer humans need to read data.
| Keep your data in whatever format make sense and let software
| handle transforming it to a more readable or more efficient
| format depending on the needs, even if humans can't read it (they
| shouldn't need to!).
|
| On top of all that my experience has been that JSON leads to more
| atrocities than XML (while fully agreeing with all of Erik
| Naggum's points about that) and YAML creates even worse horrors
| than JSON. It seems we'll soon be approaching eldritch horrors if
| we continue to pursue human readable data exchange formats.
|
| 0. https://www.schnada.de/grapt/eriknaggum-xmlrant.html
| foxfluff wrote:
| As an embedded sw dev working on things that interface with
| legacy devices, I have written lots and lots of binary parsers
| (as well as serial, net, and ipc protocols). I've also reversed
| some binary formats used by games, etc.
|
| I like binary formats for things that are simple and don't
| change too often. However, I still love not having to waste
| days on studying yet another bespoke binary format & parser for
| things that are complex and don't work right for whatever
| reason. So when performance isn't a concern and you aren't
| working in a size-constrained environment, I do find that
| "human readable" formats are often worth it.
|
| As a practical example, I recently hit a bug where KiCad moved
| some custom footprints' pad shapes around after saving &
| reloading. And I quickly discovered that the footprint files
| are just S-expressions and relatively self-descriptive so I
| fixed my issue in five minutes with vim without ever needing to
| look at docs or code. That kind of thing is super convenient.
| Later I discovered that other users are likewise working around
| the program's limitations using a text editor or custom scripts
| to manipulate things KiCad won't do for you; for example, to
| create a repetitive pattern of components in a layout more
| complicated than a grid.
| pdimitar wrote:
| Naive question: is it viable if we started using Lua[JIT] for
| configuration, like NeoVim and likely others do?
|
| Can Lua's interpreter be compiled without some "dangerous" APIs
| enabled (whichever those might be) and thus be made viable as an
| embeddable and isolated configuration engine?
|
| I'm just getting sick and tired of all the half-baked
| configuration formats and want to look for something that's both
| more flexible but still strict and unambiguous. I wonder if it's
| possible?
|
| As I said, naive question.
| Areading314 wrote:
| Surprised they didn't call it YAYAML
| deknos wrote:
| what's wrong with dhall?
| de_keyboard wrote:
| Does Dhall have a .NET implementation yet?
| Smaug123 wrote:
| You can always convert it to JSON before consumption.
| FridgeSeal wrote:
| I'm confused: why would Dhall need a specific .net
| implementation?
| dmitriid wrote:
| Because you don't want to bring in a separate language with
| a separate runtime with unknown interop story just to read
| config files?
| thefifthsetpin wrote:
| I don't like YAML and would like to move on, but I hope we don't
| move onto this.
|
| I think it's crazy that when I add a string to an inline list, I
| may need to convert that inline list to a list because _this_
| string needs different handling. I think it 's crazy that
| "convert an inline list to a list" is a coherent statement, but
| that is the nomenclature that they chose.
|
| I don't like that a truncated document is a complete and valid
| document.
|
| But what is most unappealing is their whitespace handling. I
| couldn't even figure out how to encode a string with CR line
| endings. So, I downloaded their python client to see how it did
| it. Turns out, they couldn't figure it out either:
|
| >>> nt.loads(nt.dumps("\r"),top="str") '\n'
| nsonha wrote:
| the boolean thing is dumb, otherwise yaml is a fine format
| evanmoran wrote:
| Keeping leaf values as strings is quite elegant. I've found the
| auto conversion to be inconsistent across yaml implementations in
| different languages.
| Animats wrote:
| The trouble is that people insist in writing trees using plain
| text editors. Trees should be written in tree editors. Then you
| can't get the delimiters wrong.
|
| "NestedText was inspired by YAML, but eschews its complexity. "
|
| Mandatory XKCD: https://xkcd.com/927/
|
| Fun fact: HTML was invented because SGML was "too complicated".
| mongol wrote:
| What is a tree editor?
| iamleppert wrote:
| I've never liked YAML. For whatever reason, it always feels like
| working in a mine field. It comes from the same cargo cult of
| people who think the problem with human machine formats is that
| it needs to be "clean".
|
| Clean, of course to them means some bizarre aesthetic notion of
| removing as much as possible. Only it's taken to an extreme. I
| wonder if the same people also think books would be better with
| all punctuation be removed to make it look "clean"?
|
| It's unhealthy minimalism, causes more problems than it solves.
| As soon as I see a project using YAML I cringe and try to find an
| alternative because god knows what other poor choices the
| developer has made. In that sense, YAML can be considered a red
| herring and I'm usually right. The last project I used that
| adopted an overly complex and build-breaking YAML configuration
| syntax had other problems hiding under the covers, and in some
| cases couldn't parse it's own syntax due to YAML's overly broad
| but at the same time opinionated syntax.
|
| Just say no to YAML.
| politelemon wrote:
| I've often heard this argument about YAML being "clean", but
| over time I have realized that they are conflating minimalism
| with cleaninless, when they are two different things. That
| realization is what it took for me to realize why I didn't like
| it. I did _not_ find it clean, I found it "messy" by virtue of
| the increased cognitive overhead. But it is minimal at least
| compared to other formats. Other formats appear cleaner to me.
| [deleted]
| whynotmaybe wrote:
| Mandatory xkcd
|
| https://xkcd.com/927/
| rendall wrote:
| I don't understand this. YAML has limitations. All formats have
| limitations. If a format is too limiting, don't use it. Pick one
| more suitable, or come up with another one, like NestedText (or
| whatever). What is this need to tell everyone else to "move on"
| from using some format because it doesn't sit your specific
| preferences or use case?
| tannhaeuser wrote:
| Especially since the post title doesn't match the linked
| article's heading.
| rendall wrote:
| Yes! Thanks for pointing that out! You're right!
| remram wrote:
| I don't understand this. Opinions are not universal, every
| blogger has limitations. If you don't agree with a HN title,
| don't read it. Pick the next one or read another site. What is
| this need to tell everyone that you don't like them to tell
| everyone to "move on" just because it doesn't sit your specific
| preferences in formulation?
| rendall wrote:
| I see what you did there, but it comes off as mocking and not
| so clever.
|
| The difference between my post and that blog, and your reply
| for that matter, is that I'm not telling anyone not to read
| it. I'm inviting you to comment on why people feel the need
| to tell others to move on.
|
| Here's a good example of how to respectfully disagree:
| https://news.ycombinator.com/item?id=29220994
| firearm-halter wrote:
| The person that creates the config file does not necessarily
| choose the config file format. In the example, github chose
| YAML and everyone using github actions must use it. YAML is
| error prone, as everyone that tests with Python is finding out
| as the add Python 3.10 to their regression tests. This is a
| plea to organizations like github to stop choosing YAML.
| ccouzens wrote:
| YAML is a superset of JSON.
|
| Which means anything that accepts YAML accepts JSON.
|
| So you can write your Github action code in JSON (with a yml
| file extension).
| rendall wrote:
| As not a Python programmer, I'm struggling to understand the
| issue.
|
| Your (or blogger's) claim is that GitHub misparses the YAML
| actions config when it comes specifically to Python? Or that
| YAML is inherently inadequate to the task of representing
| Python's necessary actions?
| kzrdude wrote:
| The Python 3.10 issue is this, in yaml:
| Python_versions: - 3.8 - 3.9
|
| Then we add the new version in our yaml file:
| Python_versions: - 3.8 - 3.9 - 3.10
|
| But _now_ we discover that 3.10 is parsed as a float, just
| like the other ones were. But the problem is that 3.10
| becomes 3.1, the equivalent float value! With 3.9 we didn
| 't notice this problem.
| initplus wrote:
| YAML's lack of limitations is the source of much of the
| difficulty with the format. The numerous ways to represent
| basic data (arrays, strings etc) is a common source of error.
| YAML doesn't have enough limitations!
|
| And you can't pick what config format a tool you need uses.
| rendall wrote:
| But, GitHub, specifically has very specific guidelines on
| what to write and how to format it, and will give pretty
| detailed error messages if it's badly formatted. Not to
| mention tooling to format and highlight. I'm not seeing how
| the proposed NestedText is inherently free from those same
| issues: the need for tooling, guidance, error messages. Is
| the claim that it's easier?
| IceWreck wrote:
| Huh, no. YAML is a superset of JSON. So valid JSON is valid YAML.
| This is sometimes suprisingly useful. Also, YAML is used
| everywhere and like the other user pointed out, has mature well
| tested libs for almost every language.
| tuukkah wrote:
| Indeed: "YAML version 1.2 is a superset of JSON"
| https://en.m.wikipedia.org/wiki/JSON#YAML
| TedDoesntTalk wrote:
| How is YAML a superset of JSON? never heard that claim before.
| BiteCode_dev wrote:
| Any valid json can be parsed by any 1.2 yaml parser. That's
| how it gained popularity in the first place: you didn't have
| to migrate. Like ascii and utf8.
| rudian wrote:
| You can turn any piece of a YAML into a JSON object and it
| will be read just as well.
|
| This YAML: user: name: Ted
|
| is equivalent to this YAML: user: {"name":
| "Ted"}
|
| which is equivalent to this YAML/JSON:
| {"user": {"name": "Ted"}}
| erik_seaberg wrote:
| YAML supports tagged nodes and multiple documents in a
| stream, which can't be represented in standard JSON. You
| could make up conventions, but only your parser would
| support them.
| Spivak wrote:
| While true, this is what being a supperset means. What it
| means is that any JSON document is, _without modification_
| , valid YAML document and can be read with a YAML parser.
| andoriyu wrote:
| That's exactly the case. Any YAML 1.2 parser can parse
| any valid json document as is.
| NoThisIsMe wrote:
| It just is: Any valid JSON is valid YAML with the same
| semantics. It was intentionally designed that way (though not
| from the start iirc).
|
| Basically take JSON, make quotes optional for strings and
| make curly brackets optional if the object is indented
| properly, and boom you've got (something like) YAML.
| yuuu wrote:
| If all JSON is YAML but not all YAML is JSON, then YAML is
| a superset of JSON.
| imglorp wrote:
| Another JSON superset is HOCON. The H is for human.
| _bsless wrote:
| Modest proposal - The real problem I see with JSON is it's not
| rich enough. Not a problem if you're using EDN
|
| https://github.com/edn-format/edn
___________________________________________________________________
(page generated 2021-11-14 23:00 UTC)