Hacker News Reader

Comment by taeric | Hacker News Reader

Monocultures like this interest me. We spent a ton of time in grade school learning about how monocultures were terrible long term strategies. And yet, it seems they are actively pursued everywhere. It is easy to see why this is a problem for biological things. Just look at how close we are to losing the current bananas most in the US know. I'm pretty sure avocados are the same.

In technology, though, we seem to embrace the monoculture for things. Languages, implementations, everything. They all seem to converge to a single one.

I think I understand why this happens in many cases, but I can't help but shake a feeling that it is off. Indeed, I agree with this blog post, but I still feel that something is off. Am I alone in that?

View on HN

> Monocultures like this interest me.

Just because they call it a monoculture, doesn't mean it has anything to do with social behavior per se. It's a technical choice. Might as well ask why every function isn't implemented in X languages or X styles. Using a singular tool in a build is the default. It's a surprise to me, that they still were trying to support a bunch of disparate compilers. Let someone else handle that, while you run the race of feature implementation, which is hard enough.

Your first sentence is confusing to me. Monoculture is not, necessarily, a social thing. Hence why I mentioned bananas and avocados. :)

That said, I think I agree with your overall point. With the amusing counter that most new languages do go way the hell out of their way to start implementing everything. In large to keep you in that language. Even in the web services world, it amuses me to see so many folks try and cram everything into a single service where they can.

The flip side, of course, is you do have a finite budge of energy to make things happen. It makes little sense to spend that budget solving problems you don't have. Worse, you could rathole into solving technical challenges that you may never actually have a need to solve. All the while leaving your customers dry.

So, yes, there is a tradeoff. I fully agree with that. Which is why this topic is interesting to me. All of the incentives seem to be to embrace monoculture thinking in most that you do. I can't help but think that is off in the long view, though. :(

> In technology, though, we seem to embrace the monoculture for things. Languages, implementations, everything.

I would say there's a pretty straightfoward explanation for that: monocultures are, in general, far easier. Usually (unlike the instant case, where it wasn't an option in the first place), it's even the path of least resistance.

The alternative, diversity, true dirversity, diversity of thought is very difficult. Since it, presumably inevitably, results in conflicting viewpoints, which leads to.. conflict. There doesn't seem to be a good way of handling conflict in collaboritve environments.

Consider the (rhetorical?) question, "Can't we all just get along?"

That explains why we create monocultures a lot. I'm specifically intrigued that we typically argue for them. At the least, I would expect us to feel somewhat off about doing them, but deliberately choose to do so for cost reasons. (That make sense?)

I think I understand what you're asking, and (I hope), that's also what I'm suggesting as an answer.

That is, even though having a monoculture may feel vaguely off, for most people, conflict feels much more intensely off.

In essence, arguing for monocultures is often synonymous with arguing for conflict avoidance or "just getting along".

This makes sense. I'm not sure how I feel about it, right off.

Are you asserting this is the majority of it? Or just a large portion? Other reasons I could see: a) It is easier to try and reimplement something than to try and build a bridge between old and new. b) Personal preference convinces people their choice in an implementation detail matters. (I mean, it definitely matters at a personal level. But to the end customer? Do they even know?) c) tooling is often very monoculture focused. (Though, this really just goes back to difficulty.)

I'm asserting that conflict-avoidance is why, in general, monocultures might either actively be argued in favor of, or, more specifically, why nobody actively argues for (what I consider) the true opposite, which is dirversity of thought.

I'm not necessarily saying that such a thought process would factor in, if it's never consciously brought up.

> a) It is easier to try and reimplement something than to try and build a bridge between old and new.

I've heard this described as "more fun" rather than "easier", though usually that's because the assertion is being used as a criticism.

Still, what do you mean here, by "easier"? If the difficulty in the bridge-building is largely (or entirely) due to a inexpertness, discomfort, or (less charitably) laziness with dealing with different/diverse/old thought, my point still stands.

I don't think I meant it completely in those terms. Rather, I am pushing "easier" in a term that is more in line with "cheaper." Consider, it is cheaper to reimplement a framework into javascript than it is to port the language demonstrating the framework into the web platform. (I'm thinking of the general "reactive" methodologies here.)

That said, I agree your point still stands. I was not trying to disprove it, but give it some complimentary points. That is, to help myself understand the point in the fine print, not just at the broad level. That make sense?

> Consider, it is cheaper to reimplement a framework into javascript than it is to port the language demonstrating the framework into the web platform.

I'm not sure I follow what you mean here, though I admit I'm quite inexpert in this area.

My primary exposure/interest (especially in reference to the original topic) is that of a sysadmin who's done building and porting of mostly open source software on diverse Unix platforms and some of the integration of build tools (including compilers) into existing processes... long long ago.

> That make sense?

It does. I don't think we're really disagreeing, either, just exploring the ideas around this.

There is also economics, where they have this scale from perfect competition over oligopoly to monopoly. What happens in reality differs very much: many competitors for farmers, few competitors for car manufacturers, no competition for government institutions.

Currently, Firefox works in a compiler oligopoly. It seems they would prefer a LLVM monopoly for better efficiency.

Btw the Linux kernel only supports GCC, so Mozilla is not alone.

This isn't really different across the industries, though; is it? Even farmers only do monocultures because of the money. Specifically, it is in their interest to only farm the crop that makes them the most money, if they can. They only diversify if they have to for survival. Again, see the banana and avocado market.

The kernel is an interesting case. It specifically used the free compiler. More, it specifically does not target running on platforms that historically required another compiler.

Though, again, going back to the original point. It is cheaper to build the monoculture. To that point, the risks associated with doing so are not the same as a biological case. Well, they somewhat are, but there is also the risk of development being too expensive not to do this. It all comes back to tradeoffs and this being a decision to make.

Everyone wants one grand unifying tool/standard/instruction set/architecture/theory/system to handle all use cases because it seems elegant to do so. (See obligatory xkcd which I won't post, but you know which one I mean.) It feels right to harmonize everything, even when it actually isn't, or it stifles innovation, or may lead to long-term technical debt.

Reply on news.ycombinator.com