You wrote:
> scripting. it's obvious that perl is much more powerful, but since build
> 622 i know what php3 can mean... i tried to create a socket with perl (one
> server/one client side script). the 622 build implements the urgently
> required fork() (without this function the perlipc example i've taken
> (hardly understood btw) for the client side wouldn't work) functionality
> for multithreading in a perl script.. but pitty.. there is no dbi module
> for this latest verion of activestates perl... however... trying to create
> a socket under perl seperates those 'scripters-on-demand'* like i am one
> from those c/c++/perl veterans... i didn't understand a line of the
> suggested script... trying this with php3 cost me 10 minutes and it worked
> (i didn't really need the multithreading stuff).
Let me start off by saying that the whole point of PHP is to make
tasks like this easier - at the expense of limiting what you can do.
Now then, there are several very important points I want to clear up.
[1] Build 622 is still considered EXPERIMENTAL. Do not use it
for production work unless you really know what you are doing,
and are prepared to accept the responsibility for some random
badness.
[2] You really shouldn't use code you don't understand in a
production system. Look at the trouble you hit. The solution
I would recommend is *not* moving to build 622 [perl 5.6],
but using IO::Select instead. Code illustrating this has been
published in this mailing list, so you could just search the
archive.
[3] Creating raw sockets is usually not necessary. There are lots
and lots of Perl modules which will hide the nasty bits when you
have particular tasks. You just have to look for them.
> finally think of the dbi module. when i started to operate on mysql
> databases via perl i've read the docs fo this module. that realy did it. i
> never came to the idea of looking into the dbd:mysql manual for valid
> instructions. no word in the dbi manual that most of the functions don't
> apply to mysql databases - or that the instruction set doesn't apply to all
> databases supported by the dbi manual. how am i ordinary wannabe programmer
> supposed to get behind this.
But Perl isn't restricting itself to MySQL on a webserver. The
DBI module is designed to do far more than the database functions
of PHP. The information on the limits of MySQL and the DBD::MySQL
driver are in the DBD::MySQL docs. If you can get the job done
quickly in PHP, good. But when you need change the database, or
move it to a remote server, or connect to it via another protocol,
or whatever, you'll be stuck. The point of the DBI module is to
make this relatively transparent, and easy to address. So Perl is
looking at a totally different level of approach.
> [...] php3 is much more efficient there, no mdoules, allalready onboard
> (think of the default url en/decoding while passing form elements). but,
> never mind that. i just want to say that people like me need and will need
> in future php AND perl - and i'm sure there are more out there.
Actually, I'll disagree there. I think Perl is more "efficient"
there, since it encapsulates those parts in modules so you only
access them if you need them. I doubt that most hard-core Perl
programmers do much - if any - web-work. I do very little. So
it's massively convenient *not* to have that stuff in the mix when
I don't want it. And it's so darn easy to add it in with just one
short line of code. But PHP is easier to learn, since its
learning curve is shorter. There are things you can do in PHP
in one less line than in Perl, and if that is all you ever need to
do, then PHP is a viable solution for you.
But PHP is utterly useless for at least 95% of what I do. And I
like the polyglot intricacy that is Perl.
David
--
David Cassell, OAO [EMAIL PROTECTED]
Senior computing specialist
mathematical statistician
---
You are currently subscribed to perl-win32-users as: [[email protected]]
To unsubscribe, forward this message to
[EMAIL PROTECTED]
For non-automated Mailing List support, send email to
[EMAIL PROTECTED]
