|
Re: Another prediction of Perl's demise
by tachyon (Chancellor) on Nov 25, 2004 at 03:36 UTC
|
You gotta love the depth of knowledge displayed by some people.
CGI aka The Common Gateway Interface is a set of rules that describe how a Web Server communicates with another piece of software on the same machine, and how the other piece of software (the 'CGI program') talks to the web server. Any piece of software can be a CGI program if it handles input and output according to the CGI standard, and that software can be written in a wide range of languages. In a web context PHP is just as dependent on CGI as Perl. You can directly hack on the Apache C api with Perl, Python, PHP, etc which bypasses the CGI interface in favour of another interface. Unlike PHP however, Perl sees broad application outside of a simple web context.
Within a web context there is no doubt that PHP is increasingly popular and if the web is where you want to work it would be wise to become familiar with PHP, Javascript, and Java as well as what I presume is a core of Perl, Apache, HTML and SQL.
| [reply] |
|
|
In a web context PHP is just as dependent on CGI as Perl.
That's only true if by "just as dependent" you meant "not dependent at all". PHP is very commonly used via an Apache module, mod_php, which does not use CGI. Perl is not tied to CGI either, because we can use mod_perl. We get a performance benefit with mod_perl, as with mod_php, but we also get much more power. Not only is the originally quoted doom-sayer wrong on the face of it, he's wrong on substance too.
| [reply]
[d/l]
[select] |
|
|
No, to be pedantic, tachyon is exactly right. PHP and Perl both can run either as CGI or as mod_(php|perl). They are both equally dependant on CGI ;)
| [reply] |
|
|
|
|
The only difference between mod_cgi and mod_perl/mod_php is what level the CGI interface is decoded at. The browser itself sends the same data no matter what.
Under mod_cgi, the server guarentees certain environment variables and how the standard filehandles are setup. The server might modify the output headers slightly (though it definately won't under NPH).
Under mod_perl/mod_php, the server has already done much of the work of deparsing the browser's request, and may significantly alter the output before the response finally goes back. With mod_perl2, the potential for output-munging is even greater with the use of filters that are applied after the CGI or main handler has run.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply] |
|
|
|
|
|
|
On the other hand, some tasks that are absurdly easy to accomplish in PHP are a relative (though very minor) pain in the arse in Perl. For example, try comparing the process of getting the contents of a text file into a variable in Perl vs. PHP. Hint: In PHP, you only need one function in a short line of code.
$foo = require("bar.txt");
| [reply]
[d/l] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| [reply] |
Re: Another prediction of Perl's demise
by dimar (Curate) on Nov 25, 2004 at 08:04 UTC
|
I'll keep telling myself that Perl is for *real* web programmers, and everyone else is just jealous.
It can't hurt to know PHP and ASP as well, if for no other reason: you can be more informed when proseletyzing the misguided "fake" programmers out there, by informing them of the benefits of perl ('translated' into whatever language they 'grok').
Not to get in the way of your love-fest, but the best way to fight off insecurity and fears of being a cocktail party punchline is to keep learning. Learn *all* the tools of the trade and don't take it personally if a customer stubbornly insists that you use a programming language that is (in your view) obviously inferior. As long as their checks don't bounce, what is the problem?
It would be nice if everyone understood why Perl (and perlmonks) is so great, but not everyone does, and most of the religious anti-perl zealotry is little more than a mask to hide the fear that comes from ignorance. These days there is just way too much freely available information (especially for a seasoned perl programmer with over four years of experience) not to be able to gain competence in the other schools of thought, and to be able to switch between them. That is, unless you are doing *highly specialized* work, in which case it doesn't matter what languages are "most popular" because you already have your "niche".
| [reply] |
|
|
It would be nice if everyone understood why Perl (and perlmonks) is so great, but not everyone does, and most of the religious anti-perl zealotry is little more than a mask to hide the fear that comes from ignorance.
It'd also be nice if Perl zealots understood the limitations of the language. I can see some real cool ideas in type inferencing, for instance. When I look on a site like Lambda the Ultimate and see Perl derided for ignoring the benifits of a real type system, I can't help but agree.
But PHPers have no right for anti-Perl zealotry in this regard.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply] |
Re: Another prediction of Perl's demise
by BUU (Prior) on Nov 25, 2004 at 02:36 UTC
|
Well, take heart in the fact that if they believe "perl relies on CGI" then they are pretty stupid =]. | [reply] |
Re: Another prediction of Perl's demise
by The Mad Hatter (Priest) on Nov 25, 2004 at 03:20 UTC
|
You can refute the speed argument with the excellent mod_perl for Apache. And be sure to bring up the concept of having different namespaces when talking about PHP. | [reply] |
|
|
PHP5 fixes a lot of issues, including namespaces. In fact, my personal checklist of things that annoy me about PHP compared to Perl are pretty much taken care of in PHP5. Now I just have annoyances that I can't quite articulate.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply] |
|
|
| [reply] |
|
|
Well that's good to hear (at least from a nonbiased standpoint ; ). I will admit that after first comparing Perl and PHP, I've never really given PHP a fair shot again.
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
Re: Another prediction of Perl's demise
by kiat (Vicar) on Nov 25, 2004 at 03:44 UTC
|
Hi bradcathey,
Haven't seen you around for a while :)
I toyed with PHP a couple of days ago. Didn't go too much into it but it did give me an idea of why it's increasingly becoming popular for building dynamic sites: ease of use simple to use.
With perl, there's a little bit more work involved e.g. using "use CGI;" whereas with PHP, things like retrieving cookies can be done with a global variable without having to import any modules.
PHP seems to me to be a (blessed) marriage between Javascript and Perl: Javascript because of the ease with which php code can be called from within an html page; Perl because it has syntax quite similar to perl.
For simple dynamic sites, it's tempting to use PHP. But once the site gets larger, maintenance might become problematic because of global variables.
Perl's survival doesn't depend on its popularity with CGI stuff. If it did, then the work on Perl 6 would have been a waste, imho.
| [reply] |
|
|
Thanks, kiat. Yeah, I've been out of development for a while--doing boring old print work.
After being chided here at the Monastery for not using -T or -w or strict or some other convention, when I first started working with PHP I was taken aback by it's casual approach to such issues. I felt like I was cheating. And oh, those 'for' loops--goofy.
But I think tachyon is right, I need to have a working understanding of PHP. I just hope I don't have to bow to the gods in Redmond and start learning ASP. I might just open up that bait shop I've always wanted.
—Brad
"Don't ever take a fence down until you know the reason it was put up." G. K. Chesterton
| [reply] |
|
|
I have never used ASP, and for some reasons, I just don't like it.
Between ASP and PHP, it's definitely PHP for me (I think friendster is coded in PHP).
Yah, it's definitely good to know PHP.
| [reply] |
|
|
|
|
|
|
| [reply] |
Re: Another prediction of Perl's demise
by hardburn (Abbot) on Nov 25, 2004 at 04:15 UTC
|
There is a whole list of things I dislike about Perl. Most of them involve largely academic concepts that matured after the first versions of C (like type inferencing and clean OO). Exactly zero of these issues are fixed in PHP, or any other mainstream language, for that matter.
The reason I'm so excited about Parrot is that I hope to finally use languages that support these things without having to worry about it interacting with a legacy code base.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply] |
Re: Another prediction of Perl's demise
by stvn (Monsignor) on Nov 25, 2004 at 13:58 UTC
|
bradcathey
Everyone here has made excellent points. I have a couple of suggestions to add.
- Learn PHP. It's enough like perl you should feel comfortable with it pretty quickly, and despite perl's obvious superiority, PHP has it's usefulness.
- Learn ASP. I despise VBScript, but you can use Javascript with ASP without installing anything special (it's a standard option with ASP). Also, ASP (pre-.NET) is really just an set of COM objects which you script together, so its amazingly simple to learn and use.
In the end I would not listen to any article which claims that A is "in fast retreat" and B is "simple the best choice". Almost certainly the author has a limited (if at all) understanding of A, and is in love with B. Pmachine for instance is a PHP product, so clearly they are going to sing the praises of PHP, otherwise they would look kinda stupid :)
As for the "loosing a big project to an ASP shop", I think this should tell you that you need to expand your skillset. The customer is always right (even when they are wrong). I once worked on a project where the customer dictated we use BEA WebLogic J2EE server with an Oracle database on Solaris to build their site with. The site consisted of several static pages (400+) a message board, and a registration page. (A classic example of using an Elephant gun to kill a flea) We could have done the whole thing with Perl/PHP, MySQL and Apache on Linux and saved them thousands of dollars in lisence fees, but they would hear none of it.
I'll keep telling myself that Perl is for *real* web programmers, and everyone else is just jealous.
Bah! Real web programmers use Postscript ;-)
| [reply] |
Re: Another prediction of Perl's demise (Who cares?)
by BrowserUk (Patriarch) on Nov 25, 2004 at 14:16 UTC
|
I don't get this? It comes up every now and again, and I never do get it.
Who cares if someone says something like this? Does their saying it, make it so?
The very worst that could happen, is that everyone who currently uses Perl, would move to using some better language. For that to happen
- There would have to be a better language--by whatever measure "people" make that judgement.
- That better language would have to be at least equal value to Perl--it'd be damned hard to beat it.
If that situation arose, then I would probably switch to it too. Why not? If it is better, then wouldn't it be foolish to stick with an inferior language?
Of course. IMO, there are no immediate signs of that happening. And the only prospect I am aware of on the horizen also happens to be called Perl. Same designer. Same stable of thinkers and developers. If it turns out to be a superior language, which certainly seems likely, despite my reservations about lots of details, then wouldn't it be silly not to adopt it?
Anyone who decides to switch to PHP because someone else told them "it's better", probably also switches their brand of deoderant every week, as the advertising on TV changes.
Examine what is said, not who speaks.
"But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail
"Time is a poor substitute for thought"--theorbtwo
"Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
| [reply] |
Re: Another prediction of Perl's demise
by TimToady (Parson) on Dec 01, 2004 at 09:10 UTC
|
If Perl isn't dying, what about this? | [reply] |
|
|
That's about Perl putting others to rest... ::-)
| [reply] |
Re: Another prediction of Perl's demise
by Your Mother (Archbishop) on Nov 25, 2004 at 07:13 UTC
|
It's also good timing b/c the current, October 2004, Google Zeitgeist has perl programming as the #2 pop tech query for the last month; coming in just after software. Reports of the demise are as ignorant as exaggerated. There is always room for another good tool in the box and only a poor craftsman blames tools he doesn't even use. :)
update: props to David Innes on the SPUG list for brining the Google item up.
| [reply] |
Re: Another prediction of Perl's demise
by cLive ;-) (Prior) on Nov 25, 2004 at 19:24 UTC
|
PHP has become the de-facto scripting language on the internet, putting CGI into fast retreat
I wouldn't worry too much about someone who doesn't know that PHP uses the CGI as well. PHP wouldn't be much use without the CGI!
We just patched 5,000 installations of PHP BB. The hole was that you could declare a global variable within the query string (oo, that's CGI ;-) that would include a remote file. Any web language that easily lets you include a remote file is asking for trouble!
Don't get down Brad! We're a Perl team of 7 and growing. Feel free to drop a resumé over if you ever feel like moving down and left a bit ;-)
Added bonus is that our office is about 200yds from tilly's, and there are a bunch of other Perl hackers close by - though, being Mr Dad, I've managed to miss the last two LA PM meetings, so I don't know who they all are :)
When I get stressed out that crap tech is doing things that Perl should be, I just remember this quote from Paul Graham:
During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried. - source
...and kick myself that I still haven't got my head around Lisp ;-)
I think the thing with Perl is that there's no marketing plan, because there's no major, expensive technology to sell with it. So, just because you don't hear a 'buzz' around Perl, it doesn't mean that it's dying (unless Netcraft confirms it :)
Next time the paranoia comes, just remember that Ticketmaster not only built most of Template::Toolkit, they also eat their own dog food, and that many other companies are quietly using Perl to do good and great things (heck, even we have a few people using out host management system :)
Happy thanksgiving*
cLive ;-)
*I'm surprised thanksgiving isn't celebrated in the UK - "Puritans? Want to leave? No, not a problem. Here, take my boat" - well, that's how I think it went :)
| [reply] |
|
|
| [reply] |
Re: Another prediction of Perl's demise
by rev_1318 (Chaplain) on Nov 25, 2004 at 12:23 UTC
|
There is simply no better choice to build your web community with.
unfortunately it is used by lots of people who haven't got the faintest idea about security, good programming techniques etc. Each day, at work we are confronted with hacked websites, servers and accounts due to forum software written in PHP, database interfaces written in PHP and e-mail forms written in PHP. I'm not saying that there aren't any good PHP programs, but there is just so much crap, it's giving a few of my collegues a full days job cleaning up after them!
Taint checking and strictures would be a major improvement in PHP, bus I fear that will never happen (It forced to many people to actually write solid code, in stead of quit 'flexible' scripts, leaving it to the system administrators to clean up after them.
Paul
(on behalf of his overworked collegues) | [reply] |
|
|
Taint checking and strictures would be a major improvement in PHP, bus I fear that will never happen
Heck, it'd already be much more enjoyable if it had such little nifty features that we, spoiled Perl Monks, take for granted, like lexical variables and anonymous functions. And the combination of those two: closures.
| [reply] |
Re: Another prediction of Perl's demise
by zentara (Archbishop) on Nov 25, 2004 at 13:52 UTC
|
You know, anyone can write articles and put them out there...it dosn't mean a thing if it dosn't make sense. Perl programmers could write articles lambasting the narrow scope of PHP, but Perl programmers seem to have more "self-respect" than that; preferring to not stooping to that level. Apparently PHP programmers feel the need for self-assurance that they are using the "right language".
Ask a typical PHP programmer to write something that is not "for the web"? You will get answers like "that can't be done", or "you need a local web server and a browser interface". With Perl all that stuff can be done easily. So why waste time on a language with such a narrow focus as PHP?
I see more and more, that peer-2-peer connections, with encryption, using sockets and no web server, is where the "real action" is at. Compare PHP and Perl at doing those kind of things, and low-and-behold ... Perl wins hands down, leaving all those PHP programmers wondering why they wasted so much time learning a tool that is only useful on the web.
I'm not really a human, but I play one on earth.
flash japh
| [reply] |
|
|
"Waste time on PHP" because it's not wasted time.
PHP is a language that has its uses, and its design is such that it can accomplish some (yes, narrow) tasks much more easily than Perl can. I increasingly find, in my own web development work, that a given project is best served by a combination of PHP and Perl. Perl gets used to manage the files for a dynamic website, and PHP gets used to render output to the browser, for the most part. There is some crossover, and even some interaction between the two.
Neither language is as absurdly useless as something like Whitespace. Each has its uses, and each is better at some things than the other.
I would recommend learning both quite thoroughly for any web programmer. If, however, you are only going to learn one (or if you don't really do much/any web programming), I definitely recommend Perl over PHP as the more versatile, and ultimately more powerful, tool.
| [reply] |
|
|
| [reply] |
Re: Another prediction of Perl's demise
by nmerriweather (Friar) on Nov 29, 2004 at 02:16 UTC
|
I dont think Perl is threatened by anything, but I do see lots of developer jobs switching to .NET programmers
Microsoft is increasingly doing 'technology partnership' programs with large fortune500/blue chip type companies that don't really make much sense to me. In exchange for cheaper site licenses, hardware discounts, etc, management agrees to go 'Only MS' -- and phases out most custom internal stuff, web and email to .NET. Its one of those really bad management decisions that a CTO or director or IT who has never used a computer but has two MBAs makes. In any event, from what I've seen in the office's of my firm's clients who are partners, they 'phase out' all the perl/c/java programmers (mostly comp-sci degree holders), and 'phase in' MS certified developers (mostly high school graduates who went to DeVry Technical School for 6 months). My company offers a 'clean up' service to fix all the messes these new codemonkeys make.
Anyways, as I see more and more of 'Corporate America' make increasingly bad IT decisions like that, I worry about the other languages. (although I feel good when i think of WallStreet -- which runs almost entirely on Perl and Java)
Perl has, and always will be, the reigning text processing language. More than anything, I think this is because of the way RegEx is handled in perl. Its intuitive and simple -- any other language that uses PCRE gets the job done, but not as easily.
PHP is great for small-midsize web development. Non-programmers can pick it up fast. Seasoned programmers can pick it up faster. It has a history though of security issues from version to version. Its also really bad for non-web stuff -- its not limited to web development, but you should really limit use of it TO web development. Die-hard php fans will show you all the "great stuff" they make with php for commandline or GUI execution.
I don't think perl is any more "stricter" than php in terms of style, conventions, or coding practice -- they both allow for code that is awful to read, write, or execute. Its the nature of a language. PHP just makes it a whole lot easier.
I use Perl for all my web templating, text processing, and large web applications (because I like mod_perl). I can write and run code fast enough for those applications.
I use php for all my simple web apps -- quick input forms/mailer scripts, client login/authorization galleries, messageboards etc -- the development for that is really fast, and directories of files pretty much "drag and drop" with little or no configuration.
If I could choose what language to work in all the time though, I'd actually choose python. Its really fast to code, incredibly easy to read, and can let me accomplish 100lines of perl code in 20lines of python for some projects (and 100lines of python code for 20lines of perl on others). I don't like text-processing with python though, and it doesn't work well in apache (scripts have a significantly longer startup than perl, and mod_python is complex). The Twisted python library has a lot of amazing web and protocol services, but is based on the premise of writing an applicaiton server (so your script binds to a port as a webserver (or whatever server)) -- which is just overkill a lot of times.
Anyways, the point i'm trying to make, is that I think that perlmoks are smart enough to know that people should use 'the right tool for the right job'. Sometimes the job dictates the tool, other times the user dictates the tool. Giving up on a language or using it just because its in/out of fashion isn't really doesn['t work though.
| [reply] |
Re: Another prediction of Perl's demise
by Juerd (Abbot) on Nov 25, 2004 at 16:55 UTC
|
If you fear that PHP might in any area be better than Perl, then let this document convince you that that is not true.
Superficially, it may seem that its security on the web server, where all users are mutually untrusting and untrustable, makes it the best tool available. And from a sysadmin's point of view, that is true. But for programmers (real ones), PHP makes life hard.
See also what scrottie said.
| [reply] |
Re: Another prediction of Perl's demise
by Zed_Lopez (Chaplain) on Nov 30, 2004 at 13:40 UTC
|
I recently went 9 months unemployed. Without having actually kept records, I'd say that upwards of 80% of web programming jobs I saw listed for San Francisco or the East Bay were evenly split between Java and MSFT technologies. PHP was most of what's left -- probably half again as many listings wanted PHP than wanted Perl. I only recall seeing Python mentioned once.
We have lost a lot of mindshare to PHP. PHP has some advantages for small or medium web apps one intends for wide distribution, due to ease of installation over a mod_perl app.
But I recently evaluated PHP as a candidate for a large project at work, and I really can't understand why anyone would choose PHP for a large project... It has a global namespace for functions, giving rise to an expectation that you should manually prefix every function name with its module name, and leaving you to hope for the best that everyone did the same if you use more than one third party module. It has three thousand built-in functions, with wildly inconsistent naming schemes, and inputs and outputs, guaranteeing a trip to the manual to do anything. It has a large dependence on global variables.
One of the things that strikes me about PHP is that lots of the criticisms of Perl are a hundred times more true about PHP. The core language is bloated and tries to do too much, it's inconsistent, it's impossible to know the whole language, it lends itself to poor practices...
I think PHP's a classic example of worse is better. It has a lower barrier of entry than anything else (well, except probably ASP, but I haven't used that) for someone wanting to start doing web programming. It did something lots of people really wanted, that seemed much harder in other languages. So it spread like kudzu until, today, there are large web companies doing their development in PHP. I think we're going to see a lot of buyer's remorse in 3-4 years when they've had to maintain these.
Something that does worry me, though, is that there are people who will never even try Perl because they've heard so much FUD about how ugly it is, or how it's write-only code that's impossible to read or maintain, or how it's wildly inconsistent. Sadly, some of those people no doubt should be Perl programmers by temperament, and might never know it.
I think we could really use more visible Perl applications, to implicitly convey the message of how useful Perl is. I'm not convinced Perl couldn't fall into decline. I think countering the FUD and changing the perception of Perl that exists among much of the non-Perl programming world is needed to avoid that. Perl 6 and Parrot should help a lot in that regard (though some of Perl 6's choices, like the unicode operators, are going to make for awfully easy cheap shots.)
| [reply] |
|
|
Zed_Lopez, thanks for the thoughtful real-world overview of the languages being used out there, at least in your very practical experience.
As a person who is in the "branding" business by trade, your post got me to thinking about the possibilities of branding Perl. Branding is more than logos (camels in this case). In short, branding is the sum total of all the perceptions one's audience has about the branded entity. Unfortunately, the FUD of which you speak is part of Perl's brand. On the positive side there is CPAN, Perl's unique features (name spaces), and, of course, the Monastery;^)
Branding takes lots of resources, both in time and money. We can all do our job, as I think most Monasterians are inclined to, by using good coding practices, talking up the virtues of the language, refining it make it more approachable or friendly, addressing or deprecating it's weaknesses, and writing applications that gain more universal notoriety (imagine a PerlMyAdmin gui or PerlBB Forums).
We all know that intrinsically Perl is a great language, but for some reason it doesn't feel as handy to the larger audience of Web programmers (my arena) as PHP. Who is to blame....or get the credit for that? I reach for Perl everytime because I have a good grasp of it and it feels familiar. What can be done to bring PHP (or ASP or JSP) coders to that same point? Where has the Perl community let the opportunity slip away, and what can be done to regain the edge?
In summary, doesn't sound like a language problem as much as a perception problem. What can we all do to change that? Rhetorical, but worth pondering.
—Brad
"Don't ever take a fence down until you know the reason it was put up." G. K. Chesterton
| [reply] |
|
|
I think we need better installation processes for both web apps (including mod_perl apps) and other apps, where better = easy for not especially technical people to use.
And where possible, we should, politely, and with specific technical points, call others on their BS about Perl (like I'm doing here where a Python programmer smugly pronounced he recreated Quantum::Superpositions in 100 lines of code... apparently without even realizing that he left out the hardest part.)
Heh. I was just going to take my own advice and leave a comment on some annoying inaccuracies in a PHP vs. Perl weblog entry by a PHPer (which is one of Google's top ten responses for 'PHP vs Perl'), but the site's gone 404 (the link's via the Wayback Machine.) That's a damn shame.
And, of course, we need Perl 6, which cleans up a lot of Perl 5's syntax, gotchas, and, frankly, lame OOP support.
| [reply] |
|
|
I could potentially have been one of those people using PHP that would never realize he should have been a Perl programmer. I was using (and still use) PHP for website development (mostly for inline conditionals to manage content includes, actually). It took my Linux conversion to open my eyes to the Wonders That Are Perl, and now here I am.
Thank goodness for a properly designed OS and a great system administration language to go with it.
| [reply] |
Re: Another prediction of Perl's demise
by TedPride (Priest) on Nov 25, 2004 at 16:04 UTC
|
mod_perl isn't available on many servers, and without that, PHP outperforms Perl. It's also easier to embed a few lines of PHP inside your page than it is to wrap your page around the equivalent in Perl code, leaving Perl the winner only in situations where (a) you have root on the server or (b) you're doing some algorithms-heavy programming where Perl's power and coding efficiency makes it the better choice.
Basically, PHP is designed to be easy. Perl is designed for coding efficiency. Most people are going to prefer the former if they have to choose between the two.
Learning both is best. | [reply] |
|
|
Basically, PHP is designed to be easy.
Wow, really? I'd never have guessed that. No, really, I think programming in PHP is hard. Scripting web sites, OTOH, can be done easily, as long as all you need is just a little more than templating.
| [reply] |
Re: Another prediction of Perl's demise
by spoulson (Beadle) on Nov 26, 2004 at 21:30 UTC
|
FWIW, ASP is ok when used with Perlscript. I choose not to use PHP because I already know a similar language that does the same and more.
Is there a repository for PHP similar to CPAN? There are so many powerful modules on CPAN that I wouldn't know where to begin to brag as a Perl coder. | [reply] |
|
|
PHP Extension and Application Repository
It's not quite up to CPAN's standards, but it serves a similar purpose for PHP that CPAN does for Perl.
| [reply] |
Re: Another prediction of Perl's demise
by Anonymous Monk on Nov 26, 2004 at 22:17 UTC
|
PHP is a specialized tool. You cannot compete with that without going the distance, such as mod_perl or whatever other methods. So yeah, it is going to benchmark faster, probably.
However, in a decent-size shop, you quickly realize the importance of good code organization and such, and I think that Perl is much better at this when compared to a lot of languages out there. Enterprise-level apps are a very lucrative market, and I'd be a lot prouder to capture a thousand mid-to-high-range shops than a million tiny PHPBB websites.
Anywho, in Perl I can implement my own damn HTTP server if I like, and it will be even faster. And getting the first prototype up and running would still take about a day. That's where there is a lot of (often unnoticed) power for Perl: ability to quickly bring up pretty stable and usable solutions in a diversity of situations. Those solutions then either end up staying there, or are replaced by a dedicated tool that does the job better (and is appropriately more expensive/less versatile).
| [reply] |
|
|
| [reply] |
Re: Another prediction of Perl's demise
by JSchmitz (Canon) on Nov 28, 2004 at 04:03 UTC
|
Perl is for much much more than just web stuff...
JS | [reply] |
Re: Another prediction of Perl's demise
by Juerd (Abbot) on Nov 25, 2004 at 17:13 UTC
|
| [reply]
[d/l] |
|
|
| [reply]
[d/l] |
|
|
| [reply]
[d/l] |