Re: Preaching Perl gospel to PHP converts...
by broquaint (Abbot) on Apr 24, 2002 at 15:59 UTC
|
1. What does Perl have that PHP does not?
In terms of language it has features such as closures, lexical scoping and flexible syntax. As an interpreter it is at home on the command-line, 'easy' to embed, *very* portable and pretty speedy (see. The Great Computer Language Shootout for some interesting comparisons). Something the perl community has over the PHP community is it's maturity and cohesiveness. That's not to mention it's immense library that will probably cater to every need.
2. Alternatively, what does PHP have that Perl doesn't?
It has an extensive API built into the language, with everything from zip functions to complex data structure manipulation. It has very nice documentation which is comprehensive and a dream to navigate. The language itself is quite consistent and mostly straight-forward, and because it was designed with the web in mind you can embed your code right in the page (if you so wish to do so).
3. What does Perl do differently than PHP?
One of the first things you'll notice coming from PHP is that regex is stuck right in the code without any ereg or preg functions wrapped around. This in itself shows perl's origins as a *nix command-line tool, so it adheres a lot to the *nix methodology. Something that will really trip up converts is the way perl deals with lists. Everything from assigning to returning from a function can be confusing and frustrating, so it's a good idea to get that sorted out ASAP. Then there's references which are used frequently within perl programs, whereas you can write entire websites in PHP and not use a single reference. PHP only has dynamic scoping, so pretty much *everything* is a global (unless it's in a function or a class). Something that always confused me in PHP which I thought perl did so much better is the way it deals with arrays. In PHP you can treat and mingle indexed and associative arrays and call associative arrays like indexed arrays. Whereas perl has a clear distinction between arrays and hashes in terms the way they're used, so $hash{foo} can *never* be called $hash[0].
4. Common pitfalls that PHP converts face the first time they start praticing Perl?
As I mentioned earlier, the way perl deals with lists can be confusing. References can also be a mis-understood and are subsequently ignored in favour of passing everything in named data structures (which then leads on to 'list confusion'). Another pitfall is lexical scoping (but I declared it just *there*!!!) where in the PHP world once you've declared a variable it isn't going anywhere quickly. Possibly the biggest mistake a PHP programmer will make is not using strict, as it throws up too many forboding and annoying errors for the uninitiated.
HTH
_________ broquaint
| [reply] |
Re: Preaching Perl gospel to PHP converts...
by ignatz (Vicar) on Apr 24, 2002 at 16:03 UTC
|
For the most part the biggest hurdles about getting them into Perl are going to be the same as they are for anyone.
Here are the PHP centeric points that spring to mind:
()-()
\"/
`
| [reply] [d/l] [select] |
Re: Preaching Perl gospel to PHP converts...
by Molt (Chaplain) on Apr 24, 2002 at 15:02 UTC
|
Have you thought of approaching this from the point of view of 'They learn Perl from you, you learn PHP from them'? I'm not suggesting that you switch over to PHP for work, but it's always good to have other languages under your belt.. also if you do find stuff PHP has that Perl hasn't you can pull it back over our side of the fence
Knowing more languages is never a bad thing, and as you said these two aren't that different so the learning curve shouldn't be too steep.
I suppose the disclaimer here should be that I've not learnt PHP myself as yet, but I think I would do if there was the opportunity to do it in a mutual learning environment such as this could be. I do make a point of continually learning though and when I stall on Perl I generally either pick up one of my other languages for a play, or attack a new one.
| [reply] |
Re: Preaching Perl gospel to PHP converts...
by Ovid (Cardinal) on Apr 24, 2002 at 19:43 UTC
|
Two things to keep in mind:
- PHP is not better than Perl
- Perl is not better than PHP
By trying to convince a PHP programmer that Perl is a superior language, you thereby assert that PHP is an "inferior" language. That's gonna hurt and you shouldn't do it. I've used PHP and, while I admit that I've found some areas frustrating, for the most part it appears to be a decent tool for its job. Does it have problems? Yes. Does Perl have problems? Yes.
If you take any approach, remember to focus on the strengths of a language and not its weaknesses. Brag about how useful your corkscrew is for removing corks and don't complain about how bad it is for drilling a hole in the wall. If you need to drill a hole, you shouldn't use a corkscrew.
PHP is simply another tool in the box and you're suggesting that they pick up another tool (albeit a very flexible one). It's probably not a bad notion for you to be willing to pick up another tool, too, as Molt suggested :)
Cheers,
Ovid
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.
| [reply] |
Re: Preaching Perl gospel to PHP converts...
by RMGir (Prior) on Apr 24, 2002 at 15:29 UTC
|
Common pitfalls that PHP converts face the first time they start praticing Perl?
I did one project in PHP after having had extensive perl experience.
The MAJOR pitfall for me was that, in PHP, unless you specify otherwise, a variable is automatically local to any scope.
This is the complete opposite of perl, where unless you say "my" or "local", you see the global variable.
I'm sure there are a lot of other differences, but that's the one that bit me the hardest, and I'm sure it would bite your PHP folks going the other way, as well, especially if they use "local" instead of "my", since local really isn't the opposite of php's "global"...
--
Mike | [reply] |
Re: Preaching Perl gospel to PHP converts...
by BUU (Prior) on Apr 25, 2002 at 13:23 UTC
|
A couple of people have mentioned that it would be a good idea to 'add another tool to the tool box' (or whatever semi-random metaphor they feel like using), but my question is, how does adding php help you? I mean, what you can you do in php you cant do in perl, aside from some syntactical differences as noted above, function != sub etc, how does learning php help above perl? _I_ only see two real advantages of php, one is that it allows you to easily embed your script within html without having to print print print all the time, and the other is that its a small, lightyweight and easy to learn language, so its not that hard for newbies to pick up. For the first point, ill just mention templates and perlscript and leave it at that, for the second point, well, not much you can do, with power comes some complexity. Thoughts? Im not particurally trying to start a holy war or what not, I just tend to look at php as a web only subset of perl. | [reply] |
|
Ok, almost a year later, I want to throw my comments in there...
I am a relativley NEW Perl programmer. I started learning Perl about 9 months to a year ago.
I have only modified a php script, I have not written any.
Speaking from OUTSIDE PHP looking in, and on the "outskirts" of Perl(not a Perl guru), I have seen ONE THING, that PHP does, that I have not yet seen Perl do.
PHPLive.
For those that do not know what that is, it's a Live Support helpdesk. It uses Javascript and PHP. The part I'm talking about, is how I can have my "console" open, which is NOT an applet, it's just a window, and I can leave it open forever, and my site will ALWAYS know that I have it open, so it says I'm online, or if one of my partners is on it, it says online. However, if I'm the only one, and I merely CLOSE the window, and then refresh my website, it KNOWS I've closed the window.
I have not seen perl be able to "call" a window, REMOTELY, that could be in china, and know that it's open or closed.
If Perl does it, I would LOVE to know the ways to make it work. I'm sure there are some kind of applets out there that can work, but to just use a ordinary window, it's amazing that it does that.
Don't get me wrong, I'm a Perl Guy, all the way. I have some many different sites, that I've built in Perl, that are getting better and better, as I learn more and more.
I just wish, I could create a Perl "live support" desk, like that PHPLive by OSICodes(open source industry codes).
That would rock.
(hint hint, if someone knows how to make Perl do something like that, please let me know)
That is they only REAL difference I see. I think that Perl has much better support, since it's been around much longer.
thx,
Richard
| [reply] |
|
It's not the PHP doing the work it is javascript and DHTML in the web page via a technique called "Remote Scripting".
Basically the javascript makes Remote Procedure Calls to a server and loads data in the background preventing a refresh of the page and allowing "constant" two-way communicatin between the browser and the server.
So the backend server application can be written in anything as long as the javascript client and the server speak the same RPC mechanism.
Search for "remote scripting" javascript perl on google.
Here is a decent start:
- http://developer.apple.com/internet/javascript/iframe.html
- http://www.paranoidfish.org/boxes/2002/04/17/
- http://www.paranoidfish.org/boxes/2002/01/30/
--
Clayton aka "Tex"
| [reply] |
|
I have seen ONE THING, that PHP does, that I have not yet seen Perl do.
I have seen several.
- PHP has one central website for news, documentation, downloads, etc (php.net). Perl websites are scattered all over the place: perldoc, useperl, perlfaq, etc.
- PHP is very easy to install. mod_perl is not.
- PHP is open source, but has significant corporate backing (i.e, Zend) that Perl lacks.
- The PHP community is trying hard to make the next version of PHP a worthy contender to Java in the Enterprise world. The Perl6 community could care less.
- PHP makes the easy things even easier. :)
perl -e "print 'Just another PHP hacker!'"
| [reply] [d/l] |
|
|
|
|
|
|
|
|