3 ms·
You're right: I was oversimplifying things somewhat, but I still maintain that languages are tools, not the toolbox. To use your examples: why learn Erlang? We
by VolatileVoid 17y ago
You're right: I was oversimplifying things somewhat, but I still maintain that languages are tools, not the toolbox.
To use your examples: why learn Erlang? Well, if your concurrency needs are great enough, Erlang is a great fit! If not, maybe consider another language? You pick the best and most appropriate tool for the job. Sometimes you can nail something in using your shoe, but more often than not, the best tool is a hammer.
Why learn Ruby if you know Python? Perhaps you have a project that could be taken to market significantly faster if you use Rails? Perhaps you can use Django? It really _is_ a question of the right tool: and sometimes that tool is Ruby and sometimes it's Python and sometimes it's Java (never COBOL :)).
You could probably make a strong case for any language out there. But you should make sure you're choosing the right one for your task: square pegs and square holes.
- davidw 17y agoMy rough feeling is that most people are better off picking a general-purpose language and sticking with it for most of what they do, rather than trying to "optimize" by picking the 'best' language for each task. The learning and the context switching, and even the decision process are probably worse overall than using the generic language, even if it is not the best one.