3 ms·
> 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,
by umvi 7y ago
> 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."
- kkarakk 7y agoYour 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
- umvi 7y ago> 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 7y agoBack 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 7y agoI remember a .NET developer using it in place of json. That was the slowest system I've ever seen.
- tonyedgecombe 7y agoThe funny thing is there are developers[1][2][3] out there who would like to turn JSON into XML. [1] https://json-schema.org https://json-schema.org [2] http://www.jsoniq.org http://www.jsoniq.org [3] https://www.p6r.com/articles/2008/05/06/xslt-and-xpath-for-json/ https://www.p6r.com/articles/2008/05/06/xslt-and-xpath-for-j...
- Ididntdothis 7y agoI 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 7y agoJSON is worse than XML if your use case requires namespaces.
- kickopotomus 7y agoTangentially, this is one of the reasons that I am a fan of EDN[1] over JSON. [1]: https://github.com/edn-format/edn https://github.com/edn-format/edn
- yogthos 7y agoXML 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 7y agoS-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 7y agoAll of that and more is available with s-expressions in Clojure https://github.com/edn-format/edn https://github.com/edn-format/edn