[ghodss]

One of the premises of this article - that "competing standards" exist primarily because of political reasons or shallow decision making - demonstrates a fundamental misunderstanding of software engineering.

Sure, some engineers (especially junior ones) enjoy reinventing the wheel more than using something that already exists to solve users' problems. We all like to trick ourselves into thinking we're unique snowflakes (this problem extends into our personal lives as well). But more often than not, when multiple popular standards emerge, it's because there are legitimate engineering tradeoffs that are being made.

JSON vs. XML? XML is far more capable but complex. JSON is far simpler but less capable. Sometimes when you're delivering value to customers, you need that extra complexity, so you use XML. Other times you don't need it so you use JSON. It has nothing to do with ego or politics. Multiple different JSON libraries? One may prioritize ease of use to get up and running, the other may prioritize strong typing for serialization speed. One may prioritize strict compliance with the spec, the other might prioritize speed above all else. JSON vs. a binary format? JSON is more readily compatible and easier to debug. Binary is faster but more complex to setup. It goes on and on.

Again, sometimes competing standards or libraries or languages emerge because of political or capitalistic concerns. But usually when you're talking about competing open standards, there are multiple because there are legitimate engineering tradeoffs being made because engineering is not a one-size-fits-all science. (Few sciences are, otherwise they wouldn't still have people working on them.)

When an open source project rejects a contribution, or five projects exist to solve the same problem, they're often making legitimate engineering tradeoffs that are in no way arbitrary, and any one project would suffer to try to be every thing to every person. The article in question doesn't even point out a single example of a set of standards or libraries that are entirely arbitrary in their differences or could be collapsed into one solution, which further highlights how this is a theoretical argument, not a practical one.

[lucozade]

Indeed. Sometimes things are complicated/messy because we're stupid or lazy or ignorant.

But sometimes things are complicated/messy because we're trying to solve complex problems.

That's not to say that there isn't a simple solution to a particular problem nor that we should strive to find it.

But to assume that there are always simple solutions to complex problems is itself a form of ignorance.

[yxhuvud]

Another thing to remember is that our collective understanding of the problems evolve over time and often subsequent standards reflect this. XML vs JSON is definitely a case of this, as is the progression of CORBA -> SOAP -> JSON based REST services.

[lausobo]

author here. Thanks for your comment.

I clarified that "Sometimes" the causes are political, it used to say "Usually".

But if after a 30 minute read you picked up on a stupid example and you started a discussion on XML vs JSON you are just proving my point. The expectation in the 60s was that machines will figure out protocol, even make protocol, on the fly, by asking about each other. Yet, you want to have another discussion about XML and JSON.

[icebraining]

Machines do figure out the protocol on the fly by asking each other; see the Accept and Upgrade headers in HTTP, for example. Of course, HTTP is itself a protocol, because you can't "ask each other", or do any kind of communication at all, without a common protocol to start with.

As for making protocols on the fly, that makes roughly as much sense as two people inventing their own language to talk to each other.

[lausobo]

And of course, since it doesn't make sense to you, it is impossible.

Turns out that people invented their own language by talking to each other.

[icebraining]

I never said it was impossible.

[pjc50]

That was the great time of belief in "4GL". I think what we've learned from that is that the hard part is not so much implementing what we want, but making all the decisions. Coping with all the interacting possibilities and working out what we want in each case.

[tarkeshwarsingh]

You hit the nail right on its head :)

[spacecowboy_lon]

You think the ISO vs TCP/IP fight didn't have some element of politics?