• Arghblarg@lemmy.ca
    link
    fedilink
    arrow-up
    66
    ·
    4 days ago

    How does one address the paradox that, as JSON itself is evil, one cannot use it for evil?

    (opinions may vary on the above; but it’s mine, so nyah nyah.)

      • ryathal
        link
        fedilink
        arrow-up
        35
        arrow-down
        2
        ·
        3 days ago

        XML is ok for complex docs where you have a detailed structure and relationships. JSON is good for simple objects. YAML is good for being something to switch to for the illusion of progress.

        • Radioactive Butthole@reddthat.com
          link
          fedilink
          English
          arrow-up
          11
          ·
          3 days ago

          Meh. I just wish XML was easier to parse. I have to shuttle a lot of XML data back and forth. As far as I can tell, the only way to query the data is to download a whole engine to run a special query language, and that doesn’t really integrate into any of my workflows. JSON retains the hierarchy and is trivially parsed in almost any programming language. I bet a JSON file containing the exact same data would be much smaller also, since you don’t list each tag twice.

          • bob_lemon@feddit.org
            link
            fedilink
            arrow-up
            3
            ·
            2 days ago

            I still want someone to explain to me why XML even needs namespaces (which cause about 95% of all issues regarding XML).

            There is a way to separate different XML structures, it’s called files.

          • JackbyDev@programming.dev
            link
            fedilink
            English
            arrow-up
            1
            ·
            2 days ago

            XML is also tricky to parse because people forget it is for documents too. It’s basically like HTML. Mixed content elements are allowed. <foo>hey <bar>there</bar> friend</foo> is valid XML. So iterating over elements is trickier than JSON (which is just key value pairs and arrays).

          • ryathal
            link
            fedilink
            arrow-up
            1
            ·
            3 days ago

            There are parsing libraries, maybe not as many or as open, but they exist.

            • Radioactive Butthole@reddthat.com
              link
              fedilink
              English
              arrow-up
              2
              ·
              3 days ago

              That’s kind of my point though. For being made specifically for the purpose of being machine readable, its kind of a pain in the ass to work with.

              I want a command line utility where I can just

              xmlquery --query 'some/query' --file foo.xml --output foo-out.xml
              

              or in python

              
              import xml
              
              with open("foo.xml", "r") as file:
                  data = xml.load(file.read())
              

              That’s the amount of effort I want to put into parsing a data storage format.

      • DreamlandLividity@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        2 days ago

        Idk, I never used the weird advanced features of YAML, but the basics seems really nice for stuff you want people, especially non programmers, to edit. I generally default to YAML for config files.

      • tinkling4938@lemmynsfw.com
        link
        fedilink
        English
        arrow-up
        5
        ·
        3 days ago

        YAML is (mostly) a superset of JSON. Is the face hugger any less evil than the alien bursting out of your chest?

        • SpaceNoodle@lemmy.world
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          3 days ago

          It’s got enough serious flaws and quirks that I can feel smug hating on it. JSON is far from perfect, but overall it’s the least worst of human-readable formats.

          Only Python manages to get away with syntactical indentation.

          • renzev@lemmy.world
            link
            fedilink
            English
            arrow-up
            4
            ·
            3 days ago

            The complaints about yaml’s quirks (no evaluating to false, implicit strings, weird number formats, etc.) are valid in theory but I’ve never encountered them causing any real-life issues.

            • AnyOldName3@lemmy.world
              link
              fedilink
              arrow-up
              4
              arrow-down
              2
              ·
              edit-2
              2 days ago

              no doesn’t become false, it becomes Norway, and when converted to a boolean, Norway is true. The reason’s because one on YAML’s native types is an ISO country code enum, and if you tell a compliant YAML implementation to load a file without giving it a schema, that type has higher priority than string. If you then call a function that converts from native type to string, it expands the country code to the country name, and a function that coerces to boolean makes country codes true. This paragraph was wrong. The other paragraphs are unaffected.

              The problem’s easy to avoid, though. You can just specify a schema, or use a function that grabs a string/bool directly instead of going via the assumed type first.

              The real problem with YAML is how many implementations are a long way from being conformant, and load things differently to each other, but that situation’s been improving.

              • JackbyDev@programming.dev
                link
                fedilink
                English
                arrow-up
                2
                ·
                2 days ago

                Are you sure? I’ve always heard it the other way around and a quick search for "YAML norway’ gives this

                The reason to why this is problematic in some cases, is “The Norway Problem” YAML has: when you abbreviate Norway to its ISO 3166-1 ALPHA-2 form NO, YAML will return false when parsing it

                Also, YAML 1.2 (2009) changed the format of booleans to only be case insensitive true and false. “No” no longer is false if you’re parsing as a version 1.2 document.

                • AnyOldName3@lemmy.world
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  2 days ago

                  Yeah, looks like I’d remembered it backwards. It’s still an easily solvable problem by not using a load everything as whatever type you feel like function.

                • JackbyDev@programming.dev
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  2 days ago

                  I believe they’re getting themselves confused. no was false prior to YAML 1.2. This is known as the “Norway problem.”

      • jonne@infosec.pub
        link
        fedilink
        arrow-up
        7
        ·
        edit-2
        3 days ago

        It’s still using the lesser of 3 evils, we need a fourth human readable data interchange format.