[umvi]

> Most of the ideas in use today have been discovered decades ago. The big reason for churn is that people don't bother learning about what's been done before, and keep reinventing the wheel.

But on the other side of the coin, do you really want to be locked into a decades-old solution to a "solved problem" forever? Or are there still improvements that can be made to reduce friction and human error?

"Machine/human readable data exchange format? Yeah, that's a solved problem - we use XML for that. What's that? You want to reinvent the wheel? JavaScript Object Notation, are you insane? Didn't you bother seeing which exchange formats are already out there? XML can already do everything JSON can do and more! Plus, JavaScript is the exact opposite of what we value here, get that crap out of my face; like I said, XML is the one true solution to data exchange and forever will be."

[yogthos]

XML and JSON are both examples of the problem actually. S-expressions have existed since the 50s, and they solve all the same problems with a much saner syntax. In fact, if Mozilla marketing execs didn't insist on Java style syntax for Js, and it kept Scheme style syntax we wouldn't even need HTML and CSS today. We'd have a single syntax that would cleanly express code, styling, and layout.

[marcosdumay]

S-expressions do not have typed standards for serializing dates and booleans like JSON. They also can't distinguish numbers from text.

S-expressions also have no standard for comments, and can't distinguish maps from lists.

A S-expression based serialization standard would be a bit cleaner than JSON, but it's enough of a change that it's worth redoing anything.

[yogthos]

All of that and more is available with s-expressions in Clojure https://github.com/edn-format/edn

[kkarakk]

Your contrived example falls flat because JSON is flat out better for most use-cases and anyone having a discussion about it will probably fit into those use-cases.

People don't discuss solutions in a vacuum. Ideally they'd think about what the potential fallbacks of using XML alternatives are before jumping into a new tech. Which they will, unless they're really really new

[tonyedgecombe]

The funny thing is there are developers[1][2][3] out there who would like to turn JSON into XML.

[1] https://json-schema.org [2] http://www.jsoniq.org [3] https://www.p6r.com/articles/2008/05/06/xslt-and-xpath-for-j...

[umvi]

> Your contrived example falls flat because JSON is flat out better for most use-cases and anyone having a discussion about it will probably fit into those use-cases.

Easy to say with hindsight now that it is massively popular and has a huge ecosystem of parsers for every conceivable language. At the time it was invented though, it was yet another data exchange format and I'm sure there were a lot of grey beards pooh-poohing it.

[DocTomoe]

Back in the day, XML was almost universally hated by the people you describe as "greybeards", mostly because it was a convoluted "one size fits all" approach, hijacked by business, that ate bandwidth for overhead with none of it's promised benefits actually materializing (because everyone created their own, quasi-proprietary XML Scheme).

[wolco]

I remember a .NET developer using it in place of json. That was the slowest system I've ever seen.

[Ididntdothis]

I would say JSON is a little bit better than XML in some areas but also worse in a some. XML could easily have been extended with a few attributes. there was no real need for doing something completely different.

[nradov]

JSON is worse than XML if your use case requires namespaces.

[kickopotomus]

Tangentially, this is one of the reasons that I am a fan of EDN[1] over JSON.

[1]: https://github.com/edn-format/edn