3 ms·

The biggest problems big companies have is that they need to do everything. If I have a companies with 2000 engineers and I have projects in ML, Rest Servers, C

The biggest problems big companies have is that they need to do everything. If I have a companies with 2000 engineers and I have projects in ML, Rest Servers, Cloud systems, etc, it makes vastly more sense to rely on one language to do everything, because it allows me to shift engineers from one place to another without them having to learn a new language. If I'm a startup, I generally have ONE thing that I need to excel at. If that's computer vision, why would I use Java when C++ (and arguably Python/OpenCV) is decidedly better at computer vision? If I need a simple REST service for my particular project, why in the world would I use Java over Python, Ruby or Go? The value of Java is that it does everything well, but the ecosystem is enormous. It's overkill for most projects, unless you happen to have projects that scale across multiple domains that Java does well. I find it odd that I'm getting so much push back here. There's a massive amount of cognitive overhead in utilizing Java. There's also a huge cost (both cognitive and entry) in using of Java. (The difference between a Java programmer and a generalist? How much the latter has to learn to catch up.)

dragonwriter 9y ago
> If I have a companies with 2000 engineers and I have projects in ML, Rest Servers, Cloud systems, etc, it makes vastly more sense to rely on one language to do everything, because it allows me to shift engineers from one place to another without them having to learn a new language. Well, CIOs tend to think so. I think they are wrong, and that this is one of the reasons enterprise-internal technology is so bad. You aren't actually going to.move engineers between those tasks very much, because each of them relies on fairly deep domain knowledge, and, in any case, it's unlikely that the size of demand between those tasks shifts enough that it makes sense to shift a lot of people around. And, those you do shift around are going to have a lot of work coming up to speed on domain knowledge (which is going to have a huge impact on how the language is used), which will dwarf any language-transition effects. And, furthermore, the places that do stuff like this aren't the kind of places that attract the kind of talent that could manage to the transition between these divergent domains well; what they almost invariably end up doing to deal with short-term shifts is hiring specialist contractors in the more in-demand area, and for longer-term shifts reducing headcount in one area and hiring new people in the other. At the same time, you are inhibiting productivity in most or all of the individual domains by not choosing the right tool for the specific job.
- jhall1468 9y ago
  > You aren't actually going to.move engineers between those tasks very much, because each of them relies on fairly deep domain knowledge, and, in any case, it's unlikely that the size of demand between those tasks shifts enough that it makes sense to shift a lot of people around. I agree, but wanted to specify "big" examples to make it clear what my point was. That said, while they do require domain knowledge, I've seen people move into entirely different domains at the same company. It's not common, but it absolutely happens.

dragonwriter 9y ago

> If I have a companies with 2000 engineers and I have projects in ML, Rest Servers, Cloud systems, etc, it makes vastly more sense to rely on one language to do everything, because it allows me to shift engineers from one place to another without them having to learn a new language. Well, CIOs tend to think so. I think they are wrong, and that this is one of the reasons enterprise-internal technology is so bad. You aren't actually going to.move engineers between those tasks very much, because each of them relies on fairly deep domain knowledge, and, in any case, it's unlikely that the size of demand between those tasks shifts enough that it makes sense to shift a lot of people around. And, those you do shift around are going to have a lot of work coming up to speed on domain knowledge (which is going to have a huge impact on how the language is used), which will dwarf any language-transition effects. And, furthermore, the places that do stuff like this aren't the kind of places that attract the kind of talent that could manage to the transition between these divergent domains well; what they almost invariably end up doing to deal with short-term shifts is hiring specialist contractors in the more in-demand area, and for longer-term shifts reducing headcount in one area and hiring new people in the other. At the same time, you are inhibiting productivity in most or all of the individual domains by not choosing the right tool for the specific job.

jhall1468 9y ago
> You aren't actually going to.move engineers between those tasks very much, because each of them relies on fairly deep domain knowledge, and, in any case, it's unlikely that the size of demand between those tasks shifts enough that it makes sense to shift a lot of people around. I agree, but wanted to specify "big" examples to make it clear what my point was. That said, while they do require domain knowledge, I've seen people move into entirely different domains at the same company. It's not common, but it absolutely happens.