On 07/02/2013 17:56, Paul Makepeace wrote:
On Thu, Feb 7, 2013 at 4:09 AM, Dave Cross <d...@dave.org.uk> wrote:
I think the best programmers don't "stick with the language they know". I
think they see a new language as largely a case of learning new syntax and
enjoy having a number of languages to choose from so they can use the best
one for each individual task.
I feel this is a well-worn trope but not actually how it works except
for possibly very small one-off projects. Learning and being
productive in a language is far more than just syntax; in fact that's
probably the easiest part since they're largely the same, unless
you're learning something radically different. By far the lion's share
of the work is the libraries, error messages, documentation, and
toolchain.

>From my own experience, if I'm day-to-day productive at a
being-paid-for-it level in say Perl, I tend to swap out a bunch of
Python knowledge. Sure, I can swap it in, but as ever there's quite a
cost to that. Spending one's day constantly referring to Stack
Overflow, Google, CPAN, and perldoc is workable but it's slow. Using
say Perl + JavaScript is do-able but it requires IME daily use of
both.

Conclusion: unless Language X was compellingly amazing at Task A I'd
do my best to solve Task A with Language I'm Most Familiar With These
Days.

Curious how others approach this.


I agree. The ideology of "use the best language for the job" is sound. But from my experience the practicalities generally aren't. Most people have a limit to how much they can remember, very few have an eidetic memory. Using another language usually involves lots of look up as Paul suggests. Which for me at least, feels like wasted time and frustration when I know how to do it in Perl. Then maintenance becomes an issue. Years later you have to update the code in language X, which you might not have touched since, so it's a case of relearning again. No matter how good you are in your preferred language, it'll take time to learn all the quirks and become as good in another, so the code you produce at first wont be the best.

I'll use Perl for as much as I can, because it's usually the quickest and easiest thing for me to do now, and in the future (maintenance).

If I can't use Perl, or there is an overwhelming reason to use something else, then I will.


Lyle

Reply via email to