back to article House of pain: If YAML makes you swear, shout louder – the agony is there for a reason

Enterprise IT is about solving problems, but for those who work in the field there's an index of irony in that statement. The further you go towards sales and marketing, the more problems are solved; the further towards the engine room of making this stuff work, the more problems appear. Which is why JetBrains feels so …

  1. Fruit and Nutcase Silver badge

    syntactic white space may be the stupidest idea since God invented the pigeon – and allowing non-quoted strings is as unpleasant as clothes-optional day at a trampoline club.

    Alas, the perpetrators are free to go and introduce the same on their next creation

    1. chuBb.

      And this is the only reason yaml is crap and needlessly complicated, otherwise its just json without curly brackets and non quoted strings instead, which to my mind strikes me as some obsessive micro optimisation for a very niche task where it might have made a difference at google scale and broke out into the wild....

      1. Claptrap314 Silver badge

        At Google scale (or really, even 0.1% of that), the microoptimization that you do is protobuffs or something very much like them. Human readabilty is of 0 concern.

    2. Missing Semicolon Silver badge

      Syntactic whitespace

      And yet the creators of Python walk the Earth unchastised!

      1. jake Silver badge

        Re: Syntactic whitespace

        "And yet the creators of Python walk the Earth unchastised!"

        Really? I don't know what Earth you live on, but on mine professional programmers have been pointing out the obvious issues and pitfalls with Python for thirty years or so.

        1. Anonymous Coward
          Anonymous Coward

          Re: Syntactic whitespace

          For inquiring minds, what would you list as the most offensive/problematic issues and pitfalls with Python?

          1. Anthropornis

            Re: Syntactic whitespace

            You really don't know ?

            Two for starters: copy and paste where you found an example of something, but paste causes that slithering mass to decide the whitespace is wrong. And from a couple of months ago trying to work out where a piece of python2 was sudenly failing by adding "print01" etc to tell me where it had reached before it error'd and the 10th print statement of 12 causing 'unexpected indent'.

            1. Anonymous Coward
              Anonymous Coward

              Re: Syntactic whitespace

              @Anthropornis:

              You really don't know ?

              What they're thoughts are? No, not until they tell me. Believe it or not, people will differ on what they consider the biggest issues are. I'm after what this person believes them to be.

              That you can be voted down for asking a perfectly reasonable question speaks volumes about how slashdot-like these forums are becoming.

          2. doublelayer Silver badge

            Re: Syntactic whitespace

            I like Python, but there are several issues that at least have to be acknowledged, even if we're going to decide we can deal with them.

            The syntactic whitespace got us here, so let's start with that. It's annoying because the boundaries of control flow are no longer clear. An expression could be inside or outside a block just because someone forgot to change the indentation. In languages which use braces to mark blocks, that will result in a compiler error under most cases. This makes errors more likely. It also makes copying and pasting code harder, because there's a chance the person re-indenting something which does not originally align will make a mistake which won't be caught until runtime starts to go surreal. I don't exactly mind syntactic whitespace if only because it makes others indent properly, but that's not usually a good enough excuse for it.

            There are a few other design decisions of Python which can be counterproductive. It has almost completely eliminated pre-runtime checks of any kind. That makes the interpreter simpler, but it makes simple typos or incorrect thinking harder to resolve. A few language features complement this problem. For example, the fact that objects and classes are completely open and that variable creation and variable binding (assignment) are syntactically identical. This opens new classes of typos because nobody will check that the variable you want exists until right when you ask for it. Fuzzing is therefore more important in Python just to catch things another language would get during compilation.

            These issues are not shallow, but nor do they eliminate Python as a useful language. I think it's great for prototypes or for various tasks which other languages make painful. I would much rather use Python to do string parsing than most other languages. And a well-tested Python program can be a core component in something without problems. Still, it's imperfect in various ways.

            1. Short Fat Bald Hairy Man

              Re: Syntactic whitespace

              I definitely do not like python. Not these days. But then, there are so few (if any) languages that I like.

              Of course, designing a new language to remove all problems for ever would be pure

              https://xkcd.com/927/

              And yes, no type checking!!!! How can that be a thing!! White space I seem to have adjusted to. Pretty easily, actually.

              A language for small tasks that got out of hand.

              Enough ranting, back to tensorflow or pytorch or whatever it is I am supposed to be using. Or was it flask?

              1. teknopaul

                Re: Syntactic whitespace

                Ireallylikethedifferencesbetween2&3

          3. teknopaul

            Re: Syntactic whitespace

            did you read the title of your comment as you posted?

            1. Anonymous Coward
              Anonymous Coward

              Re: Syntactic whitespace

              @technopaul

              The title is irrelevant in my opinion as to the biggest issues a poster in the underlying chain may perceive. I have generally found the syntactic whitespace to be divisive. Some love the way it forces uniform indentation within the code base and others hate that an indent alters interpretation. It's almost a religious debate to some. It depends on what you've used before and who you've worked with. Some people are just f*cking lazy and will seemingly deliberately randomise their code layout just to sh*t you.

              I was asking to see if they had more technical issues - use of GIL prevents me doing X/Y/Z etc.

    3. spireite Silver badge

      Python..... same

      I guess it took its lead from Python... similarly blessed/damned by whitespace alignment and other PITA requirements........

  2. Anonymous Coward
    Anonymous Coward

    "Where open source has taken over " " recreate new and better ways of working"

    It's the other way round - open source made everything more complex and less manageable, since everybody and its dog, cat, hamster stated to design new silly ways to make things without thinking too much, and many others found them interesting just because they were different - "fashion driven development".

    And of course, you had to be able to handle everything in VI and human-readable files because building management tools requires time and RAD tools which are sorely lacking in the new open source world based on primitive languages for which UI are an afterthought. Plus the graybeard who believe the command line is the only virile way to use a computer.

    IT is going backwards. It's adding complexity without the proper management - going towards and heavily fragmentation even it the OS kernel may be almost the same. And because some advanced management tools required a bit team of dedicate developers, they don't exist where there's no money to be made.

    Devs blamed the Microsoft INI file - they are replication it over and over - with more complexity and less tools to quickly and safely manage them. YAML is a perfect example - a format nobody needed but for reason I never understood was quickly adopted. Maybe it's still better then configuration files written in JSON - a format born for data exchanged (no comments, for example), but quickly used by clueless programmers for configurations also.

    Open source is driving IT into a mess of brittle application built with pieces collected all over the internet and with a plethora of different standards mish-mashed into something barely usable and with an ugly UI. The latest supply-chain attacks are only the beginning.

    1. Anonymous Coward
      Anonymous Coward

      Re: "Where open source has taken over " " recreate new and better ways of working"

      Nah, Open Source just brought the "mess of brittle applications built with pieces collected all over the internet and with a plethora of different standards mish-mashed into something barely usable and with an ugly UI" into the light.

      The IT world before open-source popularity was everything you just said, but hidden behind black-box "appliances", proprietary non-standard APIs, and closed corporate fiefdoms.

    2. boblongii

      Re: "Where open source has taken over " " recreate new and better ways of working"

      OS devs are not always better than proprietary devs, and in the case of Python generally and YAML in particular they have done a bad job. But bad jobs in IT are hardly new.

      I never had a problem myself with the ini-file concept; the registry replacement (not an open source solution, of course) was far worse and the fact that systemd has replicated the same fuckup is certainly disappointing.

      But, yes. YAML is complete garbage.

      1. Anonymous Coward
        Boffin

        Re: "Where open source has taken over " " recreate new and better ways of working"

        Devs are devs, some are good (like us?), some are mediocre, and some are shite.

        The problem with open source programming is that all of them can do it and some remarkably bad programs, like YAML and Python, have resulted.

        It reminds me of Excel users. Anyone can use it but some can use it in truly abysmal ways.

    3. jake Silver badge

      Re: "Where open source has taken over " " recreate new and better ways of working"

      Wow. You've certainly bought into the general Marketing line of anti-FOSS bullshit.

      Out of curiosity, what flavo(u)r was the coolaid?

      bash: VI: command not found

  3. b0llchit Silver badge
    Facepalm

    Pain transfer

    Let's replicate the useful bits of mammalian pain by teaching our robot servants to feel it.

    I'd settle for the programmers feeling the user's pain!

    Maybe we'd get better software then? (or are most programmers simply masochists?)

    1. Claptrap314 Silver badge

      Re: Pain transfer

      A little from column A, a little from column B in my experience.. :D

      Look up "false laziness". We have way, WAY to man programmers with false laziness.

      1. jake Silver badge

        Re: Pain transfer

        What we have is way too many programmers who can't program(me), but can sure say"Me too!" to whatever language/tool/methodology is the fad of the day.

      2. yetanotheraoc Silver badge

        Re: Pain transfer

        duckduckgo false laziness

        First links are not relevant, but interesting enough to distract me from the search.

        relevant: https://yousuckatracing.wordpress.com/2020/03/24/suck-less-at-sim-racing-6-10-false-laziness/

        Let me paraphrase, in case that becomes a dead link: Being too lazy to learn the efficient way to do things, so needing more total work to accomplish the task.

        Well I will say I already knew this idea, but did not know it had false laziness as a label. If pressed I would have called it false economy. My own approach is iterative, depending on how many times I have been (will be) asked to do the task. Start with the false lazy way, ASAP switch to the true lazy way. If that requires code, turn on a macro recorder during the false lazy way. The macros get refined, then scripted, more and more automated each iteration.

        Actually I think of false laziness as a kind of technical test. Programmers are looking to code a new way around the task. Power users are looking for an existing way. Good managers are looking for someone to create a custom way around it. Poor managers will accept any old existing solution -- even if the solution is to a different problem, in which case they call it "leveraging" (nice word, thanks, I know I don't want to work for you). Good line workers know there must be a better way and are happy to be shown. Poor line workers don't want a better way, they are paid by the hour and consider it "job security".

  4. cantankerous swineherd

    ini files ftw.

    1. sreynolds

      Yeah, they are so well defined and unambiguous (no need to escape anything there and CR (\r) and/or NR (\n) are not whitespace. and allow for some kind of tree like hierarchical structure. Problem was solved in the late 80's and early 90s so why is this registry a thing?

      1. Claptrap314 Silver badge
    2. Malcolm 1
  5. Terafirma-NZ

    was ok until I got deep

    Until recently I had only done light work with it but recently I have been doing lots with docker etc. and it really is. code that looks 100% identical fails on one file and works form another.

    Worst of all is the new fav IDE for YAML is VSCode and that thing sucks with YAML just search vscode not copying white space and see the history of code doing weird things with not saving white space or not copying it etc. Ok accept for the whole YAML is built on white space.

    Then yes once you start getting deep and have to deal with strings quoted and not but then also that whole "I'm cool and can do my array on a single line" vs the next guy who types it all out making it slower to read as you mentally switch between styles.

    No that note whats everyones fav editor for YAML and anyone write in another format and convert?

  6. Steven Raith

    Ubuntu server networking

    Discovered the other day that Ubuntu Server uses Netplan these days, which uses YAML for it's syntax in the config files.

    Took me over an hour to get the YAML right.

    What the hell was wrong with a .conf file for networking?

    Steven R

    (Yes I know, old man shouts at clouds, or more likely, cloud-inits, etc)

    1. chuBb.

      Re: Ubuntu server networking

      This is where my hatred of yaml and by extension netplan stems from

      1. bazza Silver badge

        Re: Ubuntu server networking

        Likewise here...

        It's an appalling mess.

    2. jake Silver badge

      Re: Ubuntu server networking

      One of many reasons I use either one of the BSDs or Slackware for servers. Canonical has all the same problems as Redmond and Cupertino, and for all the same reasons.

    3. Steven Raith

      Re: Ubuntu server networking

      Well, at least it's not just me.

      Phew.

      Upvotes for all!

  7. Jusme

    YAML...

    ...bastard sibling of python. Love-children of the scented chip-fat smoking top-knot brigade. The the sort of "languages" I'd invent as a kid before understanding more formal methods. Full of inconsistencies and hacks to make them more generally useful. Unfortunately they'll probably take over the world by sheer weight of numbers.

    (Well I got more upvotes than down last time I posted that, just about.)

    1. Throatwarbler Mangrove Silver badge
      Thumb Up

      Re: YAML...

      Upvoted for "Love-children of the scented chip-fat smoking top-knot brigade."

    2. Warm Braw

      Re: YAML...

      I don't now, and never have, understood why these things have to be text files in the first place. They're intended to be processed by a computer, so I'm not sure why humans, particularly those whose local cultures use a different language or form of writing or don't use "." as a decimal point should have to learn their pernickety syntax. That's precisely what we have computers for.

      1. yetanotheraoc Silver badge

        Re: YAML...

        "why these things have to be text files"

        Right, they don't *have* to be text files. Text (.ini, .conf) is great for simple cases, e.g. a long list of myvar = somevalue. Binary (.reg, .info) is great for complex nested structures, and/or needing strong types. And then somewhere in the middle -- too complex for straight text but not complex enough to be worth the cost of a binary format -- we have .yaml and .json. By definition there will never be a perfect solution for that middle ground, just better or worse solutions.

        Not a big fan of significant whitespace (well, except for EOL). If I need the equivalent of Reveal Codes in my editor, it's effectively a binary format anyway. So in the end I agree with Warm Braw.

      2. doublelayer Silver badge

        Re: YAML...

        "I don't now, and never have, understood why these things have to be text files in the first place."

        Because, as annoying as the formats can be, it is significantly more annoying to go to configure a program only to find that its configuration file contains large chunks of nonprintable characters interspersed with strings that look significant. Of course some programs can get around this by having a full-featured configuration system in their GUI, but there will be programs which don't, especially those core system components which don't live inside a window on the user's desktop. This is a lot more important if there is ever more than one of them. If the user needs to change configuration options or debug something breaking, a text-based format for inputs is going to make a lot more sense to someone willing to go to the effort than a binary replacement.

      3. jake Silver badge

        Re: YAML...

        "They're intended to be processed by a computer"

        Incorrect. They are intended to be processed by both Humans and computers.

        "so I'm not sure why humans, particularly those whose local cultures use a different language or form of writing or don't use"

        Because like it or not, just as Arabic drove early science, Latin (Koin Greek, Aramaic, et al) drove early Christianity, Deutsch drove later science (etc., I won't continue. You are quite welcome.), American English is the lingua franca of tehintrawebtubes and of the FOSS world. This isn't a good thing, nor is it a bad thing. All it is is an accident of history.

        However, it will change over time. If there is one thing that's a dead cert, it's that language mutates. Much to the deep dismay of all those Internet "Queen's English" nazis out there.

        Running code trumps all.

        Please understand Godwin's Law before invoking it, or I shall laugh at you.

  8. Muppet Boss

    JSON5

    YAML is effectively bastardized JSON with comments. There are various JSON supersets which address JSON limitations without uglifying it. I personally prefer JSON5 (https://json5.org/) and I hope it gets more attention (and more good-quality parsers for various languages to make it ready-to-use).

  9. Claptrap314 Silver badge

    Why the hate?

    Twenty-five years ago, my mentor quoted to me, "There are two kinds of languages--those that suck, and those that no body uses." YAML was created to fill the gap between JSON & XML. JSON's view that all of the world is a forest of six things is obviously incomplete. XML is not even a little bit human-readable.

    Personally, I find YAML easier to parse than even pretty printed JSON. YMMV on that, but JSON simply cannot admit loops in the node graph, or indeed, object references of any kind. To me that is a fatal limitation in many cases.

    But human readable does not imply human writeable. I have NEVER written a YAML file, or changed the structure of a document by hand. The wise course of action is to read it into an object into your REPL, update the object, and write it back out.

    It appears that a significant part of the complaint against YAML has to do with K8s. First, as I mentioned, if you are hand-editing a YAML file, you're being a masochist. Second, the recommended YAML library for go is broken. (The Billion LOLs attack on XML broke go's reader & no other...) Third, and the complaint here appears to be self-contradictory, if the files in question aren't to be read by humans, then certainly YAML is not the best way to go (and Google is REALLY big on protobuf) but how would anyone know unless they were reading the files?

    Active white space is problematic--if your editor thinks it can/should replace things for you. But that's the real problem--don't edit YAML files. Generate them.

    1. Anonymous Coward
      Anonymous Coward

      Re: Why the hate?

      At least you mentioned XML, which no one else did above, for the reason your post started with. They'd not been around when XML was ubiquitous, at least in hype.

      YAML was *reaction* to XML's extreme pain inducing characteristics. As was JSON.

      You want to do just a couple config values? Fine, INI files are great. Huge numbers of values, with file format validation? XML and schemas are perhaps advisable. At quantities else, either of INI or XML will hurt.

      1. Claptrap314 Silver badge

        Re: Why the hate?

        There are validation schemas with JSON. If you want to see how far it can go, check out OpenAPI. I've not tried to track down validation schema for YAML, but in principle, I see no difficulty in doing so. I will note that because everything in a YAML document has a tag, a YAML validation schema could be done on a by-tag basis. I therefore suspect that could could get an adequate validation schema for YAML entirely in JSON.

    2. bigtimehustler

      Re: Why the hate?

      If you are generating them from objects anyway, then why not just generate JSON? It is possible store whatever config state you want in a JSON, if you model the data correctly. Your DTOs can be commented to explain what the parts of the JSON are.

  10. Anonymous Coward
    Anonymous Coward

    If you think YAML is bad ... try YAPTU ... python based templating where you get all the joys of syntactic whitespace in the python code expect you have to add '+' '=' or '-' chars at the end of the indent to indicate a line that is python and not template, plus have to add a dummy comment on the end of python lines that don't already need a terminal ':' and meanwhile all this python based indentation is running in parallel with any indentation requirements of the text being templated. Finally, if you make an error my experience is you just get a "somethings is wrong somewhere" message as its exits.

    When I first encountered python and someone explained the syntax etc to me my firsrt reaction was "its Lisp without the brackets" ... turns out brackets can be useful!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like