The Underscore Archives

On 1 Jul 2008, at 13:29, Aaron Trevena wrote:
>
> Now this is only a rule of thumb, but on the whole frameworks and  
> platforms aren't different enough for any benefits to overcome the  
> cost of relearning and implementing a new project as a bunch of  
> newbies, rather than with expertise of your tools.

Case:  In 1999 I took a contract at a large company, and the decision  
had already been made that the project was to be implemented in  
Sybase, non-ANSI/ISO C++ and use a stored procedure proxy which  
purposely didn't allow any arbitrary SQL.  There was *no* way to get  
this thing to perform adequately, as it needed to do some complex  
search queries which we weren't able to implement in Transact-SQL.

After a year-long Priority 1 escalation, I rewrote it over a weekend  
in Perl and MySQL, as a line-by-line translation, and the whole thing  
ran 100 times faster, literally.  This was a direct violation of the  
escalation procedure, and I got into trouble for it.

Back when the spec had been written, the Sybase/C++/SP-proxy platform  
had seemed utterly reasonable, as they had many other projects that  
worked fine with it, and there was a lot of in-house expertise.   
However, none of those projects had required arbitrary SQL construction.

I know you cage it with "this is only a rule of thumb", but I've seen  
a few situations like this, so I'm not willing to dismiss them so  
quickly.  I still firmly believe that a flexible and widely-skilled  
expert is often more useful than an entrenched guru... often more  
insightful, too.

Especially if you're talking about more than just web projects.  As  
you mentioned earlier in your post, Perl for an FPS, and suchlike.

Right now I'm juggling some PHP code on three separate projects (two  
separate clients); learning AS3 and writing an AS3 project; learning  
enough Objective-C and OpenGL to do the next project; and trying to  
decide whether to use Perl, pure C or learn and use Python to write  
some fairly complicated low-level (sub-TCP) networking hackery.

In fact, I'm most likely to go with Perl, even though the library I  
want to use is only available in Python and Objective-C!  I'm going to  
have to port it to Perl, unless someone else on the mailing list beats  
me to it (and fortunately, it looks like they're going to...)

You've said before "I always use Perl for any serious work, there's no  
point
using something I won't be as productive in."  Good for you!  I, on  
the other hand, prefer to be able to work on whatever tech I need to  
for the project at hand, and I can promise you that Perl would only be  
suitable for about 30% of the coding I do, and sometimes it's not  
necessarily the best choice for that 30%.


>> Even worse is when the _project_ itself is chosen purely on the
>> technology matching the individual developer's skillset, which seems
>> really backward to me.
>
> Now, that's just plain silly.


Happens a lot, though... "what shall we do next, taking into account  
what we know?", rather than "what shall we do next, so we can learn  
new stuff, widen our abilities, and open up new opportunities?"

Tom

-- 
Tom Gidden
http://gidden.net/tom