[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]
Re: two good poems; Wether perl any good?
1. I maybe wrong but is there actually any difference in how one mixes
code with HTML ??
Lets generalize things a bit between Embperl, ASP and Java.. Let the
code delimiter be <% and %>. This is how I see a decent embedded HTML to
look like....
------------page.html begin ---------------
<%
[my list of variables here] = (dereference whatever the function
returns) SomeFunction([the query string here]);
%>
<html>
<body>
blah blah blah ....
<% [populate the HTML with the values returned by the function by print
or write or whatever] %>
some more blah blah blah here ....
</body>
</html>
-----------page.html end ------------------
If I am wrong my sincere appologies but no programming language seems to
be able to do better than that and as far as I could figure out thats
how people merge code with HTML in Embperl, ASP and JSP. Now lets take
the case of a change in functionality - as far as I can see in all
languages you just change the logic in the function being called - your
HTML is intact. Ofcourse no sane programmer would keep his functions in
the same file as the HTML. Now in case the page design is changed - pray
what can anybody do in that case ?? None of the languages can do
anything about that.
As for modperl - it can do a lot but not everything - it can do as much
preprocessing as you may care to do but modperl wont be able to populate
your HTML. As for templating you might want to look at Embperl Objects
and Mason but in any case Embperl is way beyond just a RAD tool.
Ahem comparing MySQL with Oracle - isnt that a bit unfair [more like
grosly unfair :)]
A natively compiled code is always going to run faster than a byte code
or semi compiled code. In case of Perl I am not sure what happens but
some sort of precompilation is done to make things run faster than it
would have in case it was running in interpretor mode. In any case the
point is the developers felt that running a natively compiled code would
be more efficient in case of a database connection. I am sure there is
nothing stopping anybody from writing a pure perl implementation of the
MySQL driver and rest assured Perl as a language is fully capable of
doing that. As for your claim that most perl module is just a wrapper -
I would say that is a baseless accusation.
As for availability I believe any perl code will run without a problem
on all platform but ofcourse I would also accept that not all packages
are available on Windows and Macintosh. This is not a limitation of Perl
as such but of the package manager. I don't know why Activestate didnt
use the standard procedure but I don't think there is any reason for a
tar ball not to uncompress and execute under windows...
I personally try not to use too many modules as it would indirectly
bloat the webserver and I havent had the reason to do so utilize too
many as most of them are generic modules not exactly tuned to what I
might actually need. So I can confidently say that the core Perl modules
are sufficient for for most applications.
Mithun