26 ms·

That's a Lot of YAML

• IlliOnato 3y ago
  After a long and painful experience I now use ad-hoc INI format for very simple configuration files and XML for anything more complex. Yes, XML is verbose and complicated, but all other formats I tried, be it Json, YAML, Toml, for me they all have nasty gotchas and/or inconveniences.
• tangjurine 3y ago
  Website is hard to read on mobile
  • bradrn 3y ago
    It’s hard to read on desktop, too: > ps. By design, this website is as usable as YAML.
  • AndyKelley 3y ago
    it's art bruh
• banditelol 3y ago
  I ended up reading from their github https://github.com/ghuntley/noyaml/blob/master/index.html https://github.com/ghuntley/noyaml/blob/master/index.html
• Ahmed783 3y ago
  [dead]
• JohnMakin 3y ago
  these complaints are misguided. yaml isn’t the problem, it’s whatever the tooling is around it. Yaml is pretty easily transcribed 1:1 to json, these same people will never complain about json because the tooling around it is better. Yet, yaml is usually easier for me as a devops/SRE person to work with because it is more human readable than json and super great tools like helm use it almost exclusively. for me? json, yaml, dgaf. Yq works as well as jq.
  • globular-toast 3y ago
    Makes me wonder if a kind of meta-format for config would be useful. Like, this is the internal data structure, you provide the mapping from whatever config format you like. People would then be free to open the config in whatever format pleases them. The project maintainer might have arbitrarily picked YAML, but your editor seemlessly opens it as TOML, for example.
    • arp242 3y ago
      Not all concepts from YAML map 1-to-1 to TOML, and vice versa, so this won't really work as it's a lossy process. Using a restricted subset of both could work, I suppose. But seems a lot of hassle over a minor issue.
  • matsemann 3y ago
    I'm happy to complain about JSON as a config format as well.. Yaml is so hard to get right, a misplaced dash or indentation in a list and you're screwed but it's still passable, just does something else than expected. It's not really human readable either, it takes a lot of brainpower (at least for me) to understand what belongs together in a list or how things are grouped together. Much more than for instance xml where it's obvious. Yaml only barely works, because many editors have added support to help you write k8s config. Otherwise it would be impossible.
    • JohnMakin 3y ago
      It’s essentially the same data structure under the hood. It’s the interpreters/parsers that are the issue at least in this complaint. “Norway” being interpreted as “NO” boolean false is something that sounds very weird to me, almost to the point of being hyperbole, and I’ve worked with “yaml” (mostly helm and simple configs) for years and dealt with really ridiculous parsing issues. Usually though they’re really easily resolved. Yea, you shouldnt put a lot of logic in your configs. yaml doesnt do that. the tooling does. and templates can be simple and easy to read and DRY principles can put you into traps that make your code harder to maintain than it should be.
• roydivision 3y ago
  Formatting the web page as YAML is a false argument against the markup language. YAML isn't meant to be read like that. The web page would look terrible in any of the alternatives, JSON, XML etc.
  • FireInsight 3y ago
    And don't forget "Yaml Aint a Markup Language". It's actually apparently a data serialization format, which I don't get, because it's obviously designed to look nice to humans and not computers.
    • pavlov 3y ago
      It’s not uncommon that humans have to read serialized data without a tool to transform it for display. I’m not saying that’s a good argument for using YAML, but IMO it should be a consideration for any data format that’s not binary. The worst data formats are “not binary but still unreadable.” Apple Cocoa XML serialization format, I’m looking at you.
    • username332211 3y ago
      Markup languages aren't supposed to look nice to humans? They are supposed to produce documents that do. Markdown is a markup format that looks nice to humans, but neither XML nor HTML are particularly nice. Some XML-based formats like Microsoft Office documents are downright incomprehensible without specialized tools.
      • brabel 3y ago
        Markdown is NOT a serialization format.
        • hk__2 3y ago
          > Markdown is NOT a serialization format. It obviously is, as you can see in [1] or [2]. [1]: https://en.wikipedia.org/wiki/YAML https://en.wikipedia.org/wiki/YAML [2]: https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formats https://en.wikipedia.org/wiki/Comparison_of_data-serializati...
