• Little Bobby Tables (unregistered)

    Don't you have access to a Cyrillic font, then?

  • LCrawford (unregistered)

    So Jesse (The New Guy) started writing write-only JSON expressions?

  • someone (unregistered)

    "Easy Reader Version: Strings should be banned"

    Meanwhile, JSON requires all keys to be quoted strings for no discernible reason.

  • bvs23bkv33 (unregistered)

    "коннект" - use it

  • djingis1 (unregistered)

    I have built stuff against various third party API's (all made by the same company) that routinely, after an update, would fail to produce valid JSON. In 2016. These were written in relatively modern .NET. I can only assume that their JSON generating code looked something like this.

  • (nodebb) in reply to bvs23bkv33

    Oh dear. That is spectacularly ... lame.

  • WTFGuy (unregistered)

    But at least he's using the latest stylish "fluent" coding style. Sleek short declarative is so much clearer than stodgy verbose imperitive.

    Buying ever more clueless generations of developers ever more powerful hammers will not end well. Moore's law has saved us from this folly for many years. but it keep doing so much longer.

  • Randal L. Schwartz (google)

    YAML has much more relaxed quoting requirements, and yet valid JSON is a valid value in YAML. It's like best of both worlds.

  • Sole Purpose of Visit (unregistered) in reply to WTFGuy

    I'm not going to defend "self-generated JSON." Well, OK, sort of, because I've tried to use .NET JSON libraries and they are ... problematic. The main problem with the case in hand is that there's no real parsing and no real sanitisation and, for example, a double-quote in the input will crap all over everything.

    But I will defend LINQ's "fluent programming style." It's (in theory) a set operation on a set operation on a set operation. If you want, you can use intermediate vars, and the result will be the same. There's the nasty issue of identifying the null set, which bites most LINQ programmers in the bum, but basically "fluent" is no different from "imperative." Just a matter of syntax elision.

    Now, "fluent programming" as it pertains to object construction or even object amalgamation? Yup, that's a snake-pit for the ignorant and careless. What do you do with a "mid-stream" fluent construct, pray?

  • Sole Purpose of Visit (unregistered)

    It's quite entertaining, however, that if you look at this WTF with the perspective of history, it's actually identical to the old C-style of strcatting things together with a comma on the end, and then stripping the last comma.

    We have learned so much in the last couple of decades. We should consider ourselves blessed. (In a Perl sort of way, obviously.)

  • (nodebb)

    If it weren't for the fact that it is through count, I would have said it was the array of subscripts for the array.

  • Andrew Cooper (google)

    TRWTF is not using String.Join:

    return String.Join(",", Enumerable.Range(0, childrenCount).Select(i => $""{i}""));

  • isthisunique (unregistered) in reply to djingis1

    This is really common when people do eval like:

    eval('[1,,2,,{bareword: val},,];')

    Because you know, it's bandwidth efficient.

  • PotatoEngineer (unregistered) in reply to Randal L. Schwartz

    YAML, alas, is only JSON-compatible-if-the-JSON-is-YAML-compatible. There are completely valid JSON structures that cannot be parsed as YAML.

    Valid JSON that isn't valid YAML: {"thing":"stuff"}

    Valid JSON that also happens to be valid YAML: { "thing": "stuff" }

    Valid JSON that isn't valid YAML: { "thing":"stuff" }

    The difference in the last two? Whether there's a space after the colon. User-typed JSON is almost never valid YAML.

Leave a comment on “Aggregation of Concatenation”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article