The Underscore Archives

2008/7/1 Tom Gidden <tom at gidden.net>:
> 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.

That's a case of the implementationg before the design - AFAICT it
would be perfectly workable if you didn't have to use a
stored-procedure proxy.

Nothing about using Sybase would case the project to fail, neither
using a particular implementation of C++ (unless it had fatal flaws,
like attempting to write a UNIX application in VC++)

> 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.

I would assume an equally good C++ program using Mysql would probably
be a few times faster again, even if it took a few more days to write.

> This was a direct violation of the escalation procedure, and I got into trouble for it.

That just illustrates how much  the problem was with people rather
than technology.

> 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.

That's a case of the system design failing, if you had an SP proxy
combined with any Static language (like Java or C#) you'd have the
same development costs and problem.

> 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 don't think your example is a case of C++ or Sybase being a problem,
somebody added a design constraint before they wrote the
specification, that's just silly.

I still believe in using the right tools for the job, even in a
heavily biased towards perl setup, you're using tools and applications
written in many languages to solve the problem - in fact currently I'd
choose Lucene for any serious searching if I need
internationalisation, and that's written in Java (and requires you
integrate it using a REST webservice, because Java sucks at playing
well with other languages unless they've been crippled to run on the
JVM).

>  I still firmly believe that a flexible and widely-skilled
> expert is often more useful than an entrenched guru... often more
> insightful, too.

You wouldn't be biased about that would you ;)

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

Yup - some fields and areas have tools that are much better or worse
suited to them, but many like Web, Report generation, Internet
Servers, etc, there aren't enough differences between the appropriate
tools to justify retraining over using what you know.

> 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.

For my personal project I'm pretty much forced to learn PHP, damn
those PHP types with their wide selection of nice looking and easy to
use applications that are easy to install and work out of the box, if
only they weren't almost always full of php3 style spagetti code,
antipatterns and sql injections. Those PHP coders sure can make their
apps look nice :)

> 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 can probably be productive in something else, but nobody will pay me
as much until then, so it's not worth the upfront cost to my wallet to
de-specialise that much.

It's not that I can't read and do trivial maintenance on C, C++, PHP
or whatever, it's just that it's not worth losing the rather nice
income I get in the area I know best, even if the projects could be
more interesting.

>  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%.

Meh, no web, bioinformatics, data feeds or unix system integration then ;)

>>> 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?"

ITYM rather than "what do our customers need from us that they would
pay a nice premium on, for the minimal effort"

A.

-- 
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Hosting