Re: Language choice for high-volume Oracle CGI interface?

Lee Fesperman wrote:
>
> Actually, there are a lot of disadvantages to using a 'subset' of a language for
> specific purpose (like using a subset of Perl for CGI). Assuming you're advocating using
> a subset of Perl (so you don't have to learn the full blown language), the disadvantages
> of that approach include:
>
> + You must clearly document this subset, carefully leaving out complexities of the
> language that are not needed. What to include can be a very hard choice to make.

Why?

> + To a user of the subset, many of the elements will be counter-intuitive since they
> were actually designed for a larger purpose.

Such as? Please give examples, with comparisons to how Jive does this so much better. Don't limit yourself to pure perl, but consider things like EmbPerl which do something very similar to Jive (without it's limitations).

> + Certain aspects of the processing will always be a 'misfit' (impediance mismatch) with
> the language. For instance, access to CGI variables in Perl always requires an explicit
> lookup. These aspects will never make 'sense' to the subset user.

Eh? With Jive you declare:

input my_form_name

With perl you generally do:

param('my_form_name') - CGI.pm

or with EmbPerl:

$fdat{my_form_name}

No explicit lookup. Those seem like perfect matches to me.

> If you are recommending that Perl CGI is a good choice for an experienced developer in
> Perl, I wholeheartedly agree with you.

s/ in Perl//;

My experience with languages limited to one problem domain is that they are just that: Limited.

Matt. Received on Tue Jun 22 1999 - 04:14:15 CDT