• FireInsight 3y ago
  There are a lot of problems in YAML, but I think the main real problem is trying to put logic inside configuration. YAML is still one of the nicest human-readable and -writeable data formats if it is only used for data and not logic. CI/CD always has some logic, and it's almost never in pure YAML but also has some weird templating going on. Like, please, couldn't you just have a real API for some real programming language.
  • nikeee 3y ago
    In my experience, the more a language is able to do, the more it will be used in ways that overcomplicate stuff. People will just pull in abstractions because they think it is needed. This is why I always avoid using Turing complete programming languages as a configuration format. I've spent hours using a JavaScript debugger to step through AWS CDK. A simple, dumb yaml/Json/whatever file wouldn't have that problem (and it was a small project, the complexity wasn't needed). Sure, there might be use-cases where you need to be able to do more. But until now, I've never seen that. This is why I also prefer JSON over JS in JS tool configuration. This is why webpack configs get so messy. As soon as people can use a real language, their "DRY sensor" (or other bad applied paradigm sensor) triggers and they make things more complicated. Being declarative also makes it easier to follow standard practice and supports tooling. Imagine the package.json would actually be like a build.gradle. That would make things much worse.
    • galangalalgol 3y ago
      I like toml even more than json, but the real issue to me is that we, or most of us, have this subtle drive to generalize, and the more things we can make comfigurable the better. But as it is said, when something is fully configurable that is like saying it isn't done and assembly is required. Also, we end up designing declarative domain specific languages. But I don't want to program in json, yaml, or toml. They aren't made for that, and it hurts me. For rust the clap crate helps put the brakes on if you agree on a simple rule, anything that is a config file parameter is a command line argument and environment variable. It is one struct that gets populated by the combination of those things. If you wouldn't make it one of them, don't make it any of them.
• maweki 3y ago
  When students send in homework through our e-learning platform, we receive all the submissions in a large-ish xml file. We read the submissions, pass it on to some (static) analysis and example execution, and write out (per exercise) a yaml-file with all the submissions, grading hints, and fields for our comments and grading, etc.. We then generate reports/statistics/feedback pdfs from the yaml files via markdown+pandoc. For us yaml works great, as it's easy to add further feedback in markdown syntax (just correctly indented "- you missed a `NOT` here"). Via the different escape methods for block text, we can print the SQL submission nicely formatted without escape characters, etc., even when the students uses all the different SQL-delimiters. It is all plaintext, so we just use a text editor and we store that all in git and have accountability over grading. We have everything archived machine readable, so that we may test new static analysis stuff on past submissions. But also having to write CI-pipelines and home-automation configurations in yaml, I understand the struggle.
  • unscaled 3y ago
    Stripping indentation for embedded text is probably the nicest feature YAML has. In TOML you either just forget about indenting multi-line strings (which makes them less readable) or you have to remember to putting a backslash at the end of each line. Neither option is ideal. This makes YAML pretty nice for DSLs or configurations that need to embed markdown or other textual format and give it an edge over something like TOML. But I won't put the entire blame for "YAML fatigue" on all the CI and DevOps tools that chose to use it as the carrier format for their DSLs. YAML has major issues which the OP site outlined very well: - The famous "Norway issue" (solved in YAML 1.2) - Leading zero parse as octal (solved in YAML 1.2) - Overeager type-coercion for numbers, dates, times etc. can be confusing. - Different modes for processing multi-line strings can be quite confusing. - Unsafe serialization (not an issue for modern parsers, but you need to be careful when using YAML on a veteran language with dynamic features like Ruby, Python or Java). All of these are issues with the YAML spec itself.
• kome 3y ago
  people really need to study and use xml
  • endre 3y ago
    the only valid answer
    • exploderate 3y ago
      At least you can do "<data> Have fun putting this in <format>JSON</format> :-></data>" in XML.
• mogoh 3y ago
  > # If SQL were built on YAML looks better than normal SQL to me ...
  • orwin 3y ago
    'looks better' isn't 'works better', sadly.
  • brettermeier 3y ago
    Hm, maybe it's because I'm so used to SQL, but I had to lol about the yaml example, I think it's quite nasty to read and I'm glad that SQL looks different.
    • tgv 3y ago
      It can be abbreviated to SELECT: [num, name] FROM: [customers] WHERE EXISTS: SELECT: [name] FROM: [orders] WHERE: AND: - EQUALS: [customers.num, orders.customer_num] - LT: [price, 50] It's not that different from formatted SQL. It's uglier, though, IMO, and more error prone. But to hate YAML for the fact that SQL looks less familiar in it, is a weird take.
      • brettermeier 3y ago
        > But to hate YAML for the fact that SQL looks less familiar in it, is a weird take. True, it's a little side hustle that's funny but doesn't necessarily make much sense.
      • throwaway46281 3y ago
        I guess the broader point they're driving at is that attempting to port familiar programming constructs to YAML DSLs will result in this kind of ugliness. If that's true though, it's a bit too subtle for my tastes.
  • contravariant 3y ago
    Good luck trying to get the joins to work though. Not that joins in SQL use a particularly intuitive notation. At the very least it doesn't make it obvious you can usually swap the order of joins around without affecting the end result.
• devjab 3y ago
  YAML is great in my opinion. What isn’t great is how hard we have made the deployment part of CD. I’ll admit that our setup within Azure DevOps isn’t amazing, but the fact that you have organisations with multiple teams or 5-6 operators working on these tools is just mind blowing to me. Maybe not for Google, but for us in regular boring enterprise where we top out at 50.000 concurrent users or typically way, way, less. It was easier for me to deploy enterprise web-applications to our on-prem IIS that had all the load balancing and networking and whatever else done by less than a quarter of a full time employee back in the early 00’s than it is for me to deploy the same damn thing into our “modern” setup. Yes, there are advantages to our modern pipeline. We’ve moved far beyond the whole “it works on my computer” thing and we’ve increased the quality control immensely by putting up much better acceptance gates, but the actual deployment? That’s a damn nightmare in 2023. Again, this is likely not an issue for many HN programmers who work in actual tech companies, or in companies with good dedicated DevOps teams, but in the world of non-tech enterprise CI/CD has frankly never felt worse in my career. I guess you can chose to blame YAML, and the loads of it you need to do anything and how hard templating seems to be. But in my opinion it’s far more of an organisational issue than a technical one. We need CD tools that are far more automated, so that it doesn’t become the job of the developer to describe the infrastructure as code. It’s fine that you can do that, but the reality is also that we are asking millions of developers to deploy infrastructure that they might not have the slightest clue how works. I’ve never met a developer who didn’t just want to hand off their container and then have all the networking and “server stuff” just done for them. And when you don’t, you end up with a lot of VNETs and subnets that nobody really knows how works and that your organisation is losing a ton of money on because your developers didn’t know you could so /x and then start the subnet where it came to.
  • jiggawatts 3y ago
    The cloud is the new mainframe. You work offline on a "job definition" of some sort, submit it to the proprietary shared system, wait in a queue, then you receive a log file generated by a system you don't control. You can't run the proprietary system code locally on a workstation, and hence the inner loop is often tens of minutes long at best, hours or days at worst. There's no preview, no "what if" mode or "dry run". You work directly on production even if it's called "test" because there's only one system. The real problem isn't YAML. It wouldn't matter if the pipelines were scripted in God's own programming language. Software development on workstations instead of central timeshare mainframes became wildly popular because it allowed a dramatically faster inner loop, it allowed isolation from production environments, and it gave control back into the hands of the developers. Current-generation CI/CD pipelines generally undo all of that. Single-box Kubernetes reintroduces most of what made workstation-based development good, but it is still a very new system and has many teething issues. PS: A related issue to yours is that there are great solutions for the solo dev doing click-ops for one app, there are great solutions for megacorops doing automation at scale for thousands of devs, but in the middle where you have a couple of enterprise devs managing a few dozen apps its just madness.
• Draiken 3y ago
  Did something happen recently to get the YAML hate train going again? I get it. YAML is not perfect. Neither is JSON, TOML, XML or even code as configuration (Xmonad anyone?). They each have pros and cons and projects/technologies take those in consideration and pick one. Not sure I see the point in hating on one specific configuration language. If it was that bad, nobody would use it. And if you still think it's bad anyways, you can always improve on it. But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat. But the fact is that most times the difference between them is not substantial, so the effort to make any kind of switch so you can shorten Norway is simply not worth it.
  • w0m 3y ago
    > Did something happen recently to get the YAML hate train going again? I was all onboard the yaml hype train until I finally started using it more for the daily job. json > * in my stogy brain.
  • davexunit 3y ago
    Write a JSON parser. Now try writing a YAML parser.
    • xigoi 3y ago
      So JSON is better because it's easier to write a parser for it? By this logic, Brainfuck is the best programming language.
  • sanitycheck 3y ago
    I think the reason everyone jumped ship from XML to JSON was that JSON is comparatively very dumb - and dumb is quick to grok. Then some of us realised JSON is actually too dumb for many things, and instead of going back to XML we made JSON Schema, OpenAPI, etc. Others of us thought that the main problem with JSON is that it's not human readable and writeable enough. So we came up with new formats like YAML. [EDIT: My timing is wrong here, sorry.] Unfortunately being human we could not resist making it much more complicated again, thus increasing cognitive load. There have been many times when in order to really understand a YAML file (full of anchors and aliases, etc) I've had to turn it into JSON. This is ridiculous.
• hnthrowaway0315 3y ago
  I hate YAML based ETL solutions that uses jinja to render YAMLs to Airflow DAGs, with a passion.
  • verdverm 3y ago
    Can you add a link to an example of this? Working on another Yaml post with a dedicated section for this
    • hnthrowaway0315 3y ago
      Sorry they are all company resources so I cannot share a screenshot. But imagine writing dags using yaml, so you would have a field called "dag_id", one called "schedule", things like that.
      • verdverm 3y ago
        fair enough Yeah, declarative DAGs 101 lol(?) Does python code get generated from the Yaml, or does python code load the Yaml and do Airflow tasks? I never thought specifying DAGs in airflow / python was that difficult. What problem is this solving? I have a thing that does CUE + text/template = anything maybe what you are describing is like the prior Yaml based input we used to use? [1] https://github.com/hofstadter-io/hof https://github.com/hofstadter-io/hof [2] https://docs.hofstadter.io/getting-started/code-generation/#data--templates https://docs.hofstadter.io/getting-started/code-generation/#...
• chrismorgan 3y ago
  I have seen this page more than a few times, but it took me until this viewing to realise that the document shown is not valid YAML, because it uses tabs, which YAML rejects.
  • ghuntley 3y ago
    This must be fixed. Send through a pull-request please.
    • throwawaaarrgh 3y ago
      Would you please read the YAML spec before creating an entire website ranting about something you clearly don't understand???
      • ghuntley 3y ago
        Send through a pull request deleting the entire website if you so desire. Art. yesyaml.com is available for registration. Go make it.
• orphea 3y ago
  Related discussion: https://news.ycombinator.com/item?id=37586580 https://news.ycombinator.com/item?id=37586580 (625 comments)
• marginalia_nu 3y ago
  I feel like we keep making the same mistake with these configuration formats. Most of the problems with YAML are the problems that XML had in the early Spring Java days, and most of those problems stemmed from "programming" by gluing together software via configuration files. This isn't a good pattern regardless of how you format the files. The moment you start to reach for schema definitions and validation for your configuration language, you should consider that a warning sign. We've been down this road before. It does not lead to a good place.
  • myaccountonhn 3y ago
    I really like what dhall-lang (https://dhall-lang.org https://dhall-lang.org) is doing in that sense. It manages to strike a nice balance between power and simplicity from the start.
• siva7 3y ago
  Wholeheartedly agree. I would propose that we sit together and develop a new standard. Contact in bio.
• devoutsalsa 3y ago
  I wrote a YAML parser for fun a few years back (https://hex.pm/packages/mark_yamill https://hex.pm/packages/mark_yamill). I haven't looked at it in years, and to be honest I can't even remember if I finished it. That being said, the thing that turned me off to using YAML in my own projects was there was subtle behavior I didn't want to have to understand or remember. JSON isn't perfect, but it's easier for me to reason about.
• somecommit 3y ago
  Now I understand why devops always took years for fixing any little ticket
• gpderetta 3y ago
  This is the inner platform effect. As an application grows, its configuration expands until it became a programming language, except bug-ridden, underspecified and with terrible ergonomics. The configuration-bankruptcy is declarer and a new configuration format is picked. Rinse, repeat. The format itself is not without blame of course: the more flexible it is, the more easily can be repurposed into a (bad) programming language. Having committed this mistake over and over, these days, I would pick the simplest config format possible (even .ini might be too powerful) for basic configuration, and delegate more complex "configuration" to a real programming language (possibly the same language the application is written in).
• ahmedfromtunis 3y ago
  I'm curious: on average, how many hours does one typically spend directly interacting with YAML on a *yearly* basis? I'm not sure my experience is typical, but the creator of this page probably spent more time dealing with YAML building said page more than I spent working with YAML for MY ENTIRE LIFE. I get it, the language has its flows, and they are apparent even with my limited exposure to it, but I don't think YAML would constitute the major part of anybody's workday. People probably spend more time and energy hating on YAML than actually working with it.
  • tiew9Vii 3y ago
    If you deal with the platform side of things with the popular products your life is YAML. Kubernetes definitions, Helm, Ansible, a lot of popular CI tools use it.
  • letmeinhere 3y ago
    You would be very surprised. Infra people can very easily spend the vast majority of their (non-ops) time in the REPL from hell, manually editing static configuration files, visually inspecting (because there is rarely any local let alone static validation), pushing, waiting for minutes, and then trying again.
    • treebeard5440 3y ago
      As an infra team we had this same problem. We also had a lot of different configuration types that were required for each tool, often several types being mixed within the same repo. After a couple of issues with syntax errors making it further down the release than we would have liked we ended up building a single tool to validate all of our configs rather than using a bunch of separate tools. We added it as a quality gate in our pipelines which really helped. We open-sourced it for anyone else going through the same issue: https://github.com/Boeing/config-file-validator https://github.com/Boeing/config-file-validator. It's written in go and runs on Windows, MacOS, and Linux.
  • rbonvall 3y ago
    I think that's precisely the problem with YAML. By being so unpredictable, it turns from "format I use without thinking much about" into "format that makes me spend a lot of time finding out what's wrong this time". Maybe you and I haven't been bitten personally by YAML idiosincracies yet, but just learning about examples like the "Norway problem" and the "negative GPS coordinates bug"—and thinking how frustrating must have been to figure those out in the first place—makes me shudder.
• tragomaskhalos 3y ago
  If I need to grok a complex nested data structure then YAML is a 'mare, but JSON is not much better - even with nice IDE support. TBH end up just running a script to flatten the whole lot into lines of key-value pairs, where each key is.the.full.path.from.root, with numbers for array indices - NOW I can see what's going on. I believe this is similar to how TOML is structured, albeit people criticise it for being too verbose as a result!
  • PhilippGille 3y ago
    For anyone looking for such a script, there's some CLIs that make it easy. One is `yq -o props` [1], another way is to use `yq -j` or `yj` [2] to convert to JSON and pipe it to `gron` [3]. [1] https://github.com/mikefarah/yq https://github.com/mikefarah/yq [2] https://github.com/sclevine/yj https://github.com/sclevine/yj [3] https://github.com/tomnomnom/gron https://github.com/tomnomnom/gron
  • verdverm 3y ago
    http://www.youtube.com/watch?v=XNBqBWO4y08 http://www.youtube.com/watch?v=XNBqBWO4y08 This shows a TUI I've been working on to grok, munge, and ETL config. It leverages CUE, but it's not required
• miragecraft 3y ago
  You can just quote everything in YAML and skip the auto-typing. Or if you have a choice of markup language just use XML. You can’t have your cake and eat it too, either use XML and deal with the verbosity or use something else with less markup but more error prone. I personally prefer XML as verbosity is the least annoying problem to deal with.
• hk__2 3y ago
  (2018)
• goku12 3y ago
  I would rather read K8s manifests in yaml than any of the alternatives. The important point here is that config/serialization languages are like programming languages in one key aspect - there is no single language/format that covers every need. The choice is based on the tradeoffs - there are cases where yaml is better than toml and cases where the inverse is true. There are also a lot of cases where people prefer a bit more features like Turing completeness (eg. jsonnet. Ansible playbook format is a counter-case where yaml gets retrofitted with ill fitting features). And there are cases where such features don't really make sense (like serialization of state in K8s). It's not like anyone if forcing you to use one format. For example, K8s spec can be in yaml, json or jsonnet. Choose what feels most natural, instead of sticking with the default and complaining. Conversion between formats is cheap anyway.
• chmod775 3y ago
  Is there a yaml without all the bells, whistles and magic? Like the syntax (it doesn't turn non-techies off from changing some config values), but aren't a fan of all the magic whistles that can shoot you in the foot if you don't have near-encyclopedic knowledge of them. The spec is too big for something that's supposed to just live in some of our configuration files.
  • iainmerrick 3y ago
    I think JSON5 is fairly close to this: https://json5.org https://json5.org I reckon the only thing it's missing to be truly accessible to non-techies is that string values still need to be quoted, i.e. you can't have: key: this is my value (I'm definitely not saying it would be a good idea to allow quotes to be dropped, just that that's the only potential stumbling block I see for non-techies.) Edit to add: oh, hmm, I guess trailing commas are fiddly too. Possibly I want some even laxer variant of JSON that lets you use just newlines! :P
    • ftrobro 3y ago
      Hjson is very similar to JSON5 but allows quotes to be dropped and can use newlines instead of commas. There are implementations for a lot of different languages, I myself contributed the C++ implementation. I wanted something smaller than Yaml but more lax than JSON, found Hjson to suit my needs perfectly. https://hjson.github.io/ https://hjson.github.io/
      • iainmerrick 3y ago
        This looks really nice, I like it! JSON5 is elegant in that it's purely a subset of JavaScript (exactly as the original JSON is). But in practice that doesn't really gain you much besides a familiar syntax, and Hjson looks simple enough that the slight differences from JS shouldn't be a problem. The real problem is how to persuade people to use something like this. For the few cases where JSON isn't already entrenched, YAML and TOML and the like have already salted the earth.
      • Dylan16807 3y ago
• benrutter 3y ago
  This is unquestionably hillarious, and there are for sure some questionable "features" of yaml. But all this yaml hate recently seems to be hate that would be better directed at the garbage CICD toolkits that come with things like github, azure dev-ops etc. YAML is good for human readable configuration, with some notable caveats. But its terrible for being a secret programming language where the only way to execute it is to put in a PR request, commit to a live branch etc.
  • oblio 3y ago
    We basically need Restricted YAML. No 1000 ways to say true/false. No 1000 ways to have strings. No significant whitespace in config files (also helps out with the 1000 types of YAML strings). Etc. A subset of YAML that drops all that garbage. And yeah, the CI/CD stuff should also use... a sandboxed programming language. I think Lua and Tcl can remove functions and language constructs in a sandboxed enviroment. Pick one of those, or improve it slightly (make Lua 0-index based if you so care), and then use that.
    • zufallsheld 3y ago
      There already is strictyaml: https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml
      • oblio 3y ago
        Cool, get back to me in 2040 when it's adopted by Ansible, Github Actions, Bitbucket, Kubernets & its menagerie :-p
        • hahn-kev 3y ago
          There's no reason you and your team couldn't choose to use it today no?
          • verdverm 3y ago
• networked 3y ago
  I think Jinja-in-YAML is very much an antipattern. It seems to come from not designing for enough programmability from the start (and then from people copying successful projects that took that route?). The page mentions some alternatives like Dhall and Jsonnet. Two more to consider: 1. Write a configuration library for a real programming language. Have this library generate a JSON configuration file that is treated purely as an inspectable artifact, not something to edit by hand. The user will have their configuration as tooling-enabled code checked into version control (hopefully). That it will be harder to make an emergency fix directly on the server has its downsides and upsides. (What was the first prominent piece of software to implement this idea? I kind of got it by osmosis.) 2. Starlark. It is a non-Turing-complete language derived from Python that was originally developed for the Bazel build system. It has several implementations (I am not sure how deeply compatible they are) and now Python bindings (https://github.com/caketop/python-starlark-go https://github.com/caketop/python-starlark-go for starlark-go, https://github.com/inducer/starlark-pyo3 https://github.com/inducer/starlark-pyo3 for starlark-rust).
  • baq 3y ago
    > 1. Write a configuration library for a real programming language. Have this library generate a JSON configuration file that is treated purely as an inspectable artifact, not something to edit by hand. The user will have their configuration as tooling-enabled code checked into version control (hopefully). That it will be harder to make an emergency fix directly on the server has its downsides and upsides. this is the route Amazon chose with CDK. it kinda works... but it really feels like you're building a rube goldberg machine to do anything non-trivial. how much of it is the CDK and how much is cloudformation plainly sucking I don't know.
  • mdaniel 3y ago
    I also think Jinja in YAML is an antipattern, but I think that due to them using the default block and expression characters of "{%" and "{{" both of which are yaml characters and thus every single such occurrence needs to be quoted, versus the very sane "${{" used by GHA or even "<%" and "<<" (running the risk that, yes, "<<:" is a yamlism but is not legal jinja) If you meant that having any executable inside yaml (e.g. not just picking on jinja, but "a yaml document is not code") then I fear that ship has sailed because people realized that inverting the literal parts and only sometimes having executable parts makes for a great way to ASP/JSP/PHP up some content If I wanted start a sibling flame war within this thread, we'd talk about HCL and for_each :rolling_eyes: (but, for clarity, please don't talk about it, or at least not here, submit your own noHCL.com link)
• tryauuum 3y ago
  I like writing yaml
  • gilcot 3y ago
    metoo
• beaviskhan 3y ago
  The vast (VAST) majority of the "YAML sucks" examples are solved just by quoting all your weird literals. YAML is definitely annoying at times (list of maps get weird in a hurry, for example, and significant whitespace almost always bites you sooner or later) but these kinds of articles seem disingenuous at best.
  • lmm 3y ago
    > The vast (VAST) majority of the "YAML sucks" examples are solved just by quoting all your weird literals. But none of the examples you see do that, and your tools won't do that. The whole YAML ecosystem nudges you into writing your stuff unquoted, and it works most of the time and breaks just often enough to trip you up in production.
    • oblio 3y ago
      Worse than that, even if you do that... you run into the 11 (I think?) types of YAML strings: https://yaml-multiline.info/ https://yaml-multiline.info/
      • Spivak 3y ago
        People shit on YAML then happily use Python that has just as many strings. '', "", f'', f"", b'', b"", """""", "" "", '' '', r'', r"" Then there's docstrings which have special language support, textwrap.dedent, type annotation strings, several different interpolating systems and most people don't even know some of them. YAMLs strings are overblown and are just the result of having a few modifiers. Of all the things to complain about having ways to make chucks of text readable is the weirdest one. Don't even dare look at how many weird strings bash has.
        • oblio 3y ago
          1. I don't use Python happily. 2. I think bash is a bad tool and we just can't get rid of it because it's ubiquitous and people are used to it. Stockholm syndrome. I wish something like Oil shell or Nu shell would take over, ideally a shell which passes objects, not strings.
• mrjin 3y ago
  Are those examples that bad at all? Check Helm charts yourselves... Once spent hours to figure out why something failed coz the error messages were so cryptic and it turned out only two extra spaces...
• micw 3y ago
  The very last thing (Don't forget the extra line break otherwise all shit goes to hell) is not valid. There is the ">" operator that "replaces a single newline by space but keeps empty line as newlines" and the "|" operator that preserves newlines. So in the example they just need to use the right operator and all is fine.
• woile 3y ago
  I think what's missing is an easy way to describe schemas, field types and documenting the meaning of the field (of course you can use json schemas with yamls, but it's an external file). I know of a new bunch of new tools which all look interesting. I feel like most of the time, they miss an easy way to parse using your programming language of choice, and you end up having to convert from cue -> json -> load in python. - nickel-lang - cue-lang - kcl-lang - dhall-lang
  • verdverm 3y ago
    CUE is adding a WASM runtime, so there will be an ability to write complex or custom functions in the language of your choice. Not sure if this addresses the issue you describe. I'm certainly doing what you do to get CUE into Python, while Go has that native feel for CUE
• unscaled 3y ago
  I believe YAML has serious issues and I would not be using it as a configuration format. But I think a lot of the criticism around YAML misses the mark. YAML is not excessively overused as configuration language. It is not dominant like XML was back in its heyday. TOML has a pretty strong mindshare, and many projects are still using JSON or XML. I would pick TOML over YAML any day for this usage, but I still think YAML beats XML and JSON (just think about comments and terrible merge resolution whenever you add an item to an array or an object). But YAML does reign supreme in the world of DevOps-oriented DSLs. YAML is more suited for DSL compared to alternatives, like TOML, JSON, JSON5 or XML: - YAML is the least verbose of all alternatives (especially XML, but even JSON5 and TOML). - YAML requires the least of amount of "syntax noise" on top of your DSL. The "syntax noise" is mostly limited to indentation, colons, dashes (for arrays), indented text block markers and occasionally quotation marks. JSON, JSON5 and TOML require quoting all string values and explicitly marking arrays and object boundaries, which make the DSL seem less fluent. XML is even worse. - YAML supports indenting multi-line strings, so you can easily embed other formats. This makes adding markdown descriptions (in Swagger/OpenAPI) or embedded shell scripts (in YAML-based CI/CD DSLs) a breeze. - YAML syntax is hierarchical. The same is true for JSON and XML, but not for TOML. TOML syntax only has two fixed and assymetrical tiers of hierarchy: sections and key-value pairs. Hierarchy can be achieved while parsing, by grouping sections hierarchically, but this is not reflected in the syntax, and this property makes TOML ill-suited for DSLs. Of course, TOML was never meant to be used for DSLs - it's was designed as a configuration language, just as JSON was designed to be a simple data exchange format and XML was designed as a document markup language. But if you had to choose any of the format above to base your DSL on, YAML seems like the natural choice. What is the best alternative to YAML then? Probably writing your own parser and removing all unnecessary cruft that you keep to make your DSL fit the YAML straitjacket. And that's the real problem, and the real reason why YAML is overused: parsing YAML is easy, but writing your own custom parser is hard. Sure, most languages have at least one easy to use library that lets you implement a basic parser based on PEG or parser combinatorics quite easily. But even then you have to deal with all the fun things like: ambiguities (or lack thereof[1]), the limitations of whatever parsing technique you've chosen, tokenizing newlines and indents and parsing a token tree that is still not as clean and easy to parse as YAML. YAML is still two or three order of magnitudes easier than even writing the simplest parser, so most tool writers pick up it for writing their DSL. This is the age-old "worse is better" principle. It is faster and easier to release and iterate on YAML-based tooling, so most projects pick up YAML and the ones that pick up YAML tend to both ship and iterate faster, and then go ahead to capture the market. > IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat. Maybe not in a heartbeat, but I do think most of the "YAML alternatives" out there didn't even try to address DSLs. Maybe we should admit defeat on the make-your-own-parser front and design proper DSL carrier language that can be at least somewhat better than YAML. [1] https://jeffreykegler.github.io/Ocean-of-Awareness-blog/individual/2015/03/peg.html https://jeffreykegler.github.io/Ocean-of-Awareness-blog/indi...
• pornel 3y ago
  This is made worse by the fact that you need to write for a specific structure/schema, but typically you have no validation for it, and no immediate feedback on errors. You tweak a line, push, wait, check if it worked, rinse, repeat. It's even more infuriating when YAML-consuming tools silently ignore extra fields. You get some dash or colon wrong, and then it just doesn't work, and it won't tell you why.
  • Spivak 3y ago
    You can validate YAML with JSONSchema and it has sold editor support.
  • capital_guy 3y ago
    Yeah, this is where it really gets painful. CI/CD systems like GitLab don't include linters for their yaml configs so you're just shooting in the dark trying to get it work for push after push. it's a terrible way to make a system
• pgt 3y ago
  EDN (Extensible Data Notation) is a subset of Clojure: https://github.com/edn-format/edn https://github.com/edn-format/edn It is: - Unambiguous - Streamable - Extensible - Whitespace-insensitive, but there are formatting conventions for readability
  • ldhough 3y ago
    So much better than the alternatives, really hope it starts catching on outside the Clojure ecosystem.
    • waffletower 3y ago
      Indeed, it translates into and out of JSON quite well, and is much more human readable. A much much saner format than YAML. However, EDN is less hospitable to non-Lisp code blobs and heredocs, which limits its adoption IMO.
  • waffletower 3y ago
    Not precisely whitespace-insensitive, as whitespace is required for element demarcation/separation. However, semantic indentation shenanigans are non-existent. Commas are considered whitespace and unnecessary -- which is beautiful.
  • tremon 3y ago
    This is the first data format I've seen that makes explicit distinction between lists and sets, which is good. But I'm not sure what the semantic distinction is between lists and vectors: in my mind, arrays and linked lists are implementation details of the data structure in code, not the data format.
    • waffletower 3y ago
      The distinction between lists and vectors manifests from the same two distinct Clojure collection types. They are syntactically distinct within the language and are present to provide homoiconicity -- code as data -- Clojure lisp expressions can be represented in EDN. Vectors, [], are typically the preferred collection literal.
• webjunkie 3y ago
  Does somebody else have manually written or at least edited Hasura permissions in YAML? Well that is for sure is a lot of YAML.
• spion 3y ago
  The more I look at it, the more I think that Deno is actually a perfect fit for infrastructure as code. The first reaction I get is usually "What, JavaScript!?". Here is why its better than it looks like. Deno easily runs TypeScript without a compile step. TypeScript is a very mature, developer friendly language that was designed to model the super complicated types often seen in JS. This includes unions and intersections which help you model complex rules between optional properties, as well as template literal types which can help you restrict string constants. As it happens, those same types of objects are present in our configurations. TypeScript is also flexible about how much you'd like to model. Do you want only properties with really nice autocomplete with docs from the language server? Sure we can do just that. Do you want to only allow strings that look like a time duration for that property? Can be done too with template literal types. You choose where to invest your energy. Building abstractions on top of IaC is seen as painful and obscure. TypeScript has tools to help you avoid that, such as api-extractor: https://api-extractor.com/ https://api-extractor.com/ - it can enforce that all your function abstractions are documented and it can generate that documentation for you. The larger ecosystem also comes with a lot of ready-made codegen tools that can help, from small modules such as json-schema-to-typescript (https://www.npmjs.com/package/json-schema-to-typescript https://www.npmjs.com/package/json-schema-to-typescript) to larger mature projects such as jsii and https://github.com/cdklabs/json2jsii https://github.com/cdklabs/json2jsii . They can be used to build the tooling to import things like CRDs and other external schemas. What about running arbitrary code, launching rockets, turing completness? This is where Deno comes in, with its permissions model (https://docs.deno.com/runtime/manual/basics/permissions https://docs.deno.com/runtime/manual/basics/permissions). You can allow only a subset of commands (lets say, `helm` and `kustomize`, while you're migrating away from them), a subset of (writable) directories, accessible network hosts - or none at all. What about the pains of managing JS modules? Deno lets you import files directly from URLs. It also allows you to set private tokens in env vars to ensure the imports succeed: https://docs.deno.com/runtime/manual/basics/modules/private https://docs.deno.com/runtime/manual/basics/modules/private - as a result, you can manage your IaC libraries the way that makes sense to you, without dealing with the unwieldy package managers of the node ecosystem.
• kunley 3y ago
  This is why I started to craft my own format: BCL, https://github.com/wkhere/bcl https://github.com/wkhere/bcl Will not immediately help in all cases of YAML usages, but at least can be a cooler way of defining resources in a Terraform-like style. In fact, it's already helpful as a replacement for HCL in one internal project, that was a final motivation to hack it. In a bigger picture, I have no idea how to help with YAML omnipresence in Kubernetes. More than a half of my problems at a $daily_job is how crude is consolidating a final Helm chart from different sources. I am not saying that Helm would be inherently a bad tool or my company has chosen pretty bad way of using it - I guess everyone is doing their best considering the ciscumstances. But manipulating textual templates with semantic whitespaces is just too error prone, and the detection of errors happens too late. I dare to say - Kubernetes would do much better with custom format based on a C-like syntax, instead if trying to prove how cool YAML is, especially when it isn't.
  • craftkiller 3y ago
    Have you seen ucl? https://github.com/vstakhov/libucl https://github.com/vstakhov/libucl It seems very similar.
    • kunley 3y ago
      Thanks for the link! Yeah, ucl looks syntactically similar. On the other hand, I am not sure if it has expressions, and the variables usage is limited - they need to be registered in the parser, so they are existing outside of the config file; plus, they seem to represent just text. My assumption was to use variables in the same file, to make the content more modular/DRY, and to evaluate expressions using these variables. Moreover, variables and expressions have basic types: int, float, string and bool. This is not an artificial need, I will give you concrete examples what I want to have in the config file: - port numbers increased from a base value (int arithmetic) - recalculated frequency/throughput values (float arithmetic) - fields enabled if some other condition is true (comparisons, bool arithmetic) - names concatenated from text and numbers What else... in BCL variables are internal to the file; I want also to resolve the information existing external to the file, which would be: env varables (planned builtin function getenv) and ideally, output of executing command (like shell's $(), also planned). With this I can express easily and shortly quite complex configurations. Actually thanks a lot for your comment, because answering this makes me realize I should put such information in the README of my project, maybe in some more structured way.
• ranting-moth 3y ago
  There is another fundamental problem that exaggerates the yaml loathing: If you're on the dev team, you solve the problem by programming. You also leave and/or create other problems for the devops team to solve because of microservices, 3rd party integration, etc. Depending on your dev environment, this cycle can range from incredibly quick to incredibly slow. If you're on the devops team, you're often left with solving the problem with a configuration file only. The dev cycle for that is usually horrendous both in time and feedback on each iteration. Anything that gets in your way becomes a victim of your wrath and anger.
• iknownothow 3y ago
  I guess it's just me but that website is quite readable on desktop. I mean, all I'm seeing is perfectly legible prose and satire while still being a legitimate config file. I literally would share this website as proof of Yaml's readability. As to your frustration with logic and code being stuffed into YAML, I totally get it. Everyone coming up with their DSL, I'm guilty of it too. I think YAML unfairly takes the blame for unnecessary abstractions built on top of it. YAMLs only fault being, that you actually can write DSLs with it easier than with anything else.
• jqlive 3y ago
  YAML is ummm confusing in ML training. Not a fan, but then again there’s not a better choice. I’m with the crowd that YAML shouldn’t have logic in it.
• meatjuice 3y ago
  cool website
• baz00 3y ago
  This is my favourite turd: - 07 - 08 Results in [ 7, "08" ] due to assumptions about octal and strings. This assumption was discovered deep within some templated YAML generated by templated something else three levels down and resulted in a complete k8s cluster failure for us, but only the 08 cluster! It worked in the first 7.
  • hersko 3y ago
    Really?? How can this possibly be right?
    • paulddraper 3y ago
      YAML parses the value as a number if possible. 07 is the octal number 7. 08 is not a number.
      • HankB99 3y ago
        Missing piece: And in some languages, a number with a leading zero is interpreted as octal.
  • ghuntley 3y ago
    Author of the website here. Send this in as a pull-request please.
  • throwawaaarrgh 3y ago
    > This assumption was discovered Did you read the spec? Or did you just start using it assuming you knew how it worked? Whatever generated that clearly wasn't serializing its data using a library, or it would have converted the type into the correct format.
    • baz00 3y ago
      It was somewhere in the middle of a helm chart we imported. So we're building on the shoulders of stuff no one knows how to use.
• coding123 3y ago
  Then use Json, your yaml readers can understand that. Now please move along.
• efitz 3y ago
  GenX: “Here’s XML, it can be used as a data exchange format and here’s a tool ecosystem to ensure structure and correctness” Millennials: “That is way too much text, it’s like way longer than an SMS message. And everything’s on the internet. Here’s JSON, which is much shorter and more Web 2.0.” GenZ: “Bra, all those squiggly lines are sus, try this YAML. It’s dank, no cap.”
  • nerdponx 3y ago
    If JSON had comments and trailing commas we probably wouldn't have YAML.
    • cryptonector 3y ago
      Use jq then. It has comments, though no trailing commas (we could fix that). As a bonus using jq code as configuration gets you templating for free.
    • totallywrong 3y ago
      Nah, I'd still pick YAML any day.
    • dheerajvs 3y ago
      Both JSON5 and JSONC have those features. There is a discussion[0] on the VS Code repo to use JSON5 format instead of JSONC for the settings file. [0]: https://github.com/microsoft/vscode/issues/100688 https://github.com/microsoft/vscode/issues/100688
  • deafpolygon 3y ago
    IKR, like, it's a solved problem bruv, no cap.
• throwawaaarrgh 3y ago
  YAML is a data serialization format that was never intended to be written by hand. It was intended to be written by programs serializing their data, and read by a human. This is the reason so many people don't like YAML. They don't know how to use it right, and they keep fucking it up, getting pissed off, and not learning their lesson. Don't write YAML by hand and it works fine. And maybe read the spec... While we're on the subject - Did you know you don't have to pick from 3 existing formats? You are allowed to make your own new configuration formats. And you are allowed to make them not be some perfect universal solution for all configuration needs for all programs. Back in the day, every program invented its own configuration format, with features designed just for what that one program needed to do. They were ugly and not based on any kind of "principles" or "best practice" or trendy bullshit found on a social media site for nerds. It was just whatever the user found easiest that worked. No standards, just a wonky configuration that worked great for that one program. And guess what? All those weird formats, they are still around today, because the programs are still around, because they are useful and work. Get off of HN and make something unique that you find useful. Don't ask people on here if it's good, just use it. If it works for you, it's good enough.
  • ojkelly 3y ago
    But YAML _looks_ like it’s easy to write by hand. It looks easier than JSON to write by hand. JSON at least makes it known that you’ll have a better time generating it, that writing it. It’s like those doors that open by pushing them. Some open both ways, some have a handle to grab and open it to you, some have a plate for you to push on. And some (like YAML) have a plate on the side you need to pull, and a handle on the side you need to push.
    • deleted 3y ago
      [deleted]
  • ianburrell 3y ago
    YAML was always intended to be written by hand. It was originally an alternative to XML for "markup language" although it isn't one. It was used for serialization, but JSON quickly won in that realm. But YAML was used for configuration files from the start. A good example is the quoting of strings, that wouldn't be optional in serialization language.
• gilbetron 3y ago
  Joe Beda makes the point of why configuration/DSL "languages" end up having issues in one of his early TGI Kubernetes streams, and it still resonates with me. YAML/JSON/XML/TOML have issues, but the main issue is that configuration DSLs evolve until they become an ad hoc "real" language. Joe describes the issue well here: https://youtu.be/ILMK65YVSKw?t=941 https://youtu.be/ILMK65YVSKw?t=941
  • ianburrell 3y ago
    I like Cue and Dhall that aren't Turing complete which is important feature for configuration language that can be run by someone else. I think some of the problems come from different areas using similar languages. There are data serialization langugages, JSON is good for this. Then there are configuration languages, which need to be human editable, YAML is good for this. Then there are configuration languages that generate configurations. Shoehorning this into YAML/JSON makes a mess. Better to have dedicated language and output JSON for API.
• MPSimmons 3y ago
  I'm guessing that 80% of problems with yaml can be resolved by just ALWAYS using quotes when you want strings.
• footlose_3815 3y ago
  I miss the days of not putting all the settings of a thing into a text file. I'd take checkboxes and radio buttons over esoteric text files that require extra research every time you edit one.
  • verdverm 3y ago
    How do you track and review changes in a click based solution? How do you roll back a bad config ?
    • footlose_3815 3y ago
      YAML is like Regex in the "Now you have two problems" philosophy. It's like using an XML file for what a txt file could do. It demands frankly unnecessary structure and formatting just to be ingested, when it's all serially-read parameters, anyway. YAML isn't the only way to implement parameterization. We could use our imaginations and think of a ton of tried-and-true ways to abstract it. Have you ever done a quick-deploy on a cloud platform? The alternatives just generate all the esoteric stuff for you. Config files generated by guided steps.
• bogwog 3y ago
  Anyone have a suggestion for an alternative to YAML that's easier to write by hand than JSON and also supports nested declarations? ("XML with a fancy text editor" doesn't count) I have a project where I'm using YAML just for that: nested tree-like (data) declarations and reasonably succinct and relaxed syntax. I have run into some of YAML's parsing weirdness occasionally, but overall it hasn't been that bad to deal with when it happens.
  • lelanthran 3y ago
    > Anyone have a suggestion for an alternative to YAML that's easier to write by hand than JSON and also supports nested declarations? ("XML with a fancy text editor" doesn't count) S-expressions. A parser for s-expressions (with no evaluation) can be as small as 300 lines of C code. It'd take a day to write, and can express everything in a way that: 1. Current IDEs and code-editors can semantic-highlight 2. Current IDEs and code-editors can auto-format Add in builtins for setting/getting symbols, and you can also DRY your config with variables and functions. [EDIT: The DRY is optional - if you don't want someone messing up configs down the line, then don't implement any builtins that modify the symbol table, just examine the tree in your program after you have read in the s-expressions.]
    • xigoi 3y ago
      S-expressions don't have associative arrays (maps/dicts/objects), which are very important for config.
      • lelanthran 3y ago
        S-expressions don't have anything. They can represent almost everything, though. Composite data types, nested objects, alists, lists, trees, tables... With only a few primitive additions, you should be able to represent everything, except for bidirectional cyclic graphs.
        • mbakke 3y ago
          But then you have to evaluate things, which brings all kinds of problems. Your parser is no longer 300 lines, and eventually you might snap and throw it all away for a full-blown interpreter which makes dealing with user provided input difficult. I'm actually investigating using S-expressions for describing jobs and systems, but haven't figured out how to safely evaluate them short of running in isolated VMs. Edit: thinking more about this, it is possible to represent all those things without evaluation. It's just awkward to create them... but that can be solved on a different level.
• 89vision 3y ago
  Just build some sort of object model and generate all your yaml. Nobody should be handcrafting it
  • captaincrisp 3y ago
    Then you run into the differences between implementations. No one implements the whole standard. The company I work for had a bug driven by the underscores-in-numbers and scientific notation functionality (`20230101000000_e111111`, a timestamp underscore a git short hash, was parsed as a huge number rather than a string). The serialization library from one language did not implement those features and so did not quote the value in its output, but the deserialization library in the other did and would parse it as a number. This eventually resulted in it becoming null (not sure why, maybe it was too large for the int type in the target language?) but even if it hadn't been we then format it into a URL (to download an artifact) so the fact that our YAML libraries disagree would cause the string value to change and break the download. The YAML standard is too big, resulting in only partial implementations, and the disagreements can result in unexpected value changes. With no handcrafting whatsoever.
• redder23 3y ago
  I recently discovered Strict YAML, it sounds it makes lots of sense but there is only a python implementation. I like YAML, it is super easy to read, I like it for simple configuration, it works good for Ansible, Github actions use it. I never ran into any issues, but reading about it I get why people do not like some parts of it. I think it may have to many features that nobody uses, but the features to cloning and injecting and merging content is are kind of cool, used them once for config that got a lot or repeated stuff.
  • spicybright 3y ago
    I'm not a fan of YAML. But frankly people complaining about YAML is starting to be more annoying. I barely use it and even I can see 80% of these issues are from not putting quotes around your values. Maybe config languages are just really easy to bike shed.
  • hgomersall 3y ago
    There's also a rust implementation: https://github.com/fralalonde/strict-yaml-rust https://github.com/fralalonde/strict-yaml-rust
• woodruffw 3y ago
  On the topic of "shocking deficiencies in markup/configuration languages": I only recently discovered there are some characters in XML that are outright illegal, even when escaped[1]. Implementations vary on whether they actually honor these restrictions, making interoperability an additional issue. As a result, user-supplied input can't just be escaped: it may also need to be base64 encoded or otherwise transformed into a safe alphabet. [1]: https://www.w3.org/TR/xml/#charsets https://www.w3.org/TR/xml/#charsets
• otikik 3y ago
  Do you like YAML? Norway.
• waffletower 3y ago
  Semantic whitespace /facepalm. Clearly willing to burn some karma here in an attempt to remind people of the tragedy at hand.
• sodimel 3y ago
  Oh, I thought of a way to create json with comments by using a small python overhead. I wrote about it here: https://misc.l3m.in/txt/json.txt https://misc.l3m.in/txt/json.txt
• aidenn0 3y ago
  Does anyone use YAML 1.2? It fixes many of the problems with YAML, but I've not seen it in the wild.
• Ayesh 3y ago
  On mobile, it constantly opens the keyboard, and I think it's perfect!
• gervwyk 3y ago
  Enter Lowdefy - Build business web apps in YAML - and its fantastic! Also, founder here so.. Honestly our team is writing more YAML than I think anyone, and we, including junior devs are loving the experience. Check it out! https://lowdefy.com https://lowdefy.com
• jroseattle 3y ago
  That's a lot of JS and CSS to render the page to look like YAML.
• MrPatan 3y ago
  I don't find YAML undertandable. I find JSON very understandable. I think it's another example of the different ways people understand (I don't want to call it "reading") code: "textually" or "visually". I suspect the same subset of people find lisp, coffescript or yaml readable, with the same drive of removing everything that isn't "words" from the code (useless noise!). The punctuation doesn't let them read the code as a text, I guess? and they only build the structure of the code in their heads after a "linear pass" through the code? While myself and others like me are very happy with all the punctuation that makes the structure jump out to us at literal first sight. I build the structure first in my head and fill in the "words" later. I made it sound all neutral-like and all, but it's not, my way is certainly much better. Learn to grok code visually, it's better.
• KerrAvon 3y ago
  Reading the responses to this makes me wonder how many people have read the Mythical Man Month and not made the connection that config files are modern JCL -- the original instance of "this config file format should have been a real programming language from the start".
  • zacharycohn 3y ago
    This is my problem with writing YAML for Home Assistant. You have to do so much code gymnastics to do the simplest things. It tries so hard not to be a programming language that it really should just be a programming language.
• x3haloed 3y ago
  I think I have a solution to keep the peace, if we can all universally respect one rule: Never use YAML outside of the Python ecosystem. That way, people who love esoteric scripting formats that prioritize legibility over correctness, durability, and maintainability can keep all their tab characters, loose typing, and cryptic syntax. And the rest of us never have to! Those of us who prefer C-style syntax can keep our sanity. Edit: OK, I think I've finally got my finger on the crux of the issue here. I think I can't explain this whole thing without being spicy. For C-syntax devs like myself, syntactic whitespace is pure madness. Whitespace is not information or an instruction -- it's formatting. Good formatting is helpful and useful, and good C-syntax devs care about legible formatting. In Python (and YAML), the formatting is instructional information. This has the benefit of making all functional code legible. But why the blazes does code have to be legible to be functional? Imagine working with a YAML coworker. You send them a long message. They reply with, "What? This is nonsense." You suddenly realize your mistake. Without separating your paragraphs with an empty line, you've broken the meaning of what you sent. Adding the empty lines back in and re-sending the chat message, your co-worker can now read what you wrote. Without syntactically-accurate formatting, the information you sent was meaningless.
  • IlliOnato 3y ago
    Generally it's assumed that significant whitespace is a philosophical or even religious issue: some people love it, others hate it, and while both camps rationalize their preferences, it seems it's it: just a strong preference. However, I came to think that the difference is not philosophical. It is just that some tools (text editors, e-mail programs, etc) support significant whitespace well, while other don't. For example, the text editors I use are all set up to display space and tab characters, and to display them differently (usually as a faint dot and a faint mdash, or something). I am used to it, and this does not distract me at all. From my point of view, code is not some random text. We use fixed-width fonts for it that we would not use in a book, we color-code it, I don't see why not make the white space visible. I still have a "philosophical" preference for languages without significant whitespace, but I don't hate languages with it, they are not a problem for me at all. But if the tools you use and love don't have good support for significant whitespace, or you won't make the whitespace visible, or even, you know, use vaiable-size fonts for coding... Well, then you will hate significant whitespace with a passion and consider it pure madness! :-)
• cryptonector 3y ago
  Just use gron!
• cannabis_sam 3y ago
  It’s not that hard, YAML is disappointingly and unfortunately, unnecessarily, extremely ambiguous, which is exactly what you do not want in the contexts where it’s dominant. The solution is uncannily simple tho, fuck YAML, just generate it from Dhall; enjoy the subsequent bliss!
• totallywrong 3y ago
  Funny that a site trashing YAML is actually a great resource for it. I, for one, am more than happy to use YAML, there isn't a better alternative today to write human-friendly, complex configuration.
  • ghuntley 3y ago
    Thanks.
• timcavel 3y ago
  [dead]
• leeu1911 3y ago
  I ran into "NO" problem first hand just the other day. Luckily no production issue. Phew!
• mixmastamyk 3y ago
  Use Strict YAML, the regular version leads to madness. https://hitchdev.com/strictyaml/ https://hitchdev.com/strictyaml/
• drzaiusx11 3y ago
  This is a fun one I've hit: In docker-compose YAML files, when using a container port lower than 60, because YAML parses numbers in the format xx:yy as a base-60 value.
• shantnutiwari 3y ago
  "# ps. By design, this website is as usable as YAML. " An upvote just for this comment! :)
• CyberShadow 3y ago
  YAML would be fine if parsers did not try to guess the type of values. 07 or 08 should not be parsed as integers or as strings, but stored as is until the application requests an integer or string.
• Aerbil313 3y ago
  Nickel (https://nickel-lang.org/ https://nickel-lang.org/) is a new configuration language which builds upon lessons learnt from YAML, TOML, JSON, JSONNet, Nix and many others. Not affiliated. Just want to see the project succeed.