|
|
|
|
|
|
by schleyfox
5280 days ago
|
|
|
Is it really so hard to take existing talent and train them to use other languages? Especially in cases where the existing library and tooling ecosystems exist (e.g. anything based on the JVM) the actual language probably won't be a show stopper for the level of talent you need. If a new language takes a couple weeks to get up to speed in, so what? The bigger problem, IMO, is the existence of libraries and basic development tools like build systems and dependency management. I'm fairly pleased with how many of the newer languages that build on the JVM allow easy interop so that you can use the existing ecosystem when it makes sense. |
|
|
This will go into the costs column, and the reasons you use that particular tech. stack will go into benefit column. Weights and values are fairly subjective for each of the rows in the two columns and is very case specific.
What I wanted to point out was that there are a lot of factors to consider while choosing your tech stack, be it for academia, research, startup or enterprise. I disagree with this following statement:
>, and since you (probably) won't be working with an entrenched code base, you are free to use whatever language best suits the task at hand.
Size of the codebase is not the only criterion. (And to be fair to the author of this article, "task at hand" envelopes a lot of the other criteria).
PS: I found a good debate between Ryan Allen[1] and Michael Wales[2] debating the criteria on which to choose PHP or Ruby, a lot of them can be translated to a general tech stack choice. I've submitted it to HN here[3] and direct link here [4].
[1]http://twitter.com/ryanfaceryan
[2]http://twitter.com/walesmd
[3]http://news.ycombinator.com/item?id=3446180
[4]http://net.tutsplus.com/articles/general/language-war-php-vs...
Sorry, if the link was already posted on HN sometime in the past.
Edit: Formatting