ghodss

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.

Box hires Syncplicity CEO techcrunch.com

2 ghodss 11 years ago 0 comments

Comment · 11 years ago

For those who want to try it out in San Francisco, Reboot Float Spa[1] is a great facility.

[1] http://rebootfloatspa.com/

Comment · 11 years ago

My personal favorite... great colors/contrast on a Macbook Pro. http://vimcolors.com/1/jellybeans/dark

Comment · 11 years ago

One major limitation of this approach is that any project that wishes to vendor or lock their dependencies can no longer be used as a dependency for another project. From the gb GitHub:

> A project is the consumer of your own source code, and possibly dependencies that your code consumes; nothing consumes the code from a project.

This seems to imply that any code outside of a project (i.e. the code inside vendor/src) has no recourse for indicating the versions of their dependencies. This is nice in that it simplifies the problem, but to completely remove the ability for any and all libraries to indicate the versions of their dependencies seems unnecessarily restrictive. If I build a library for others to use, and I have a dependency, I want to be be able to lock to a specific version, or at least give my preference for a version.

Of course, this creates its own issues - what do you do when two libraries depend on two different versions of the same library? (Also known as the diamond dependency problem.) This is where the Go culture helps, where as long as you pick a later version, things are likely to work. But I'd rather have the tooling let me detect the two versions that the two libraries want, show that there is a mismatch, and give me the ability to override and pick one (probably the later one). Instead, the gb approach eliminates the ability for the libraries to even have the ability to indicate what version they would prefer, which makes it even more difficult to get a bunch of libraries that share dependencies to work correctly together.

godep (https://github.com/tools/godep) seems to have the best compromise: vendor dependencies without path rewriting (though with GOPATH rewriting), but also keep track of their versions in a Godep.json file. You can gracefully pick between conflicting versions upstream if need be.

Comment · 11 years ago

But it's not really material, because bar doesn't touch x (and if it did, this problem wouldn't exist to begin with).

In other words, it might be a bit strange and cause a slight detour in your quest to discover the cause of a bug, but it wouldn't actually change any behavior or cause any issues.