The Artima Developer Community
Sponsored Link

Perl Buzz Forum
'Right tool for the job' is stupid

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Chris Winters

Posts: 931
Nickname: cwinters
Registered: Jul, 2003

Daytime: Java hacker; nighttime: Perl hacker; sleeptime: some of both.
'Right tool for the job' is stupid Posted: Dec 2, 2003 8:46 PM
Reply to this message Reply

This post originated from an RSS feed registered with Perl Buzz by Chris Winters.
Original Post: 'Right tool for the job' is stupid
Feed Title: cwinters.com
Feed URL: http://www.cwinters.com/raw/cwinters_perl.rdf
Feed Description: Chris Winters on Perl, programming and technology
Latest Perl Buzz Posts
Latest Perl Buzz Posts by Chris Winters
Latest Posts From cwinters.com

Advertisement
This is now in my "If I hear this phrase one more time..." list. (The straw on the camel's back was Scoble's comment to one of Diego's posts.) It's total crap, normally said by people arguing the benefits of one framework over another (or all others) in such an abstract terms as to be meaningless. And it's meaningless in two enormous ways.

First, take the "right tool" part of the phrase. This sets up a false comparison between 'right' and 'wrong' off the bat. Have you ever seen a nontrivial application where only one solution was right? Of course not. Everything has trade-offs, some of which are more painful than others. (We'll get into context in a second.) In Scoble's case at least he qualifies what 'right' means: "when you want to give Longhorn users the best possible experience." What does "best possible" mean? What if it comes six months later because all your .NET programmers have been shafted, again, by huge API changes from Microsoft and have to scramble to learn the libraries? What if by using a scripting language plus a portable toolkit they don't get the best experience but they get updates to the system three times as fast?

Second, "for the job." Like a pattern, a solution for a job (which itself is a slippery term) must be evaluated in a context, something rarely done when this phrase is brought up. Maybe deployment ease is my most important criterion for judging a solution. Or being able to use existing opensource libraries for interop so I can control my own destiny. Or supporting users on multiple platforms and thin clients. Maybe I've got a cadre of kickass Perl programmers who can bang out a solution in a third of the time with a quarter of the code which is more reliable code because they've been doing it for (by that time) ten years. Or I've got a very mature in-house Java library which does 70% of the work for me. Or whatever.

Of course there are lots of wrong tools for many jobs -- AFAIK nobody suggested to ebay to use an app server written in Forth. But even then people have some seemingly inappropriate fun which winds up bring just ahead of its time -- the first person to write one of the tiny web servers was just having fun, but now you can find web servers embedded in all sorts of devices.

Read: 'Right tool for the job' is stupid

Topic: 'Right tool for the job' is stupid Previous Topic   Next Topic Topic: Perl testing modules

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use