Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

PHP, Perl, Java Servlets - What's Right For You?

Hemos posted more than 13 years ago | from the learning-'em-all dept.

Programming 254

Sean writes "Take a look at this comparison of Server-side scripting languages. The article explains how PHP scripts, Perl CGIs, and Java servlets work. It can help you decide whether to use PHP scripts, Perl CGIs, or Java servlets for your next Web development project. It also covers the issues that separate the three languages and provides all the source to test their differences." Right tool, right situation. That's all I have to say.

cancel ×


Sorry! There are no comments related to the filter you selected.

Re:PHP rocks... (1)

Micah (278) | more than 13 years ago | (#274973)

PHP is faster than Perl/CGI, but I'm pretty sure mod_perl beats them both. PHP has to re-interpret each script every time it's run, while mod_perl caches a psuedo-compiled version. Unless, of course, you buy the Zend Optimizer, in which case you'd get the same benefit with PHP. But then you'd be introducing unclean (closed source) software to your web server.

Re:Crappy article (1)

pohl (872) | more than 13 years ago | (#274975)

It's very fast execution-wise, in my experience. One can write naive, slow code in any language. The most common example I see in the java/servlet universe is establishing fresh database connections for each HTTP hit, rather than pooling them. If one does that, it'll be slow for sure. If one knows what they're doing, on the other hand, java/servlets/jsps can be very fast.

Re:ASP? (1)

Bake (2609) | more than 13 years ago | (#274982)

Considering ASP is crap (and yes I do speak from experience, over a year at that), I think it's ok to skip it in this discussion.

Re:ASP?? (1)

Bake (2609) | more than 13 years ago | (#274983)

more components? In order to get the least bit productive in ASP you'll need a few THIRD party components (for which support isn't always all that great, not to mention licensing complications). So, NO ASP does NOT have more components than say php or perl.

Re:ASP is doubleplus ungood? (1)

Bake (2609) | more than 13 years ago | (#274984)

Not if you don't want to. OK, granted. ASP is OK for people who don't know the first thing about dynamic content. It only takes a couple of days for a newbie to get productive (that's how it was in my case anyway). HOWEVER... as weeks and months went by I came to realize how crippled ASP is, for instance it doesn't come (de facto) with an easy and comprehendable way of saving uploaded files, I did not find a way to use a special mailserver to send emails. Granted this is mostly because of how NT Server is set up, but it's an annoyance. And how do we deal with these annoyances? The easiest and most common way of doing things was to purchase 3rd party components that helped make this easier. And when you do that you have to worry about licenses and it all ends up being a pain in the ass, and of course in the end you blame ASP for being such a piece of crap. --- I know my english is bad, I'm hung over.

Re:JavaServlets (1)

consumer (9588) | more than 13 years ago | (#274987)

The main reason that Perl, despite its poor performance compared with PHP and Java, is so cool is the regular-expression stuff that's built in.

Poor performance? What are you basing this on? When my company was deciding between mod_perl and Java servlets, we looked at a benchmark by the folks at Caucho, who make the Resin servlet runner. Their test seemd to show Java doing better than mod_perl on Linux. Then we looked at their code. The mod_perl stuff was not coded optimally. We fixed it, and added some more tests that used Oracle for simple interactions. The results showed mod_perl beating Java servlets by a significant margin, even on the fastest (at the time) servlet runner and JVM (from IBM). This was a year ago, and both Perl and Java have new releases since then, but the point is that you should check your assumptions when it comes to server-side performance of languages.

Re:close... no cigar (1)

Dg93 (10261) | more than 13 years ago | (#274988)

Funny, but most of his comments seemed to be geared towards other issues, such as ease of development/deployment and extensibility.

I'd rather have my page designers working with jsp, giving them a handful of well documented, custom tags to do the dynamic stuff, than try to either a) have java programmers do page design or b) page designers to java programming.

Re:Disappointed... (1)

Dg93 (10261) | more than 13 years ago | (#274993)

I have issue with a lot of the 'points' raised in this article, however...

(Let's ignore the fact that they're using a rather idiotic way of using jsp in their article - and in fact, it's rather plain to see that the article is written in a way that displays only a very minimal knowledge of jsp).

So - their first point, is that since Velocity code isn't embedded between tags, it makes it 'easier to see what's going on' when you bring up the page in a browser... Forget the fact that the way Velocity does things would completely destroy the appearance of layout if you just bought the page up in the browser (compared to, most of the jsp pages on the project that I work on, which a browser can actually display most of the layout with very few issues).

Honestly, though, when i have code in a jsp page (or a cgi script, or a, or a) - i almost -never- load it up straight into a browser. There's too much context that would be missing (and this is ALSO true for velocity!)

So - their first point is a weak one.

Let's go on to the second one...

They complain about the way that JSP works, in that it compiles down to java/class files, and that a temp directory could 'grow without bounds'! First off, I've been running production jsp engines for nearly a year and a half now - and I have -never- seen a temp directory grow in the way that they're afraid of, even in a development environment.

In addition, they also seem to be under the mistaken impression that JSP output isn't buffered by default. For a group that's working in the context of Apache's Jakarta project, i'm surprised that they don't seem to understand that JSP output IS in fact buffered.

Last but not least, they use a set of what the java generated from jsp looks like... Here's a clue - end developers never even need to see that stuff...

Now, onto their complaints about error handling...

This section is actually halfway decent, and isn't as full of the erroneous assumptions of other sections, but again, they use bad code examples (e.g. they do an if( true ) throw Exception() and then complain that there's a 'statement not reached' error because of code generated further on in the page - please...) They also completely miss the fact that if you want to - you can handle exceptions right in the page, in fact, I didn't see anything in their comparision about how to handle runtime errors such as this in the velocity engine. tsk. tsk.

I will grant them that at times, a JSP engine can throw out ugly errors, but i've never had it throw anything out that was difficult to deal with (and most of the time, the jakarta engine gives enough proper line number information to be able to find the exact line of the error).

They then go on in the next section to complain about how java beans are accessed in JSP pages... In our 200+ page JSP application, we don't have a single jsp:useBean definition. Nope - instead, we have defied jsp tags (*gasp* - yes, they seem to be so far ignoring the fact that you can define your own set of tags for jsp) that export necessary objects and provide needed functionality. Our application design is separated enough that it's a rare thing to have actual java code/scriptlets in our pages. (Unfortunately, I can't see a way to do a velocity page without their velocity code)

Of course, they do finally hit on tags, but again seem to be doing stupid things with their tags. Honestly, between you and me, if I ever had a (non-junior) developer underneath me write JSP code like this, I would either a) have them rewrite the code or b) fire them on the spot.

They seem to feel that extra typing is a bad thing (even if it makes the layout inconsistent - and yes - throwing #blah tags into the middle of an HTML page is inconsistent compared to a well formed XML document.

They also go on to claim that JSP is pigeonholed to -just- produce HTML. Man, am I glad they cleared that up for me, I must be doing something horrifically wrong, what with outputting XML and WAP, along with HTML, as well as formatted text.

Now - they finally get on to something that Velocity -may- have an advantage in at this point, embedding in other applications. However, this is an implementation issue, not a language/syntax issue. (And in fact, I have been able to embed jasper with relative ease into my applications - yes, you need to gasp *know java* to be able to do it...)

They then move on to some FUD, that because JSP is a 'new' standard it is unstable (and where, pray tell, is velocity's standard? Oh, that's right, its on their TODO list), and feel that the advantage to velocity is that there's only one implementation (as opposed to multiple jsp implementations (which, for the record, I have not had any problem moving code between)).

They then move into a hosting argument, that allowing people you host for to put java into their pages is a bad thing, because they could write something that uses up system memory! (Like, oh, say a CGI...). Of course, because velocity only has foreach, and no for, there's no way to do an 'infinite' looping situation to build up memory (poor, poor, naive developers, give me a day with velocity, and i can probably write something that will throw your server down to the ground performancewise :). They also completely miss the fact that it's fairly easy to limit functionality with Java's security mechanisms... Of course, the gods forbid that someone managing a server that does hosting -understand- what they're providing.

This document is FULL of FUD, up one side and down the other. And it is a shame, because it looks like velocity may actually have the potential to be useful, but to build their entire argument on a set of horrific misconceptions about jsp development, without trying to -really- understand what's going on... well, that pretty much ensures that it will never be used on any development project I work on. (Sorry, I'd really rather not use a project bourne out of such naivite). This strikes me as a project that was started up because someone spent a day with JSP, got discouraged, and started thinking of other ways to do things - re-inventing all the problems of older CGI/scripting solutions. Yippie. (Gee, what will we see first, an HTML editor that understands JSP or an HTML editor that understands velocity? Hrm.... :)

I'm sure there may be deeper benefits/issues to velocity - this is based soley on this one particular article 'justifying' velocity's existence, and showing all the 'problems' with jsp.


Re:Disappointed... (1)

Dg93 (10261) | more than 13 years ago | (#274994)

No, shit, really? I've done implemntation work for jsp, I know what goes on in jsp engines. One of the reasons we use jsp is -because- we can provide well defined tags that our HTML designers can use and be happy with.

I wouldn't expect a designer to code in velocity anymore than I would expect them to write scriptlet code. But I can have them put tags around their page to ensure that we can template the look and feel of the page in a trivial fashion, or use tags that automatically backfill from previously entered data (or pull their data from a supplied object).


What about Embperl? (1)

Wim Kerkhoff (14333) | more than 13 years ago | (#274999)

What about the other embeded languages? HTML::Embperl ( can do exactly what PHP does, except you have the power of perl (such as all the modules on CPAN) at your hands...

Re:JavaServlets (1)

mkozlows (21830) | more than 13 years ago | (#275002)

There are several free (both senses) regular expression packages out there that work quite well. You can find two of them at the Jakarta Project's web site:

Re:close... no cigar (1)

mkozlows (21830) | more than 13 years ago | (#275003)

Far from being "a morbid joke", I've found Java to be one of the best languages for server-side development on Unix. I worked for two years writing server-side Perl apps (with CGI and mod_perl). When I first switched to Java, I was somewhat irritated by it -- but after getting used to its way of dealing with the world, I find it to be more powerful, faster, and far more maintainable than Perl.

Of course, if you haven't done anything with Java since the bad old days of JServ, you can be forgiven for your dismissal. But go download Tomcat and see how well modern Java works.

Re:I don't hire "Java Programmers", even for... (1)

mkozlows (21830) | more than 13 years ago | (#275004)

This may be true now, because most people who have a CS degree (and thus are more likely to understand things at a level greater than the superficial) learned C++ for their degree -- so the people who only know Java, and not C++, are the casual accountants-cum-programmers.

With the move to Java as a primary teaching language, this is going to be far less true in the future. Those people with CS degrees, who've taken classes in assembly language, computer architecture, and symbolic circuit design, will all have learned Java, and not many of them will know C++.

Java part mis-leading as always (1)

scode (22551) | more than 13 years ago | (#275006)

First of all, servlets *ARE NOT* a scripting language. A servlet is a class that extends javax.servlet.Servlet. Period. The most common form is the javax.servlet.http.HttpServlet. They are classes that implement a certain interface. It's got nothing to do with scripting.

And as has already been pointed out, comparing servlets with PHP is ludicrous. What they should be comparing is *JSP*. JSP (Java Server Pages) are HTML that gets converted into a servlet (and then compiled and run) by the Web Application Server. So yes, servlets are involved. But JSPs clearly fit the description "Java equivalent of PHP" much better than servlets. Servlets are the building blocks of JSP; but comparing PHP to servlets is like comparing JSP to PHP pages without HTML in them (i.e. everything is done in the form of code).

/ Peter Schuller

One note though (1)

scode (22551) | more than 13 years ago | (#275007)

I agree with the conclusion however. At least, if you don't know PHP, perl nor Java, servlets are obviously more difficult than PHP or Perl, simply because it's just yet another application of Java. And in order to use it efficiently, you need to understand OOP, and be familiar with the Java API.

/ Peter Schuller

Try them all, then try ZOPE (1)

Phill Hugo (22705) | more than 13 years ago | (#275008)

Zope is to PHP, JSP and Perl as The GIMP is to using a HEX editor to make XPMs

Re:PHP rocks... (1)

Phill Hugo (22705) | more than 13 years ago | (#275009)

No, not really. What matters is...

1. Is the development time so long that buying faster hardware would be cheaper than building it in something just 'faster' at runtime (PHP isn't fast anyway - its just faster than its peers)

2. Does it work (this means does it support transactional operations, simple distribution and integration with third party application that customers may already be tied to.

The above items alone are the prime reasons why Java solutions are very popular. Enhydra is better than PHP by a long way. Don't get me wrong, I like PHP and have built some very complex sites in it but these days I use Zope ( for all that I'd ever use PHP for and its perfect (can I say that?). If you haven't tried it, give it a go, the curve is steep but that's because you end up a lot higher than PHP would get you. Its offers a lot of stuff starting at a built in transactioal object database (no SQL, no tables, just object that persist automatically - the coolest thing your likely to find in the open source world!)

For example in Zope I could put together a simple website with News postings and suchlike in about 1 hour - and the site would cope with undoing changes to practically everything and version control so changes can be made without them being visible to general visitors (again to everything - even the HTML and images).

I'm pretty much against the idea of Java for web sites (simply becuase I'd not use C++ for presentation layers so why is JSP a good idea? Its ugly and one look at Enhydra's XMLC or Zope's new Page Templates makes it look completely crappy). Also now that there are a hundred and one ways to connect anything to Java backend stuff if necessary (XML-RPC, Soap, Corba, DCOM bridges, etc etc) there just isn't the need for Java on the presentation layer.

Anyway, try Zope - give it a month (yes, its a lot longer than it took you to learn PHP but hey, its worth it). Get there and you won't go back.

Re:ASP?? (1)

Phill Hugo (22705) | more than 13 years ago | (#275010)

ASP is a framework for page based scripting in multiple langauages (VB and JS out the box but Perl and Python from ActiveState).

Page based scripting is bad, ugly and quickly becomes unmaintable and messy.

Check out Zope, its is an object based, cross platform framework which makes PHP, ASP and JSP look decidedly old hat. At the moment it allows you to use Python and Perl (with an add on). If you haven't tried it, give it a go. I know I've said this a few times here but try it, give it some effort and next time the subject comes up, you'll be saying this ;)

Holy Shit. (1)

Zarniwoop (25791) | more than 13 years ago | (#275011)

A decent color scheme... on slashdot?!??

Have the four horsemen shown up yet?

What do I do, when it seems I relate to Judas more than You?

Stateful and Treebased Web Application Design (1)

Leghk (30302) | more than 13 years ago | (#275012)

When it comes to building webpages with interspersed dynamic content, PHP or Perl no doubt do just great (and are plenty fast); ASP too I'm sure.

However, when it comes to building a web _application_, the pictures changes drastically. The amount of work spent on the presentation layer (the HTML + That "dynamic" content), shrinks drastically. The picture doesn't revolve around what the user see's in their browser anymore, but the complex interations of the objects behind that display. To make these web applications really work effectivly, your web application needs to be able to hold and store complex structions and classes defining these objects and interactions.

PHP and Perl die here. They're not ment for large systems like that. Perl can't hold state unless it's coupled with FCGI, so it wouldn't be able to persist objects or RMI handles between requests. I think the morale of the story is, these different web architectures each have their own benefits, and but they cant' solve all your web needs.

Check out [] It's a web application framework using java servlets which tries to solve the issues assosciated with a web application, and not "dynamic content" web pages. It uses a template system, stateful operation, and a treebased design of application logic. But regardless, it may be very elegant for a web application, but it would be rediculously overkill (and thusly a poor choice) for the kinds of dynamic webpages the article was discussing.

Re:Disappointed... (1)

Kingpin (40003) | more than 13 years ago | (#275019)

JSP pages get compiled to servlets. All that's not in 'scriptlet' sections, ie. not in <% .. > just gets writted to the responseobject outputstream. The only thing JSP does is make the servlets accessible to the webdesigners, which they screw up, and you end up implementing tag libraries or using alternative template engines, like eg. Velocity from

Re:Crappy article (1)

Kingpin (40003) | more than 13 years ago | (#275020)

JSP is not slow. JSP is not Swing or some other wack Java GUI hype. JSP is probably the closest thing you'll get to a speed similar to that of serving static content. The code is compiled and gets runtime optimized - as I expect you'd only use JSP on websites thus expecting uptime, that is a very very sweet deal.

Re:close... no cigar (1)

Kingpin (40003) | more than 13 years ago | (#275022)

Even with JServ0.92 running on a 2.0.36 I have yet to see the system go down. The puppy has been running for two years, with average uptime %gt; 150 days - when it's down it's due to human failure or power outages - not Java/Linux. Solaris is rock steady as well.

Re:ASP? (1)

Chandon Seldon (43083) | more than 13 years ago | (#275023)

Most widely used dynamic content technology in the world? What world?

According to Netcraft, 62% of web servers are running Apache, and another 6% are running Netscape-Enterprise. Only 21% of web servers are running Microsoft IIS.

ASP is only common on IIS.

Chances are, based on that info, it's unlikely that ASP is the most common dynamic content Generator.

Re:JavaServlets (1)

glebfrank (58922) | more than 13 years ago | (#275026)

try GNU regexps [] , or [] ; also this review site [] has about 10 links to Java regexp implementations.

One of the beauties of Java - the ease of finding software and integrating it into your code.

Re:Crappy article (1)

ffatTony (63354) | more than 13 years ago | (#275027)

Thats strange, I've found jsp to be faster than some of the other alternatives (especially perl). Yes jsp's compile slowly the first time, but after that it should be quite quick (although that also depends upon the servlet engine; I use tomcat 3.2.1 which is by far not the fastest, but is good enough for my needs (medium sized university)).

Err.. (1)

_marshall (71584) | more than 13 years ago | (#275029)

Like Perl, Java also has a shorthand syntax to define an entire array at once. However, it lacks some of Perl's quirky and powerful array manipulation features, not to mention hashes

I'll admit perl has some pretty damn powerful array maninpulation functions (map, grep, join, etc..). But Java does have 2 standard hash types in the java.util package that are standard with every jdk... (java.util.Hashtable, java.util.HashMap) Although, I do have to admit it's alot easier to use perl's variant..


Re:Crappy article (1)

angel'o'sphere (80593) | more than 13 years ago | (#275032)

oh, I just liked to write what you wrote.

Re:Crappy article (1)

angel'o'sphere (80593) | more than 13 years ago | (#275033)

no, you don not have to admit that.
In all real world projects where I used jsp it was the fastest alternative.

Re: One has little to do with the other (1)

Drestin (82768) | more than 13 years ago | (#275034)

You make a common logical error in your assumptions. Just because netcraft claims there are more DOMAINS running under apache servers does not mean that MANY of them have no dymanic content whatsoever and that the majority of IIS survers do. My field experience shows me that most apache servers run static content for huge virtual hosts with zillions of little bitty domains while IIS typically runs only a few domains or only one but they are much larger and more likely to use dynamic content. Your typical ISP runs Apache because it's the free one that came with the free OS they are running cause they have little money. And, true, it's easier to host zillions of "10 meg limit" static page websites on apache. Businesses typically are running IIS and they have a need for dynamic content and use ASP.

Python? UCITA? (1)

fanatic (86657) | more than 13 years ago | (#275035)

So far we're not using Python in production, but it's probably just a matter of time.

Since the python license explicitly places it under the laws of the State of Virginia, and since Virginia has passed UCITA, and since UCITA lets the sellor make the license terms anything they want at any time they want, even after you've bought the product and started using it and your ONLY recourse to bad terms is to stop using it, you may want to think twice. ("Bought" may be the wrong word in this case, but the principle still applies.)

For these reasons, I'll no longer even consider use of Python (tho I'll admit I'm a perl bigot and the concept of syntactically signifcant whitespace is anathema to me). I used to think about learning Python, before I learned about the licensing.


Re:ASP? (1)

Amokscience (86909) | more than 13 years ago | (#275036)

Actually if you follow the links to the *authors* homepage you'll see that the author has no 'expert' level knowledge of ASP etc. I think it's a simpler explanation.

why did this get modded down? (1)

jon_c (100593) | more than 13 years ago | (#275045)

freakin zealots.

What about webware? (1)

jmoffitt (100733) | more than 13 years ago | (#275046)

I've been playing with Webware, which is similar to the Java sevlets + JSP model, but totally in python. You can find it at [] . So far I really like it. It has more structure that PHP, which is very nice, and it's in a language that is fun and easy to program in, Python. (I like the structure of the java stuff, but java is just hte wrong language for web application stuff, I'm just too used to the faster dev cycle).

Re:JavaServlets (1)

Glonk (103787) | more than 13 years ago | (#275047)

Just so you know, James Gosling is the inventor of Java...

Ruby (1)

_fuzz_ (111591) | more than 13 years ago | (#275049)

No one has mentioned embedded Ruby [] - probably because no one has heard about it. It's a fully object oriented scripting language somewhat like a cross between Smalltalk and Perl. There's mod_ruby [] project that's pretty far along. I'm not sure how it compares to ASP/JSP/PHP/Perl for execution, but it's sure a heck of a lot faster for development.

Re:ASP is doubleplus ungood? (1)

DrSkwid (118965) | more than 13 years ago | (#275052)

because making a mistake more often than not leads to downtime when you reboot

that alone is all most people need to know

Re:Code-in-html vs. html-in-code debate is over (1)

spullara (119312) | more than 13 years ago | (#275053)

You really have no idea what you are talking about. JSP provides exactly what you are asking for except it goes beyond PHP in that you can define new tags and filters externally to the page in order to increase the maintainability of the site and the readability of the HTML.

Comparing PERL and PHP to Java Servlets? (1)

spullara (119312) | more than 13 years ago | (#275054)

If you are going to compare technologies clearly this person has left out the best one. Java Server Pages gives you the best of all worlds. It is compiled code, it has extensible tag libraries, dynamic filters, direct Java coding if needed, is completely cross platform, and runs on many server implementations including some free as in speech/beer with an Apache license and not the viral GPL.

Re:ASP is doubleplus ungood? (1)

MrBogus (173033) | more than 13 years ago | (#275071)

Sending mail through the IIS SMTP server is like 4 lines of code using CDONTS. You can access a binary stream, but it's true that you do have to either roll your own file upload code (not especially hard) or cut-n-paste some off of MSDN.

Now if you really want to know why ASP is crap here it is: They dropped Java a supported environment for building COM components, pretty much forcing you to use either VB (which I hate) or C++ (which I don't know).

You forgot one (1)

AintTooProudToBeg (187954) | more than 13 years ago | (#275075)

What about ASP?

That's a pointless comparison. (1) (188228) | more than 13 years ago | (#275076)

PHP and JSP are scripting environments.

Perl CGI is a programming language and library.

A proper comparison would have been PHP, JSP and Perl environments such as Perl ASP, Mason or (my favorite) Embperl. For a more detailed (and wider-spread) comparison, see Web Scripting Tools - Compare and Contrast [] .

Zope. (1)

cbr372 (193706) | more than 13 years ago | (#275079)

Zope [] allows faster creation of dynamic sites and the ability to manage thousands of pages via user priveledges built into the Zope platform. ASP is ok for quick hacks (but not as good as Perl, PHP or Python), but for large sites, using raw web scripting can be time consuming. Zope allows scalability using the ZEO clustering, which basically takes a Zope Object from the Zope Object Database (built into the Zope Platform) and balances the requests over a cluster of Zope Servers using replication and synchronization...and maximum flexibility by being fully open source. Zope Methods can be written and the Zope platform can be extended using the amazing ZClasses API, one of the cleanest I've seen.

ASP?? (1)

powlette (198002) | more than 13 years ago | (#275081)

Hello, where the mention of ASP? the definitive scripting language of the Microsoft platform. Why would you use php or perl on win2k when ASP is already installed and has more components.

Re:Crappy article (1)

traused (200984) | more than 13 years ago | (#275084)

I agree. This definitly is a poor artical, giving examples but no real advice on when or why you would choose one technology over the other.

The coverage of Java is very poor, and the omission of JSPs is a big deal. Most sites combine servlets and JSPs, which is a very powerfull combination.

I also found it odd that the example extended GenericServlet, not HTTPServlet.

Apache mod_perl + (HTML::Mason || Embperl) PHP (1)

karlheg (201564) | more than 13 years ago | (#275085)

The author of that article obviously does not know about Apache mod_perl (, [] HTML::Mason ( [] , or Embperl ( [] .

Those provide a PHP or ASP like templating system with full access to the Apache API and all of full fledged Perl (and thus the CPAN modules). It's way better than PHP!

Anything that can be done in PHP could be done with either of these systems. I think it would be worth doing to port a lot of that fancy PHP HTML magic over to either HTML::Mason or Embperl. (May the better engineered solution win!)

There is, additionally, an emacs extension called "mmm-mode" (found via the HTML::Mason site) that makes psgml-html mode and cperl-mode co-exist! The perl parts are in cperl-mode, and the HTML parts are in HTML mode. It's really cool!

JavaServlets (1)

rattid (214610) | more than 13 years ago | (#275088)

I just love java as a langauge, which is the main reason I use it (java servlets and jsp). For bigger sites I'll use servlets, for something simple I can use jsp, and sometimes I'll mix them.

Re:This article sucks! (1)

Ramshackle (224022) | more than 13 years ago | (#275092)

What's the best in terms of ease of use? What about flexibility? Scalability? Performance?

Not sure what you mean by flexibility.

Scalability/Performance: If we're going to talk typical Slashdot-geek "I made a web site that generates random yo-mama jokes in PHP," then it's anybody's game. For actual high-volume sites, however, this all depends on the "container" (i.e., application server) the scripts are being run in. Big e-commerce sites will invest in a multiple machine cluster, running a bad boy like BEA WebLogic, and will out-scale/perform anything comparable on the market. Java is bar-none the most robust technology for highly scalable sites.

At this level, though, it's no longer about the fastest script compile time - it's about scalability of servers running your business logic. Again, this moves way beyond scripting languages and becomes a matter of robust application server technology.

What about CF? (1)

jimmu (227057) | more than 13 years ago | (#275094)

While the article itself isn't too bad, they seem to neglect Cold Fusion (and ASP, but I hate ASP, so you wont see me running to it's denfse). I love PHP, and use it often. its a great language. But the development time is nowhere near as fast as cold fusion. I'd take this article alot more seriosuly if they bothered to compare a few other languages.

Wow.. (1)

OblongPlatypus (233746) | more than 13 years ago | (#275096)

That's the most pointless article I've seen in a long while. They neglect to mention anything except language syntax and implementation. If that's all that mattered, any developer would choose the one which was most familiar or which came most naturally to him/her. I do see a small mention of "power" in the conclusion, which they seem to think PHP has sacrificed in favor of ease of use. They might even be right, who knows.

I wonder if Hemos even took a look at the article before he posted it. (Hmm, slow day.. Hey lookie here, an article comparing PHP and Perl and Java servlets, that should get the flame wars going!)

What about Python??? (1)

MadCow42 (243108) | more than 13 years ago | (#275101)

Python is definately a powerful tool for server-side stuff.... don't forget it!!! (or else...)


Re:PHP rocks... (1)

robert-porter (309405) | more than 13 years ago | (#275110)

I thought assembler was the fastest.

Re:ColdFusion and thinking far inside the box (1)

Heroic Salmon (323170) | more than 13 years ago | (#275116)

ColdFusion works with Unix as well as Windows. Perhaps you should have leafed through that book a little longer.

The great advantage to CF is the extent to which it enables very easy and quick database access. It is also an easy language to learn if you know HTML and SQL. Used in conjunction with Javascript, ColdFusion apps can be very powerful.

I agree that it is somewhat simplistic and you can't use it on its own unless you have very simple needs, but your comment that it only works if you're "locked into a Windows world and you don't want to do anything complex" is patently false.

Re:close... no cigar (1)

Kunta Kinte (323399) | more than 13 years ago | (#275117)

Java is a morbid joke under most *nixes, at least in my experiences. SSI is ok but again for heavy content, sites with massive interaction from the server to client, it can become cumbersome too.

I agree with your general aguement 100%, right tool for the right job, but you are entirely wrong on java.

Forget Java servlets, try JSP. JSP source is compiled by the JSP server ( eg. apache tomcat ) right before the page is viewed the first time. This makes JSP potentially very fast. I don't have benchmarks, but I'd bet a mature JSP server would kick most other scripting languages' butts in speed.

JSP also has some very cool features useful for larger projects. Taglibs allow you to make your own markup tags. This allows you as a programmer to hide the implementation details from the designers (as not to confuse them, separation of content/presentation, etc.). Check out info on taglibs at the apache tomcat web site. PS I'd love to see taglibs in PHP.

JSP allows you to store objects at different scope levels. So you can, for example, have a method execute at startup, and the result is saved in application scope for every session of your app to use.

Many of the open source web applications I see out, IMHO, there are better suited for JSP then PHP. I NOT a big fan of java and I understand the pressure to use PHP because of more talent out there (I had to make that decision recently), But I think more people should download tomcat give JSP a try. It might be the better technology for your next web project.

PS. those colors really are an improvement

Re:ASP?? (1)

alex_siufy (411363) | more than 13 years ago | (#275118)

I agree with this... Everything in the Microsoft/ASP world is commercial. The simplest of the functionalities that you'll have to add will cost you $29.95. Things like file upload require you third-party modules. Of course, there's people that are stuck with Microsoft, and people that don't mind being tied to all these third-parties. I'd much rather use PHP/Perl, where everything's open and free.

Re:What about Python??? (1)

alex_siufy (411363) | more than 13 years ago | (#275119)

Python is still too slow for anything but the most basic web services. At least that's my experience, but of course, YMMV.

Re:What about CF? (1)

alex_siufy (411363) | more than 13 years ago | (#275120)

Perhaps they're only covering open source tools/non-commercial tools.

PHP rocks... (1)

Woofcat (412210) | more than 13 years ago | (#275121)

PHP is the fastest and isn't that what really matters... I've tried many languages for my web game ( [] ) with a few thousand players and CPU usage is always 0.0... You can't do better than that...

Re:Crappy article (1)

Woofcat (412210) | more than 13 years ago | (#275122)

It's stupid to try to compare the ease of use of languages... You have to admit that jsp is s-l-o-w.

This article sucks! (1)

glenkim (412499) | more than 13 years ago | (#275123)

Can we get an Ask Slashdot on a comparison of the different dynamic scripting languages? The big players that come to mind are PHP, ASP, JSP, and CGI. What's the best in terms of ease of use? What about flexibility? Scalability? Performance?

Has this already been done? If it has been done, why is this article being posted in the first place?

Good point. (1)

Fearsome Badgers (444920) | more than 13 years ago | (#275130)

IBM simply has no vested interest in ASP.

Right: Conflict of interest. We'd be fools to trust anything IBM says on the subject. It's a very good point, and it raises serious questions about the independence of journalism in what could be called a "capitalist command economy" such as that of the USA: When vested interests control information, who can you trust?

This leaves aside the fact that IBM was Demon-of-the-Week in the hacker community fifteen years ago, but they've now been "rehabilitated", like Kruschev. Scary stuff, when you think about it.


Sorry, one more thing . . . (1)

Fearsome Badgers (444920) | more than 13 years ago | (#275131)

Why don't I see C, or C++, or Pike, or Scheme, or any of a number of other languages in here?

Thank you for mentioning Scheme, a sorely neglected gem of a language. In fact, until C and C++ support arbitrarily recursive macro substitution like Lisp does, I can't see any sense in taking them seriously as programming languages -- particularly for demanding real-world applications like CGI: C is unbeatable for writing trivial UNIX command-line utilities like ls, but it's just not scalable . . . and the fact that Perl was implemented in C should give us pause about that language as well.


ASP? (1)

Fearsome Badgers (444920) | more than 13 years ago | (#275132)


Yeah, sure, it's "politically incorrect" to speak in public about technologies that are out of favor with the Open Source Taliban, but is it so wrong just to mention the most widely used dynamic content technology in the world?

Can we have just a little open-mindedness around here? Just a small dash of fairness and honesty in our reporting, for once?


Amen! (1)

circletimessquare (444983) | more than 13 years ago | (#275133)


ColdFusion and thinking far inside the box (2)

Cardinal (311) | more than 13 years ago | (#275139)

Sure, CF has its uses, if you're locked into a Windows world and you don't want to do anything complex. However, ColdFusion is quite firmly locked into a small box of features, and the moment you want to do something outside that box, it's time to switch languages. Extending CF is a joke. Sure, you can write a custom tag. Not terribly versatile. You can even write new functions, if you know C++. No thanks.

ColdFusion is a joke for anything beyond the stereotypical database plug-in-dynamic-text-here site. Which is fine, that's exactly the market Allaire (Now Macromedia) targets CF to. The guy with the little static website describing his car repair shop and what sort of services he offers. CF to the rescue! Or something.

But let's say you want to pass around relatively complex data with CF. Well, CF arrays are limited to three dimensions, and you have to declare how many dimensions you want ahead of time. ColdFusion's idea of a list is a delimited string. As a PHP coder, I literally laughed when I read through a book of CF's support for "complex" data types. It was utterly pathetic. But, CF gets away with it because people that CF appeals to don't need that sort of power.

Me, I do. So CF can go collect dust next to the NT server I don't need either.

Re:Use what you know (2)

Erbo (384) | more than 13 years ago | (#275141)

Exactly. When starting to work on the project that has now become Venice [] , I picked Java to implement it in because that's what I know. My Perl is rusty at best, and my PHP and Python are nil. It was easier and faster to learn a few new Java class libraries than it was to try and tack on a new language. And, of course, Java has a database API (JDBC) right in its standard class libraries, which helped out immensely. (I know Perl has a standard database API, too, and I'm sure PHP and Python do as well, but, again, I don't know them.)

I'm also wondering why this article compared PHP and Perl to Java Servlets, rather than JSPs (which are a little closer in concept). In practice, Venice uses a combination of both--servlets for front-end processing, and JSPs for easy output formatting.

And, of course, the Java architecture leaves me open to employ new techniques at a later time, such as object relational mapping (using projects like Osage [] or ObjectBridge [] , both of which are similar in concept to the commercial product TopLink), embedded scripting (using an engine like Rhino or Jacl, or, yes, Jython), XML/XSLT rendering (using Xalan or something similar), and other techniques, both those that are part of J2EE and those that aren't.

But, in the end, I agree with you; use what you know, and use what you think works best. Other people may prefer something other than Java for a Web site project. Fine by me; I'm not running their projects, and they're not running mine.


Re:JavaServlets (2)

Ian Bicking (980) | more than 13 years ago | (#275142)

PHP certainly has regular expressions as part of the standard library, but they are considerably more annoying to use. You give the RE using a normal string, which makes it very difficult. "\\s+" instead of /\s+/ and so on.

Python, which similarly has REs as a set of procedures (well, classes) instead of being part of the syntax, does this much better. It's a nearly trivial addition to the language: you put a r before the string, and \'s don't get substituted, like r"\w+\s+\w+". It makes a big difference, and really easy to add to a language.

Another annoying part is that PHP doesn't document their regular expressions -- merely says "oh, read the Perl manual, or POSIX definition or whatever." That's just intensely dumb, it makes it look like PHP is just a poor copy of another language. They really ought to fix that.

Python/Webware (2)

Ian Bicking (980) | more than 13 years ago | (#275143)

Of course Java, PHP, and Perl aren't the only languages. But everyone already knew that.

I've been using Webware [] lately, which is a Python servlet engine. Very similar to the Java servlets, except without a lot of the verboseness that Java demands. For Python there's Zope [] as well, but I found it unwieldy, and not very Pythonic.

ASP gets unmaintainable pretty fast (2)

cthompso (2283) | more than 13 years ago | (#275145)

I'm more sysadmin than web developer, but the 30 or so developers at work have pretty much unanimously shunned ASP. As one woman explained, once you get past a couple of variables on a page, ASP gets very cluttered, and she (for one) felt it was harder than Perl when trying to understand someone else's code. But to be fair to ASP, it was out quite early in the game, so picking on ASP is like picking on Windows 95. At the time, it was quite good. As far as what the developers *do* rave about...the top 2 guys at work are stoked about Python. Not so much from a performance standpoint as a technical elegance standpoint. So far we're not using Python in production, but it's probably just a matter of time.

developerWorks focuses on Open Source tech (2)

jjohn (2991) | more than 13 years ago | (#275146)

As a writer for IBM's developerWorks [] , I have a good reason why Microsoft's ASP and Allaire's Cold Fusion products weren't mentioned in that article. The editors reject references to non-open source applications.

Also, ASP is, at best, a weird framework for CGI development. It supports a number of languages like ActiveState's PerlScript, but the default language is the demon-haunted VBScript. If there's one language that demonstrates ad hoc design, it's this one. Two incompatible assignment operators? Thanks!

Lest you think I'm casting aspersions wontanly, I do help maintain the ASP XML-RPC library [] . My ASP pain is real.

Hm, very narrow-minded (2)

Lazy Jones (8403) | more than 13 years ago | (#275151)

There are many more alternatives for server-side programming. If you look at all the possibilities in such a shallow way as the article does, you can always safely choose PHP - it's simple and gets the job done - or whatever language you're most proficient in. In other words, the article is 100% redundant. IMHO.

Re:PHP rocks... (2)

Skapare (16644) | more than 13 years ago | (#275156)

No, I have no intention of substantiating this claim. I don't need to because I only made the determination for myself. I tested PHP and Perl about 2 years ago, and found PHP to be slightly faster when you combined all the time factors (time to learn, time to develop, time to deploy, time to run). I didn't keep the result data because I didn't need to as I got the answer I needed and no body was offering me money to publish an article with the results. So I summarized into my own memory what those results are, and found PHP to be slightly faster overall.

Re:ASP? (2)

Skapare (16644) | more than 13 years ago | (#275161)

Then write a better article that covers ASP along with the others. And while you're at it, toss in some more languages. I'd really like to see a solid, well written, point by point comparison, from someone as experienced as yourself, about all these language choices (although I have made my own choice already). Such an article would surely find hosting space almost anywhere, but if not, contact me.

Re:Sorry, one more thing . . . (2)

Skapare (16644) | more than 13 years ago | (#275162)

I happen to be doing most of my web stuff in C (and the rest in PHP). If I needed arbitrarily recursive macro substitution, I wouldn't be using C. Guess what: I don't need that. That's not to say that someone else won't, and if they do, they should have access to good language choices.

Part of what goes into language choice is the way you think about problems and how their solutions are implemented. I happen to think strongly procedural. Don't try to justify why I should think some other way, because it won't happen ... I'm referring to my human nature. We're all different in one way or another. If you've chosen Scheme for your programming language, or for a particular project, and you have experience and information to back that up, then I'm sure the choice is the correct one, especially for you. And not everyone does, or can, tackle every kind of problem, either. Again, thats most likely part of our own styles of thinking (that we're mostly born with, or acquire in the early phases of life).

What language was Scheme implemented in? I promise not to use that against Scheme. BTW, I'm not against most languages (exceptions include Algol, COBOL, Pascal), but I do think people need to make choices with good, and unbiased, information.

Re:What about Redmond? (2)

Skapare (16644) | more than 13 years ago | (#275163)

Oh really? You say "peddles" so I assume it's not for free. So how much would it cost me to buy the BSD/IRIX/Linux/Solaris versions?

Re:I don't hire "Java Programmers", even for... (2)

Skapare (16644) | more than 13 years ago | (#275165)

I've found that C programmers who come from a heavy assembler background tend to know how to handle pointers a lot better than those for whom C was their first language. So I certainly agree with you about the "first programming language" syndrome. There being no one language that uses all technologies (intentionally), a programmer who knows only one is essentially inexperienced in computers, no matter how many years they've been doing it (for the most part ... surely there are a few exceptions, though most would have picked up another language within a few years).

CGI is not a scripting language (2)

Skapare (16644) | more than 13 years ago | (#275166)

CGI is not a scripting language. It is an environmental programming interface which many languages can use. If you want to make comparisons validly, you would compare languages to languages (e.g. ASP vs PHP vs others) and environments to environments (mod_whatever vs CGI in Apache, or Apache vs Roxen vs iPlanet vs IIS).

Re:ASP?? (2)

the eric conspiracy (20178) | more than 13 years ago | (#275171)

Why would you use php or perl on win2k when ASP

Because someday I might need to run my code on a non-Microsot platform. ASP is a dead end.

Re: One has little to do with the other (2)

the eric conspiracy (20178) | more than 13 years ago | (#275172)

Businesses typically are running IIS and they have a need for dynamic content and use ASP.

SERIOUS web businesses run Java.

Re:Python/Webware (2)

Phill Hugo (22705) | more than 13 years ago | (#275173)

Give Zope another go, since version 2.3.0 its had internal python capabilities (no more external file nastiness). I've not tried Webware but it look conceptually similar to what Zope now offers with the internal python script stuff (except Zope also offers version control and rollback, along with undoability on your objects (practically everything in zope is stored in an object database as a proper object - you can even write your own - think EJB without having to try ;).

Re:JavaServlets (2)

Noer (85363) | more than 13 years ago | (#275188)

What I find hard to believe is that all the rich string-manipulation functionality of Perl was left out. The main reason that Perl, despite its poor performance compared with PHP and Java, is so cool is the regular-expression stuff that's built in. I don't know PHP; maybe it has all that stuff, but Java has no regular expression libraries by default. Maybe some exist, but I haven't seen them. Don't underestimate the power of REs!! :)

Re:PHP rocks... (2)

e_n_d_o (150968) | more than 13 years ago | (#275191)

PHP is faster than Perl or Java

Do you have any intention of substantiating this claim? Okay, I know you're just responding to someone who was attempting to create facts using anecdotal evidence, but you're adding credence to his claim here.

If you want to make a statement which is definitely not obvious (Personally it goes against my intuition, I would think Java is the fastest, but who cares what I think), then please make some justification.

Computer scientists like Java??? (2)

Ars-Fartsica (166957) | more than 13 years ago | (#275194)

Where do you get this from? Java is shoddy implementation of its own chosen paradigm. I'm sure OO purists would more often recommend Eiffel to Java if you are speaking purely from a elegance perspective.

Code-in-html vs. html-in-code debate is over (2)

Ars-Fartsica (166957) | more than 13 years ago | (#275195)

As elegant as it may seem to create a modular architecture for creating content, the web is page-driven and this is the best way to produce dynamic content. Html-in-code is dead. Long-winded OO syntax for producing html is dead. None of the Java solutions for producing content are going to last beyond the hype phase. The popularity of PHP is simple - it works, and it is only as complex as the problem it is trying to solve.

Re:Crappy article (2)

jschrod (172610) | more than 13 years ago | (#275196)

I agree completely. The article does not explain the basic difference between these three approaches, it gives no guidelines when to use them. Just publishing examples is simply not enough.

And the problem is not only the Java examples. Just like the missing JSP pointer, I would have expected pointers to embedded Perl scripting, too. And to template-based systems, for those who want to do real work.

Re:JavaServlets (2)

ZanshinWedge (193324) | more than 13 years ago | (#275199)

Hmmm, I don't know where you get that "poor performance" thing from. In my experience Perl is at least as fast as PHP, without mod_perl even. As for regular expressions, yes, that is an excellent point. Perl is very heavily wedded to REs and it shows. Sure, to some extent you get most of the same RE functionality in PHP, but it is much more cumbersome and annoying to use. Another great advantage of Perl (IMO) is the ease of creating modules and libraries and the huge base of modules out there. If you want to do something non-routine with Perl, it's a good bet that someone has written a module to help you out. There are so many modules for Perl that it is really astonishing the level and breadth of tasks that you can take on with Perl.

Re:PHP rocks... (2)

phaze3000 (204500) | more than 13 years ago | (#275204)

As someone whose done quite a bit of both Perl and PHP for websites, here's my thoughts.

First, forget all this 'scripting language $x is faster than scripting language $y' bullshit. Speed comparisons are so incredibly task-dependant that there's no hard and fast rule at all. mod_php and mod_perl can basically be assumed to be equal in terms of speed, because the scripting language is extremely unlikely to be the limiting factor.
Where PHP wins out for my is when you're doing a site that's either simple or a complex site that relies heavily on databases. Database interaction is far easier. Where Perl wins is the thousands of modules avaliable; PHP has a hell of a lot built in a quite a few classes avaliable, but it's never likely to match Perl in this respect. IMO you're very unlikely to actually need most of these modules for doing a website, but if you do, then Perl is the way to go.

To be honest, Perl and PHP are so close in terms of speed and feature-set that I'd tend to argue that it's probably just as much a matter of picking what the developer (this means YOU!) is more comfortable with.


Of course no ASP (2)

truthsearch (249536) | more than 13 years ago | (#275210)

As someone else commented, ASP is far from the most widely used dynamic content technology. I refuse to call it a technology since it consists of one dll which exposes objects written in C++ to perform as a layer to CGI. That's all it is, an object layer to CGI. ASP is not a language, while PHP, Perl, and Java are.

ASP in 2 years will have no relation to what it is now. .NOT will make it a compile-on-first-run library. It'll first be a pseudo-compiled thing which its creator then plans to drop for something completely different. Unlike the other 3 languages discussed in the article, ASP has no support from its inventors or the community, one of which is always needed to keep it desirable for use.


close... no cigar (2)

deran9ed (300694) | more than 13 years ago | (#275211)

IMHO that article nor can any other give a definitive insight as to what someone should use to manage their site.

Example, I was using PHP before for my site, and chopped up a random image script for chick pictures, and my server load would go sky high, from loading nothing more than pictures... Now php for content was fine but the pics killed me.

Over to embedded perl. Works well I even use it for certain tasks here and there, but nothing major. Python, well its fine but not suitable for me, since my site is small. I wonder why eperl wasn't mentioned, nor was the latest entry Curl [] .

Java is a morbid joke under most *nixes, at least in my experiences. SSI is ok but again for heavy content, sites with massive interaction from the server to client, it can become cumbersome too.

Anyways enough ramblings... I do however think I have thee ultimate old school solutions for fixing my site without using any of the above!@!@... Combos of sed/for [] scripts which till this date have done me more justice maintaining my site ;)

P.S. nice colors going on here maybe that shit looking brown over yellow should be changed to this too ;)

© GBonics 101 []

webobjects (2)

jean-guy69 (445459) | more than 13 years ago | (#275215) i saw a demo of this NeXT product in 1996. this was as amazing and advanced as every NeXT product were for their time. because NeXT was bought by Apple this is now an Apple product. it could make a comeback with Macos X. it seems to have been forgotten but i'm curious to know how it evolved. apparently hey're going from Objective-C to Java.. does anyone still use this software ? did anyone evaluate this technology in the context of today ? i know it's not opensource so no "it's closed software !!" flames please

Code-in-HTML and HTML-in-code are both dead! (3)

Skapare (16644) | more than 13 years ago | (#275216)

Actually, BOTH HTML-in-code and code-in-HTML are dead. The one and true answer is separation of content vs. application, and total pluggability between the two. The ultimate solution will work with any content/information form (HTML, XML, etc) and application form (C, C++, Perl, Java, Scheme, etc). This is organization and the web still majorly lacks it.

Don't get me wrong here. I love PHP. I did LinuxHomePage.Com [] in PHP in one day as my very first PHP project. It was great and PHP was very easy to work with.

In the long run, mixing content and application is bad as systems get far more complex. One critical need will be the ability to change one or the other. By having them be fused together, it becomes more cumbersome to make those changes.

Some people are inherintly more program/application development oriented. Other people are more information/content development oriented. And still others are graphical/artistic oriented. Few people have the capability to be all that and good at all of it at the same time. So it will be necessary to divide the development (and change) functions and thus also necessary to divide up the entities these different people work with to implement and deploy the components they do.

An author of an article can't write the page layout, but she does need to write the article. She can't concern herself with what tag needs to be inerted at the top to get the properly rotated ad banner inserted. She can't concern herself with how to lay out the menus on the left side or the right side.

The very model of dividing things up at the page boundary is what is wrong. We got fooled into thinking of that with HTML itself because the tags were (at least early on) easy enough for even a non-techie document writer to work with. But today's web applications bear little resemblence to a hierarchy of documents for which HTML was designed. Our thinking needs to be along the lines of keeping separate, and dynamically merging in the appropriate way, the various components that make up what it is we are accessing. That is where we are headed and we best be prepared to deal with it, regardless of what our preferences are for things like content language or programming language.

Re:PHP rocks... (3)

Skapare (16644) | more than 13 years ago | (#275217)

PHP is faster than Perl or Java, but there are other choices out there which are even faster than PHP. I'd bet that speed is not your only reason for choosing a language to develop web applications in, but rather, you're just pointing out this reason because it is aligned with what your choice is. In reality, emotion often plays a big part in the choices we make, and we feel better when we see some non-emotional justification for our choices.

Cocoon (3)

ffatTony (63354) | more than 13 years ago | (#275218)

Apache's cocoon [] is a basically jsp done right using XML/XSLT.

Re:PHP rocks... (3)

mbadolato (105588) | more than 13 years ago | (#275219)

It's getting really annoying to keep seeing people claim "PHP is faster" without any substance to back it up. Quite being a "Me Too!" Lemming (tm) and just reciting "It's faster." Faster in what regards? And compared specifically to what?

I'll use Perl here, as it is my personal preference for language of choice. I'm using Perl in only the web context here, as that is the scope of the discussion.

As a language itself, Perl is just as fast as PHP, if not faster. As far as the process goes, yes CGI has a larger overhead and slighty longer time to initiate, but the once the processes are going the actual script execution time is no longer for a Perl script.

Plus, if someone is actually a programmer, as opposed to a kiddie that's been programming for 2 weeks and thinks they know Perl (or whatever language for that matter), they can actually program properly and create programs that execute fast enough, and effieciently enough, that the slight ding caused by the CGI overhead is negligable.

And don't forget to compare apples to apples. PHP against mod_perl is the proper comparison, not PHP vs Perl via CGI. People forget [or don't know...] that PHP is mod_php and compiled into the server (usually). PHP can be run as a CGI process, but doesn't (well, on NT it may). With mod_perl running and maintaining persistant database connections, PHP is not faster. And compare a well programmed mod_perl script to a poorly written PHP scripts and, well... you get my point.

PHP may be "easier to learn" but that's because it's Perl with training wheels. People that aren't adept enough to properly comprehend Perl, LOVE that they can go to PHP instead. But PHP is quite like Perl, but a subset of it. So claiming it's harder then PHP seems silly to me, as they are both fairly similar in terms of the language.

Bottom line, PHP is a good web language. Perl is a more robust general language. Scripts done properly will run fast and effiecent. Blanket calls of "PHP is better/faster" are unwarrented. It all depends on what is needed for the job, and using the proper tool.

Hell, uses PHP for some areas of the site. It's all about what is right for a situation.

Re:I don't hire "Java Programmers", even for... (4)

Dg93 (10261) | more than 13 years ago | (#275222)

It depends on the background of the java developer...

I've found that java developers who come from a heavy c/c++/unix background tend to know what's going on underneath the language -fairly- well, and understand how to do things like work in a debugger, work with a profiller (and interpret the results from said profiler!) - as well as handle a lot of things outside of direct development, i.e. system maintenance, development environment tuning, etc... etc... etc...

I find that developers for whom java is their first programming language, tend to be very weak all the way around. (Then again, i've found that to be true for most developers who are on their 'first programming language').

(I do want to get back into doing regular C++ programming, it's been about 2 years for me, hrm, perhaps its time to re-install that BeOS cd...)

Re:ASP? (4)

Skapare (16644) | more than 13 years ago | (#275223)

You've got to consider the source. IBM simply has no vested interest in ASP. I'm sure you can even find a lot of ASP in use within IBM. But as long as Microsoft plays corporate bully (not that IBM doesn't) and doesn't want to let someone else share in the benefits of ASP, then you can't expect someone else to sing the praises of ASP. For them to do that, they have to have some interest in it. Individuals can when their benefit is a job and income, and they know and like ASP, or any other language.

Probably the biggest reason for ASP not being there is the fact that it isn't (as) portable. IBM has vested interests in non-Microsoft operating systems for which these languages are more readily available and marketed.

Also, Java is currently heavily pushed in academia (which also tends to care less about issues important to business).

Why don't I see C, or C++, or Pike, or Scheme, or any of a number of other languages in here? There's a combination of reasons, varying from ignorance to disinterest. But probably the biggest one is because the authors do have a vested interest in showing off a subset (for which they have an interest) against a subset (for which they have no interest and see as a threat to their interests). The languages I just mentioned have little threat to their interest because few people use them (reasons vary, and not always technical). But if they did, I'd bet you would see them mentioned.

Crappy article (4)

glebfrank (58922) | more than 13 years ago | (#275224)

This is a really crappy article, at least the part that applies to Java. First of all, the correct analogue to PHP would be a JSP, not a straight servlet. With JSP, the first Java example would not be any longer than the Perl and PHP ones.

Also, that business about having to be careful not to confuse the class names is hogwash: that's what packages are for.

Use what you know (4)

Deadbolt (102078) | more than 13 years ago | (#275225)

I've done sites with perl, JSP and servlets. Experience has taught me that you're usually better served using what you're most comfortable with -- it's easier to learn new tricks with an old language. Admittedly, it is less fun, but when the boss is yellin', you need to get it out fast.

The difference, I think, is mostly that these options are reflections of certain approaches to programming. Whichever approach you feel most comfortable in, that winds up being what you use the most. Hardcore *nix will like Perl because it reminds them of long summer nights with sh and awk. Computer scientists will like Java since it's "clean" and "pretty" and "portable" <snicker>.

Use what's best for the job and leave the flamewars for Happy Hour.

Disappointed... (5)

Dg93 (10261) | more than 13 years ago | (#275226) see mention of java servlets, but NOT jsp... where i work we use a combination of jsp's and servlets (all the 'hard' logic and stuff sits in the servlets, the jsps are for page design).

I love it, it means our java developers can concentrate on logic, and our HTML designers only need to learn a small handful of JSP tags, but can concentrate on their display.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>