Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

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

Posted by Hemos 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? More

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

Comments Filter:
  • 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.
  • Well, I can use Perl, PHP, or Java for free, or I can drop several thousand dollars [allaire.com] on a fractionally powerful template engine. I think I'll pass. CF on Unix is a terrible mismatch of environments, imnsho.

    I've seen CF tie into JavaScript a lot, yeah. However, this brings with it the requirement that JavaScript be present. While I realize JavaScript being present is a safe assumption for most users, I don't consider it a safe assumption in web app development. Even if it is there, it's very difficult to do anything meaningful in JS without writing it once for each browser you want to support.

    I've also seen whole application suites written in CF (A first mistake) that use _only_ JavaScript for data validation (A second mistake). As a result, if JavaScript is off, or if it isn't written correctly for each browser, the app either simply breaks, or data gets send to the queries (Or in this case, sprocs) unvalidated, creating messy DB error messages.

    CF does have one last gasp at a future, though. They're working on converting the language into a set of JSP custom tags, which would free it of the poorly designed CF server, and tie it to a language that does have a solid future (Regardless of if we like it or not, Java is indeed not going anywhere for quite awhile).
  • 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.

  • What the hell is wrong with the PHP interpreter?

    It is not as widely-distributed on the systems I work on as PHP. And unless I'm mistaken, #!/usr/bin/php is a fairly recent thing; before the generic interpreter was available you had to use phpcgi or some damn thing.

  • No offense, but you seem to have a fairly loose understanding of PHP at best.

    This may be; I haven't seriously looked at the language in over a year now.

    If your programming is good, modular, and loosely-connected, your script will not care whether it's running on the web or on the command line.

    Okay; I've got Perl installed on all systems I work on. PHP is (was) installed only where it made real sense: on the webservers. Why would I write Perl modules to do some fairly generic work and then rewrite them in PHP to take advantage of them for the webservers? Or why would I write a PHP class which did something great only to find out later that I can use it on another system without PHP and have to rewrite it in Perl? I simply settled on one scripting language which I feel is more superior.

    And I'm not sure where you got the idea that perl doesn't use an interpreter...

    Actually I didn't say that. As I wrote to another person who replied, #!/usr/bin/php is a fairly new development IIRC. Before that you had to use phpcgi or some damn thing which I'd written off as a hack to make PHP more useful outside of webspace. If it indeed has gotten a generic interpreter that's great. In my eyes I've crossed that bridge. It's too little, too late. The languages are too similar to me to warrant "perfecting" both.

    Don't get me wrong, I like perl as much as the next guy...but this holy war assumed-condescension is silly.

    Agreed. PHP makes some things easy that Perl doesn't either. And the general syntax is cleaner IMO as well (I come from a C background). But this entire article seemed to be the breeding grounds for a holy war and it was late, so I thought I'd fan the flames a bit. :-)

    The DBI argument gets more specious by the day, too. Check out PEAR. Or PHPLib. Or Metabase.

    I can create a connection, run commands and get results generically with DBI. Yes there are vendor-specific extensions, but the base calls are the same. A year ago PHP did not have this. There were pg_* calls for Postgres, mysql_* calls for MySQL, msql_* calls for mSQL, etc. Yes there were generic ODBC drivers but hardly anyone uses them if they're working on a high(er) performance system because vendor ODBC drivers are notoriously slow. DBI fixed that.

    There are lots of valid reasons one could give to prefer perl over PHP, or PHP over perl, or emacs over vi, or milkshakes over spaghetti...but what you've written are not among them.

    I don't see how my post didn't give any valid reasons. I stated my own reasons and here I've backed them up further.

    As I'd said, I started out as a PHP guy. Loved it. Then I started wondering why I was learning two languages that were very similar, did pretty much the same jobs but one was more targetted to web apps. So after some careful consideration and a few posts to various Ask Slashdot's I made my choice. And I really don't miss PHP, which indicates to me that it was a good choice to settle on one scripting language, and (IMO) the more versatile and powerful one. That's not meant as a flame against PHP; it's just a direct observation on my part. I've not been able to prove that PHP is significantly easier, faster or different to warrant learning it.

  • Perl. Why learn two languages when one does 99.9% of it without breaking a sweat? Seriously. PHP has umpteen number of DB interfaces. Perl has DBI. No matter what you talk to it's all DBI and it's fast. Regexps? OO? Parsing? PHP and Perl both have them but why write your modules once in PHP and then have to redo them again in Perl just because you want to use it outside of the web?

    Yeah I know about the PHP interpreter but that's just plain old hokey. And to think I was once a really avid PHP guy. If all you're doing is web, PHP is really sweet. But really when you think of it you have other things to do too... parsing logs, reformatting, search and replace... things that get done on a daily basis and are beyond the scope of "just the web". Write the module once, write it good and use it in all situations!

  • Actually, most hosting companies I've dealt with use PHP as a CGI, not mod_php, so they must have the /usr/bin/php someplace, but they may not make it available to you that way (they probably don't give you shell access anyway).

    I thought PHP, like Perl, got most of its speed when run as mod_php (like mod_perl) -- I thought a lot of the overhead was loading up the interpreter for every script access? Have I really missed something here?

    Actually, it's not terribly new, afaik. I was using it a couple years ago at least, so I know it's not 'new'. I'm not sure if it was available like that in PHP2, but from mid versions of 3 on I can attest that it's been like that.

    Hmmm.. I remember reading about having to do some hoop-jumping to get it to run as CGI. I could be mistaken though. I appreciate your response and maybe in the future I'll take another look at PHP.

  • So its pretty clear. PERL users like leatherman tools, PHP users prefer traditional single purpose tools. Or maybe not.

    Definately maybe not. :-)

    I hate leatherman tools except as a "where is my... oh fuck it, I'll use my leatherman" type of scenario. Proper pliers, proper screwdrivers and proper nailclippers are essential to me. Hell I can't even stand the dozen-in-one screwdriver sets half the time!

    To me, PHP is tailored to the web and is breaking into the generic system interpeter market. Perl owns the generic system interpreter market but has uses in the web world. In my opinion Perl has a better chance at the web market than PHP does in the system interpreter market, but as I said, it's my opinion. I really haven't seen much of a speed difference between mod_php and mod_perl, I happen to love Perl's OO setup (10000000x better than C++) and although it causes me headaches from time to time, Perl's regexp abilities are far more flexible than PHPs.

  • The brunt of my objection is against the propagation of the notions that a) PHP doesn't make sense other than on the web, and b) that PHP has no database abstraction layer. Of course, the fact that it works fine as a general tool language and has database abstraction doesn't mean that you should use it if you'd rather use something else, since other tools will do it all fine too.

    Alright. At the time I was looking at PHP, it didn't make sense for anything but the web. After looking at some of my older systems and seeing that PHP was indeed available as a generic interpreter I do have to apologize; it was ignorance rather than solid fact that led me to the conclusion that PHP is just for the web.

    Regarding the abstraction of database access -- I had never heard of nor was there mention of Metabase or Pear::db in the online documentation regarding database interaction when I was learning about PHP. This has changed and this is a good change in my opinion. It will bring more people to use PHP.

    In the end, I do feel rather foolish with my previous "sentence by sentence" comment. I was (still am) in the tub and the tone of your comment set me off. I don't ever think I'll look at PHP for my own use but these changes will make it a better language for others to decide to use.

  • Re:ASP? (Score:1)

    by Bake ( 2609 )
    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?? (Score:1)

    by Bake ( 2609 )
    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.
  • 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.
  • 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.
  • I didn't say I was avoiding PHP, I said that I picked something that I already knew...in part because Venice was being written for an online community that was within a month of finding itself homeless, and which now, thanks to my efforts as well as the efforts of the entire community, has a new home. (Details to follow.) So I had a good reason to stick to what I knew.

    Besides, I think it helped get me my new job :-).

    Eric
    --

  • Exactly. When starting to work on the project that has now become Venice [sourceforge.net], 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 [sourceforge.net] or ObjectBridge [sourceforge.net], 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.

    Eric
    --

  • 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.

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

    I've been using Webware [sourceforge.net] 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 [zope.org] as well, but I found it unwieldy, and not very Pythonic.

  • Then it's irresponsible of you to be spreading myths about something you admittedly don't understand fully.

    Okay, I'll call you on that one. Where am I spreading any myths? I gave my opinion and several reasons behind why I have that opinion. But let's take my original post on a point per point basis and you show me where I'm spreading myths. I don't even think you read the second comment after the first sentence.

    • Why learn two languages when one does 99.9% of it without breaking a sweat?
    Why indeed? I don't see this as spreading myths; In fact I consider this a fact.
    • PHP has umpteen number of DB interfaces.
    And it still does. Perhaps there are third-party classes which attempt to intgrate them (I even remember doing half of one myself) but no singular DB interface had become the main one when I was playing with PHP. This is a myth?
    • Perl has DBI. No matter what you talk to it's all DBI and it's fast.
    I hope you don't consider this a myth.
    • Yeah I know about the PHP interpreter but that's just plain old hokey.
    This you might construe as a myth but when I played with PHP it was hokey.
    • Regexps? OO? Parsing? PHP and Perl both have them
    More truth.
    • But really when you think of it you have other things to do too... parsing logs, reformatting, search and replace... things that get done on a daily basis and are beyond the scope of "just the web". Write the module once, write it good and use it in all situations!
    I stand by that statement. From what I have read now PHP has a "regular" invocation to do CGI. However it is still not as common nor (IMO) as powerful as Perl. Myths? Disinformation? Hardly. Opinion? Definately.

    So now... Show me where I'm spreading myths. If you can't, then please retract your statemnt that I'm spreading myths. After all, anything else would be irresponsible.

  • 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.

  • As a writer for IBM's developerWorks [ibm.com], 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 [sourceforge.net]. My ASP pain is real.

  • Platform independance is necessary to prevent vendor lock in. Also, if I find that a solaris box can do better DB I/O than any NT box, and that a Linux box running khttpd is fastest for static pages, and FreeBSD fastest for general dynamic content, then I can freely mix the three together to get literally an 'optimal' solution.

    --

  • I'm sure OO purists would more often recommend Eiffel

    And that's exactly the point - purists. I have come up against a number of these fascinating creatures in my time. Their ideology is so fixed you just give up and ignore them. One project I was lucky not to be on, one such purist wanted to send radar feeds over RMI "because that is the way it must be done in an OO world". Let's try tracking 1000 different objects at 20hz and shuffle that over the ideologically pure way. This project ended up being 2 years late (from an original 18month timespan) and went on to use C++ and raw sockets as the communication mechanism.

    You wonder why languages like C++ and Java are winning the mindshare of the developers over "pure" languages like Eiffel and Smalltalk? Stupid comments like this, and the people that make them are the bane of a commercial software developer's life. I have yet to see one actually produce a real, working system (and I've run across probably a couple of dozen or more in my code-development life). The reason - complete inflexibility. There is only one "true" way and all others are punishable (and yes, I've seen them try that trick with management).

    So, use the right tool for the job. That tool is the one that gets things up and running and maintainable in the fastest amount of time.

  • Of course that's irrelevant if you are enrolled in a decent CS program. At least where I go, they're teaching me about large-scale application design, specifcation, data abstraction and modelling, OOP, functional programming, etc. To quote one of my professors, "A language is something you learn over the weekend. If that's not the case, then you're in the wrong field." That about sums it up. The only real skill you need to make the leap from Java to C++ is a firm grasp on memory managment, which can be gleaned by hewing to the following maxim: for every 'new', there must be a 'delete'. Simple as that :) Everything else is just details, or is not worth learning. Like operator overloading. Avoid that like the plague.

    --
  • I'm opposed to a failed attempt to create such a language but making it have a screwy data model (typing is too strong).

    The typing is too strong? I pulled out my copy of the Revised Report on Algol 60 and looked again. There are three types in Algol 60 - Boolean, Integer and Real, and arrays on those. Since it automatically converts between Real and Integer as neccessary, and doesn't check the type of an array you pass in to a function, I don't know how you know the language and can claim the typing is too strong.

    In any case, do you oppose all old languages for their misfeatures? It's not like any one really uses Algol anymore . . .

    Language choice depends on a lot of issues, and there are several strong choices

    Like what?

    It was the right choice then, although not today.

    Proof by assertion. Very convincing.

    I know of financial stuff done in many other languages, so I think that's phoney, anyway.

    Understand Turing machines? Of course you emulate Binary Coded Decimal in other languages! The legal issue is that the interest on $103,355,883,888.97 must be accurate to one cent. That's longer than a C long on 32 bit machines and doubles would introduce illegal rounding. In COBOL you define a BCD type with two digits to the right of the decimal point, and 18 to the left, and go on with your life.

  • 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.
  • Your example is alright but you're ignoring the fact that to the machine Java is handling a string almost exactly the same way PHP is. The main difference is to the programmer. Simple percentages aren't really an indicator of language performance. Also JSP != servlet. A servlet is a fully compiled program you run with CGI where JSP is an HTML document containing java code that is executed when the page is loaded. JSP should be compared against ASP languages rather than Perl and PHP.
  • Actually there is a good reason to write servlets. Not everything requested of your webserver is going to be HTML. In the case of a client making a GET request to the server for some XML file or database object you would much rather have a servlet processing the request than a JSP page. You could use the same beans with the servlet as you used for the JSP if you wanted. Servlets are also good when you need to take data from somewhere like a database and turn it into some other form of data like a graph. Using a JSP page would make the HTTP transaction far too long and your connection will probably time out. Using a servlet to do the hard work and then send it to the client over a separate connection is more friendly for the client who'd like to see at least SOMETHING load onto the page.
  • That would work for php also, except you change the html to php instead of jsp ;-)

    I started my own comparison of various programming languages at my own personal web site. I go over perl, php, asp/VB (some), java, javascript, C and C++. I compare a few different things. Mainly I discuss the basic similarities / differences of these languages like the for loops, while loops, if statements, functions, types, and then I get into how each has its own definition of an 'object'. Yes C sort of has objects they are structure. Not a 'real' object like C++ or Java but it is similar.

    The point is that anyone can learn any language once they have learned one language. The big differences in the languages are the 1) syntax, 2) garbage clean up (or lack of) and 3) the ease of programming. Lets face it pointers are not easy and objects can be difficult as well.

    Personally I think what language you pick should be more dependant on what you feel comfortable with. JSP has the drawback that it is not part of apache, so if you are running apache each JSP page needs to have a call made to tomcat (or whatever you use) which means you have to have a socket call outside of apache. Perl / CGI meanse you have a new process forked for each page (why the hell did he not say mod_perl instead). Neither php nor perl have string 'types' but you can 'force' types if need be.

    In case you want to see my review go here -> http://www.mindspring.com/~joeja/programming_myth. html .

    I'd love constructive critism on this so I can improve the comparison and correct any mistakes that I may have made.

    I don't want a lot, I just want it all!
    Flame away, I have a hose!

  • Java leaves your idea of PHP dead in the water for one big reason - with Java you write your application classes seperately from your HTML generation classes/JSPs/whatever. Then you use the application classes in both the web site and any number of different apps, without having to write them as 'web services' or whatever. If you wrote your application classes as data abstractions of your app data, using the Observer/Observable pattern, you now have shared data objects as well as shared code.

  • 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.

  • Thanks. These are good links with good info. Now I can see better what I am up against with with I am developing. While I don't expect to be as grand as they are, it's good to be able to see other points of view on those other web tools.

    BTW, for others doing cut & paste on the URLs, there is a space in the middle of each one that needs to be deleted first.

  • I use long long in C. It handles up to $92,233,720,368,547,758.07. Even Bill Gates would dream of having that much money.

  • Algol did not let me tweak any of the types.

    You're still using 32 bit integers?

  • I guess people just quit using it. Maybe it exited.

  • 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.

  • 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.

  • 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?

  • vanza [mailto] wrote:

    Velocity. [apache.org]

    Great. Now how do I plug modules of other languages in there? Or more to the point, why was this designed to be specific to just one language? My prior post [slashdot.org] did say "and total pluggability".

  • 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. 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).

  • Did I say it had anything to do with Java?

  • I guess we're reading this from different contexts. I wish I had the time to go through the whole thing with a point by point explanation. But I don't. Maybe another day.

  • I'll let Woofcat go into the speed differences more, since he said it first. But I do find PHP to run faster than Perl, and from what I read, it therefore must be faster than Java.

    If you're doing DB backed stuff, then Java is probably not going to be your bottleneck unless you improperly misbalance the machines. I do agree with you that speed of development is secondary (although try convincing most project managers or CTOs/CEOs). And yes, separating logic/process/application from presentation/content is the way to go for anything short of little one day PHP knockoffs like I did with http://linuxhomepage.com/ [linuxhomepage.com]. I'm currently building up my own toolkit to do that in the language I now do my web stuff in (which is faster than PHP).

  • Interesting. So you're opposed to powerful non-GOTO control structrues and source code that doesn't depend on counting columns (Fortran IV) or lots of parentheses (LISP)? Because ALGOL happens to be the pioneer of those concepts.

    No. I'm opposed to a failed attempt to create such a language but making it have a screwy data model (typing is too strong). If your assumption were true, then I'd be opposed to C, C++, Java, and many others (even though some have goto, they provide enough to avoid using it).

    So what's your suggested replacement? There's reasons COBOL has stayed where it is; Binary-Coded Decimal (the only legal way to handle financial matters) is one.

    COBOL has stayed around because so much legacy stuff is built in and around it, and there's still a sufficient supply of programmers to continue working it, that managers in the companies that use it aren't going to jump ship just yet to change things until they have to.

    I'll make no one specific recommendation for a "replacement" since that would be inappropriate. Language choice depends on a lot of issues, and there are several strong choices today as compared to when COBOL was created for the lack of any others, and the lack of knowledge about computers in general. It was the right choice then, although not today. Remember Grace Hopper [wic.org]?

    As for the legal issue, I've never heard of such a thing. In fact I know of financial stuff done in many other languages, so I think that's phoney, anyway.

  • 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.

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

    SERIOUS web businesses run Java.

  • 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 ;).
  • It would have been more apropos to use a JSP, not a servlet in this comparison. It it typically considered bad practive to embed HTML code in a Java Servlet. Servlet are used for business logic and communicating with backend systems. When it's time to render the presentation, use a JSP:

    <%
    String title = "My First Script";
    String greeting = "Welcome to my first script.";
    %>
    <html>
    <head>
    <title><%= title %></title>
    </head>
    <body>
    <h1><%= title %></h1>
    <p><%= greeting %></p>
    </body>
    </html>
  • coulnd't have said it better my self.
  • Stored procedures aren't always appropriate. Worse yet they tie to a database, forever locking you a database vendor, worse even then that Transact sql SUCKS as a programming language. If you put all you logic in transact SQL (I would rather shoot myself first) then you can never ever switch from SQL server. Good for MS sucks for the poor business owner.

    The ampersands are just the tip of the iceberg. VB sucks ass as a language. It's obvious you have never done string manipulation with perl or php. Once you learn that then you'll see what I mean.

  • I'd be interested in your views of enhydra VS velocity. Did you try enhydra and reject it?
  • The components are all out of process activeX calls. Every control called adds lots of overhead to the ASP page and ASP is nothing more then a framework for calling activeX components.

    You can call activeX objects from PHP or perl too and you can use perl in ASP.
    In the context of this article I'd say ASP has no place. It's not a language, it's not platfrom independent, and it's on it's way out. ASP will be replaced by .NET pretty soon why bother reviewing it?
  • Are you claiming CDONTS is easier to use then the php mail command?

    Here is the best reason NOT to use ASP.

    SQL = "Select " & fieldlist & " from " & tablename & " where " & fieldname & " = " & fieldvalue & " ORDER by " & sortfield & ";"

    in PHP
    $sql= "select $fieldlist
    from $tablename
    where $fieldname = $fieldvalue
    order by $sortfield"

    Which would you rather maintain?

    After the 10 thousandth ampersand I want to just smash my monitor to pieces. In my job I have switch from php or perl to VB very frequently and I just want to stick needles in my eye whenever I am forced to use VB. Yes I am forced to use VB in my asp pages because
    1) MS says it's prefered and the management believes them.
    2) The idiots that manage the web site don't know anything else.

    I could give you a hundred other examples but really that one reason is enough.
  • Learning MTS and COM+ is about a hundred times harder then learnin PHP. All your MTS objects must be written in a object oriented way and must be very carefully written to maintain transactional integrity. In fact if you need to do anything even slightly complex it's best written in C++. Is your ASP developer proficient in writing MTS/COM+ objects in C++?

    You can pick up PHP in a couple of days. Using ASP + MTS + COM+ requires a developer with at least two years under his belt.

    You can not compare the two technologies. You should compare MTS to J2EE that would be a closer technology.
  • If you are going to have to learn a new language why not learn perl or php. They are both easier to pick up then C++ or Delphi. As a bonus you won't have to use two languages to build your web site.
  • I have used CF. I used it until 4.5 came out. With 4.5 they raised their prices again. I said to myself. "It looks like they are going to raise their prices with every version what features does it offer that PHP does not which would compell me to upgrade". I thought about it quite a bit and came to the conclusion that it would be better to switch.
  • 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

    In that case you haven't any experience worth talking about. If you run PERL scripts as CGIs without mod_perl, then you have the full overhead of starting up the PERL interpreter for each service. This is much the same as writing CGI in Java and starting up a new JVM for each service - yes, you can do it on a very lightly loaded site, but it isn't good engineering.

    No CGI scripts - no matter what language they're written in - can compete with in-process technologies, whether it be Servlets (my personal choice), PHP, or mod_perl. CGI is just inherently inefficient, and the larger the binary you have to start each time, the more inefficient it is. PERL is a pretty big binary.

  • Does anyone knows a free PHP-compatible object database ? I'm fed up to death with SQL transactions which are bulky and inefficient when interfacing with Web pages. A persistent-transactionnal object database is my wet dream...
  • "I still see "Internal Server Error" more often with Perl than with PHP (maybe I'm not using CGI::Carp 'fatalsToBrowser' correctly? The Perl programs I work with call subroutines spread out over many files - does CGI::Carp 'fatalsToBrowser' need to be in each file?)"

    Nope, just the main file. Here's what I use. It might be different from you.

    #!/usr/local/bin/perl -w

    use CGI;
    use DBI;
    use CGI::Carp qw{fatalsToBrowser};

    do "SubsCommon1.pl"; #has some subs
    do "CGIStuff.pl"; #and mo' subs

    I don't get Server Error messages that often at all.

  • I would have to concur that this article really did not hit its mark. The four sentence conclusion was a waste of digital storage space.
    All this article did was cloud the decision making process for neophites even more.

    Where the article should (or could) have gone is into detail on when to choose the various technologies. Why and when would I choose PHP over PERL over JAVA? What are the performance trade offs for using each? What language features does is support?

    Paying a little more attention to meat rather than trying to get something published would have benefited us all a lot more.

    RD

  • Bravo... At my company we've encountered this exact issue.. There are various elements in our organization that have differing skills. Some artistic, some executive, and others coding guru's.

    Since Perl was a local favorite, we did something that I assume is similar to "Velocity" referenced elsewhere. Basically separate engines produce HTML (either through flat pages, or through cached perl-scripts (similar to FastCGI or Apache::Registry)), and then a template merger will take important parts of the various pages and produce the final HTML. The approach is generic enough to allow side-content to be applied (kind of like a static layered HTML).

    In this, a template is specified for a directory (via putting a file and possibly munging a config), then throwing cgi's or htm's all over the place.. Exec's can use Front Page, or artists can use Photoshop, and us guru's blow in complex perl code. The best part is that it's transparent... Nobody need learn anything new.

    Well, unfortunately that only seems to work efficiently with perl.. So basically you'd have to reinvent the wheel for each language, since there would be a different problem set.. Java wouldn't be too bad (a la Velocity, I'm sure), PHP would probably be a b*tch, and so on.

    One slight addition was going to be the general piping of HTML to the merging engine. Thus non-Perl CGI's could just be exec'd and passed through. I'm sure through post-filtering in Apache you could accomplish this just fine with any other language.

    The problem mostly arises in how you generate the HTML around the actual data you're trying to display (i.e. the table or pretty printed dynamic forms). Creative uses of templates could work. But mostly we resort to language and package specific methods: CGI.pm, embperl macro's, PHP thingies, etc. Don't really have an answer for that..

    Another idea could be the micro-translation of data-types into HTML widgets... The recreation of the document (a la XML descriptions) with an associated style sheet could be ideal. Especially if this is all passed to the browser for final construction.

    Other issues come from sidebars and dynamic menus.. The graphics designer will make all the reall cool button graphics, but how do they implement the switching logic without doing any code. I'm a big fan of static (non context sensative) menus, but on bigger sites that's just not practical. The only solutions I've come across require definate communication between developer and artist.

    I'd be more than happy to learn what other's have found.

    -Michael
  • 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!! :)
  • What can Perl do that Java can't? Nothing at all; they both let you approximate a Turing machine, so they can accomplish exactly the same things. BASIC , Lisp, and Fortran are also equally powerful in this regard (heck, I love Lisp)

    My point is that regular expressions are very natural and easy in Perl (assuming you understand regular expressions conceptually, and find them easy on that level). In Java, to my knowledge, they aren't. According to some other peoples' posts, there are some Java libs for REs, but they're written in Java, so aren't as fast as the Perl and PHP RE functions that are written in C and compiled to machine-specific code.

    You don't truly NEED regular expressions in a language, because you can parse them yourself using your own stack. In this way, you could do regular expressions in Fortran (and hell, they'd be damn fast if you coded them well). At issue is convenience features in a given language, and how well documented they are, and how streamlined their use is. REs in Perl work great. I can't speak for PHP, because I don't know the language. Heck, as much as I despise the syntax of ASP (BASIC), I'd be surprised if you can't do REs fairly easily in that Microsoftish language (please, someone - surprise me!!!)
  • Cocoon [apache.org] is much better at this. JSP's only invert content and presentation. JSP tags do separate them in someways but cocoon is much more powerfull.
  • 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.
  • COBOLScript [cobolscript.com]!

    And who says you can't teach old dogs (or mainframe jockeys) new tricks?

  • 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.

    Come on folks, you can pick up PHP in a day. You can read the entire online documentation guide in four hours.

    If you're going to hold this party line of avoiding new tools, just keep it in mind next time you crack on a forty-something who insists on doing the job in COBOL.

  • 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.
  • 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.

  • 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.

  • 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.

    This is the most elegant explanation of ASP that I have ever seen. Thank you!


  • This post is completely ignorant. I've written some extremely complex apps in CF that go well outside your so called box. Just because it's an elegant and simple application server that any idiot can develop crap code on doesn't mean that it's not extremely powerful for professionals as well.

    And what is this "Windows world" you speak of? CF runs on Linux, HPUX, Solaris, and Windows officially. FreeBSD and others unofficially.

    CF is by no means the best for all jobs (what is?), but I think people on Slashdot focus too much on it's simplicity and it's early version performance issues and don't give it the credit that it deserves.
  • 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.
  • It may not be distributed on as many systems currently, but that may change. Actually, most hosting companies I've dealt with use PHP as a CGI, not mod_php, so they must have the /usr/bin/php someplace, but they may not make it available to you that way (they probably don't give you shell access anyway).

    If you're bouncing from system to system, yeah, Perl will probably be more of a constant right now. But my guess is that many admins that have PHP on their box would either have it as a CGI, or give you access to it anyway - it's actually easier to make PHP safe in a multiuser environment that way than mod_php, imo.

    Actually, it's not terribly new, afaik. I was using it a couple years ago at least, so I know it's not 'new'. I'm not sure if it was available like that in PHP2, but from mid versions of 3 on I can attest that it's been like that.
    R
  • Show me please. I did see one reference to an article that had a VBScript example of this, but can't find it. Every other article I see shows how to do it with a third party componenet. Perhaps this is different in ASP3/W2k, but I've not heard definitively.

    If your example is the VBScript code, two strikes against it. One, it's not terribly standard. I worked at a web integrator that was 95% MS and only two people there even KNEW about the VBScript method, and both wouldn't use it, not let us use it, because of stability and security questions (didn't have time to test and audit it, and if a component broke from someone else we could at least call them up and bitch about it). The second strike is just that it leaves MS shops without 'support' (see above). I realize not all shops were/are like where I was, but the attitude seems prevalent enough from other MS people I've talked to ("come on, it's just a few bucks", etc.)



  • PEAR is becoming a good alternative to DBI - not there yet, but...

    What the hell is wrong with the PHP interpreter?

    #!/usr/bin/perl is OK but
    #!/usr/bin/php is 'hokey' ? I don't have to redo my PHP modules in Perl to use them 'outside of the web' as you say. I simply include() them and use them. Doesn't seem a whole lot different from Perl, from where I'm sitting.

  • The way to create the best application possible is to take a langauge you know well, and use it. Period. Suddenly going and studying "Language X" because you think it might be best for a client while doing work for said client likely will create a lot of headaches and long hours for everyone involved. If you find out in the end that it wasn't the langauge you should have used for the project, you're screwed.

    Optimize the code you know how to optimize, and use (properly coded) external tools to handle requests you can't handle well on your own. Breaking up large programs into a series of smaller ones is acceptable; look at KDE. One tool that I am surprised does not get more publicity is FastCGI [fastcgi.com]. It is the only langauge and web server independant (more or less) way I have found to speed up CGI scripts. Perl scripts coded for mod_perl more or less port easily to FastCGI, with most of the performance boost. And here's the real kicker; unlike mod_perl or PHP, which take up huge chunks of memory, mod_fastcgi for Apache does not. A small handler simply hands off control to one or more copies of your program running on the side, possibly even on another server!

    I've used FastCGI extensively on systems that otherwise could not serve the load they had to handle. While it is not used as much as mod_perl or PHP (it no longer is in the core Apache distribution because it evolved too rapidly), I strongly encourage people to consider it a choice.

  • 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.

    --

  • There is no mention of JSP, the current standard for generating HTML with Java Servlets. Just this makes the article loose all its credability. People use Java Servlets without JSP mainly to generate non HTML content, such as images or sound.
    Sindri Traustason
    "It takes two to lie, one to lie and one to listen"
  • I was thinking about that too. Very kuro5hin, this scheme is.
  • What about ASP and ColdFusion? Gee, why didn't I see them here? And what about the homebrew server-side code that the Shack [shacknews.com] uses? That site's uptime and responsiveness is greater than that of Slashdot, which is primarily due to the server running BSD rather than Linux. And that web server doesn't even have a RAID cage (the proof is in the "0 comments" lines beside some of the mid-March articles, due to a missed backup).
  • Dude, just from your exmaple, I can tell that you're not a a professional. Only kids put SQL right in their ASP. Have you ever heard of... gasp... a "stored procedure"? That's where SQL statements go. Or, how about a "COM object". You can put your SQL statements in there too. And are you serious? The ampersand is too much for you? You can't concatenate a string? That's a pretty silly reason for not using ASP.

  • Dude, I was responding to the post about there not being any community support for ASP. My point is that there's HUGE community support for ASP. Who was talking about whether or not it's a language? And, on top of that ASP IS platform independent. Ever heard of Chilisoft ASP. And why is platform independence such a big idea, anyway? Most people don't suddenly decide to change server platforms in the middle of a project. That's generally decided a long time before the project is started, so platform independence is usually a moot point.

  • 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.

    ---

  • 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 [curl.com].

    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 [antioffline.com] 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 [antioffline.com]

  • I agree. What I was really looking for was a comparison of the performance of the languages (how fast is byte-code vs. the interpreted languages), how much overhead do the runtimes take up. And particularly, how do the packages available to the different languages compare, especially for database access.

    While I know the answers to a couple of these questions, I would have liked to see a really thorough side-by-side comparison (at least of performance.) Anyone know of anything like this?

  • The article also incorrectly states that there are no hashes in Java. This is also quite incorrect. The java.util.Hashtable class is one example of how to do this:

    import java.util.Hashtable;
    Hashtable numbers = new Hashtable();
    numbers.put("one", new Integer(1));
    numbers.put("two", new Integer(2));
    numbers.put("three", new Integer(3));
    System.out.println( numbers.get("two") );

    The above code will, of course, output "2". The Hashtable supports having ANY object used as a key, not just a String. As well, Java has a Properties class which pretty much has the same functionality, but can be loaded and saved from a file.

    Also, those who are interested in developing web applications should have a look at Velocity [apache.org]. It's much cleaner than JSP in that it more closely enforces the separation between code and design. I'm currently using Velocity in a web application project I'm working on and it's working out wonderfully!
  • I'd be interested in your views of enhydra VS velocity. Did you try enhydra and reject it?

    I have looked at Enhydra. It looks quite good, and I was thinking that we may use it for another part of the application (the 'application' in question is actually 3 web applications linked together with a common interface).

    We will likely add Enhydra to our configuration in the coming months. For the present time, however, Velocity offered a good solution for us because it was simple to install, performed surprisingly well and we were able to make templates straight out of HTML editors. I generally code HTML by hand, but my time is better spent doing the back-end code, so often I have someone else do the design work.

    I also liked the way that Velocity 'merges' data (in a Context object, which is basically a hash) with the template. Because of the way it loads templates, I found it to be a piece of cake to be able to load different templates by language (we support French), and by customer (some of our customers want customized looks and/or functionality).

    We've had some bad experiences in the past with ASP. The bad part was that while things worked reasonably well, the developers were too often tempted to put code directly into the ASP page instead of the COM objects which were called. The production server, only shut down very infrequently, was not making it easy to update COM objects (bloody things got stuck in memory often and we couldn't reload them without rebooting the server sometimes). Hence, the developers became accustomed to putting code in the ASP part of the app, since it could be updated on the fly. After a while, we end up with hundreds of ASP pages with all sorts of code in there, and you can't easily read them to modify the presentation if you have to.

    Enter JSP. While I like the technology and its abilities, I don't appreciate that it's just as easy to make the same mistakes. JSP allows you to embed Java code directly in them, which normally shouldn't be a problem, but maintaining an application over some years, you're bound to find situations where somebody is going to stick code in there and lots of it. Pretty soon, your JSP page is not as simple as it was when you started. What we needed was a way to enforce the separation of code and presentation, and an easy way to customize the look for our customers and to be able to handle multiple languages.

    I found Velocity fit these needs well. I was able to write a small, customized template loader which searched for templates appropriate to the customer and language (if it can't find it, it loads the generic English one). Velocity does not allow you to embed Java code in the template. There are a few basic ifs and loops available, but generally you're forced to keep the code in the classes, and just send the template the resulting data to display.

    For the data/functionality part, I've also implemented similar ideas for the classes. At runtime I load classes specific to the logged-on customer and try to run those to process forms (they just extend the generic form handler for that function and override a method or two). If they don't exist, then naturally the generic handler class processes the next action.

    The main requirement for me was maximum flexibility with minimal effort. Velocity fit these needs well. I'm sure that Enhydra will fit our future needs too, so no, I am not rejecting it as a viable platform.
  • http://www.webobjects.com 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! (Score:3)

    by Skapare ( 16644 ) on Saturday April 21, 2001 @11:52AM (#275216) Homepage

    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)

    by Skapare ( 16644 ) on Saturday April 21, 2001 @09:57AM (#275217) Homepage

    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)

    by ffatTony ( 63354 ) on Saturday April 21, 2001 @09:43AM (#275218)

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

  • Re:PHP rocks... (Score:3)

    by mbadolato ( 105588 ) on Saturday April 21, 2001 @09:59AM (#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, 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)

    by chipuni ( 156625 ) on Saturday April 21, 2001 @06:26PM (#275220) Homepage
    The article was a disappointment to me.

    No one uses scripting languages to display static text. The comparisons were meaningless.

    A really good article comparing any server- side technology would compare:

    • How the languages access local files and databases
    • Whether the languages can access remote files and databases
    • How the languages access other websites
    • How the languages access code written in other languages
    • The relative speed that each language runs
    • The relative speed that programmers generate code with each language

    ...and other topics.

  • Re:What about Redmond? (Score:3)

    by Prophet of Doom ( 250947 ) on Sunday April 29, 2001 @10:00PM (#275221)
    Calm down.

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

    by Dg93 ( 10261 ) on Saturday April 21, 2001 @10:00AM (#275222) Homepage
    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? (Score:4)

    by Skapare ( 16644 ) on Saturday April 21, 2001 @09:48AM (#275223) Homepage

    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)

    by glebfrank ( 58922 ) on Saturday April 21, 2001 @09:32AM (#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 (Score:4)

    by Deadbolt ( 102078 ) on Saturday April 21, 2001 @09:43AM (#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... (Score:5)

    by Dg93 ( 10261 ) on Saturday April 21, 2001 @09:34AM (#275226) Homepage
    ...to 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.

Slashdot Top Deals

If you want to put yourself on the map, publish your own map.

Close