Slashdot Log In
PHP, Perl, Java Servlets - What's Right For You?
Posted by
Hemos
on Sat Apr 21, 2001 12:23 PM
from the learning-'em-all dept.
from the learning-'em-all dept.
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.
This discussion has been archived.
No new comments can be posted.
PHP, Perl, Java Servlets - What's Right For You?
|
Log In/Create an Account
| Top
| 254 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Code-in-HTML and HTML-in-code are both dead! (Score:3)
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 [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... (Score:3)
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 (Score:3)
Apache's cocoon [apache.org] is a basically jsp done right using XML/XSLT.
Re:PHP rocks... (Score:3)
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, perl.com uses PHP for some areas of the site. It's all about what is right for a situation.
Access to databases? (Score:3)
No one uses scripting languages to display static text. The comparisons were meaningless.
A really good article comparing any server- side technology would compare:
Re:What about Redmond? (Score:3)
Re:I don't hire "Java Programmers", even for... (Score:4)
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? (Score:4)
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 (Score:4)
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 (Score:4)
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... (Score:5)
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.