RE: server side tools...

[shalperin@xxxxxxxxxxxx (Shalperin)]

> From: James Robertson <jamesr@xxxxxxxxxxxxxx>
> 
>> [SNIP]
>> But I would ask: why C++ instead of Java?
>> [SNIP]
>>
>> From: "Guy Murphy" <guy-murphy@xxxxxxxxxxxxx> 

> Performance? :)

And the real reason is...

C++ is stable.  Tools exist for our needs on the front end as well as the back
end.  Java only recently made the leap to the server side, so we're a little
hesitant to implement a large system (3-tiered) with a language that's still
evolving.

<vent>
Besides, ever try debugging a servlet?  I don't know how much things have
progressed, but about a year ago, when I was learning Java, I asked a co-worker
how I could use Kawa to debug a servlet.  The answer, "Huh?  Oh, you can't,"
made me experience a paradigm shift of great magnitude:  suddenly I was
catapulted back in time to the days of printf's and symdeb... the resultant look
of shock on my face generated much laughter.  I won't describe the chain of
expletives that went thru my mind - had we really evolved to this?

I dunno, maybe I'm just an old codger who's set in my ways.  ;)

(BTW, it is possible to debug servlets, but it's not an obvious integrated part
of the "IDE".)

Aside from that, the idea of browser dependence dictating which version of the
language I can use really *irks* me (yes, yes, of course that's only for
client-side Java).  We're already dealing with that issue with Javascript and
HTML and I'd rather it not trickle back into the server side.

This is why I want to do all my XSL + XML = XML/HTML on the server side,
swapping parsers as is necessary.
</vent>

<evangelism>
XML is exciting technology and I feel that XSL is the key that lets me leave
browser dependence behind.  It's the next step in the evolution of platform
independent information dissemination.  Woo hoo!
</evangelism>

-s


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list