Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Both are strange and alien to Javascript developers, who can be full stack.

Python may seem simple once you know it, but going in blind there's plenty of traps to bite you. Significant whitespace for one.



I think there's two different issues:

1. picking a language/tool that a company doesn't have personnel with experience using it

2. picking a language/tool that is esoteric, which generally implies #1 as well.

#1 on its own isn't great, but generally when sticking in the java/python/ruby/javascript/php/etc...mainstream languages, there's a lot more documentation, and there's a higher chance that _someone_ in the company will have some familiarity. If nothing else, it'd be easier to hire a replacement for.


A higher chance, yes, but it doesn't matter much; what is tricky with most applications is the domain. Certainly, it's faster to go learn a language than to learn a new domain. To that end, you can get the whole team trained faster in a language than you can hire someone with experience and train them to the domain.


> Certainly, it's faster to go learn a language than to learn a new domain.

It's not only the language but the framework. For example I know javascript well enough but I now am quite a noob with Ember in my new role. I would say the framework is just as important as the language, at least when doing web development.


You're kind of reinforcing the point though -- now you've got a whole team distracted by picking up a new language....why? how is it a good use of anyone's time? And it'll be a perennial training issue in the case of an esoteric language, because those team members will eventually turn over as well, meaning that you don't get to avoid either hiring or training a new person on it.

If it's just one component, implemented by a single dev, it really can make more sense to understand what it does and rewrite it in a language that's common in the company.


I'm not advocating NOT rewriting it. I'm just saying, back to the great grandparent's point, that the issue is a dev went rogue, NOT the language the rogue dev chose. The difficulty is the same regardless of the language the rogue dev chose; it's not that they picked Clojure, it's that they picked a language there was no organizational adoption of.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: