The Underscore Archives

On 2 Jul 2008, at 10:52, Aaron Trevena wrote:

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

The use of the stored procedure proxy was part of the required  
platform, just as Sybase and that C++ installation was.  They'd been  
using this platform for all projects for years.

There just wasn't the option of using CTLIB directly rather than the  
proxy.  It was actually easier to replace the platform altogether.

If I was to use Sybase directly, the app wouldn't have been allowed on  
the same servers as the other apps... even if it would, it would have  
required major work to reorganise the firewalls between the DB and web  
side (originally bridged by the SP proxy) to allow it anyway, and that  
would have had other implications.

On the other hand, installing a single LAMP machine was practical,  
just about... well, as soon as we'd proved that the standard platform  
in use wasn't going to work.


> 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++)

Actually, the compiler was fatally flawed.  It was one of those Cfront- 
style translators, IIRC, and had a severely broken STL and wouldn't  
compile the reference implementation of the STL, either.  It was a  
major chore to get it to link to any libraries, too.  It really got in  
the way.  Nasty bit of code.  Unfortunately, installing GCC wasn't an  
option.


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

It would have been *marginally* faster, as the app was database  
bound.  I did try compiling a bit of the C++ with MySQL at the time,  
expecting that it would be quicker to rewrite just the database  
interface than the entire app.

However, that C++ compiler was utterly unable to talk to libmysqlclient.

So, it then became a case of picking something I knew _would_ work...  
Perl and MySQL, especially since I was doing this off-the-radar in my  
own time.

Arguably, since I was setting up a whole new platform anyway, I could  
have done it with Linux, Apache, MySQL and GCC, but I figured I was so  
far off the reservation already, I might as well go the full hog.  At  
least they could easily employ a LAMP guy to maintain it.


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

Only in that the problem was that people had chosen an inappropriate  
platform.

We (or the original requirements team) had no reason to suspect there  
would be a problem.  The other projects using the platform were  
successful: they worked fine with just SPs.


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

Yes.  An aspect of the platform in question (which was not necessarily  
unique to that platform) made the platform unsuitable for the task.   
This is my point!

The others in the team only had experience with that platform, in much  
the same way that a dedicated Foo developer may only have significant  
experience with Foo.

My wider experience made me the only one in the team able to solve  
this escalation.

...which is where we started.


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

Not if you consider the "BuggeredC++/Sybase/MumblemumbleSPProxy" to be  
the platform in question, in the same way you'd consider "LAMP" to be  
a platform.  The SP Proxy wasn't an arbitrary constraint... it was  
part of the platform.  The reason it was originally there was purely  
"security": to limit access to the database from the external web  
servers.  Regardless of whether that was actually a good solution or  
not, that was the platform of choice.

I definitely wouldn't have been allowed to CTLIB directly.

Of course, the Perl/MySQL solution didn't address this.  It was mainly  
to demonstrate that the escalation could be solved fairly easily.


> if only they weren't almost always full of php3 style spagetti code,  
> antipatterns and sql injections.

Hey, don't limit it that to PHP3! :)  Many (most?) PHP "developers"  
still treat PHP as a scripting language, rather than a proper OO  
development system.  Admittedly, the language does make this style of  
usage far easier than it should be.

Perl's guilty of that too... it's a lot easier to write nasty "stream- 
of-consciousness" Perl than OO Perl.  Java, on the other hand, tries  
to make it easier to write nice code than bad code... of course, how  
well it achieves that is another matter.

I think the major difference is that many PHP programmers have got  
there from web design, whereas many Perl-types have migrated from the  
programming side.

There are certain aspects of PHP I personally prefer over Perl.   
However, apart from anything else, Perl definitely does win over PHP  
(and most other languages) in one major aspect:  CPAN -v- PEAR.

Clearly, thanks to CPAN, Perl is far more suitable than other  
platforms in many circumstances.  That demonstrates that it *does*  
matter what platform you pick.

Now, just because it happens to be your platform of choice, that  
doesn't mean that it's the ideal platform for all circumstances:   
there are things that aren't in CPAN that are easily available in  
other platforms.   That network library I was talking about, for one.


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


Not at all.  I don't personally subscribe to that mentality.  Fine if  
some people do, but if everyone thought like that, there'd never be  
any innovation.

 From the sound of things, money does seem to be an overriding factor  
on your choice of projects and your career path.  Not necessarily a  
bad thing, but it's not the case for me: satisfaction and interest in  
the project are much more important to me.  Whenever I've had a high- 
paying job, I've usually been miserable. Not sure why.

Money isn't everything, RANDOLPH!


Tom

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