How do you separate the well-trained software developer from the ignoramus with a flashy set of credentials from the dotcom era? Here's one little discriminator: the latter will actually judge a programming language's utility by how "cool" or how "hip" it is, rather than based on how well-suited it is for a given task. Java for kernel-level code? Hey, it makes sense because it's easier to hire a Java coder than a C programmer. PHP for a massively complicated web application? Of course, J2EE is simply too "software engineeringish" for such a task. Then you have the cheerleaders like Business Week:

Here's a look at a few of the seismic shifts underway. For one, many of the now-large companies built from the ground up to operate on the Internet don't make Java a major piece of their tech strategy. Those include Google (GOOG) and Yahoo! (YHOO). The new generation of lighter-weight programming tools, including AJAX and PHP, are immensely popular with the Web 2.0 startups, including the likes of Friendster, Flickr, and Facebook. The new tools allow programmers with less training to build applications rapidly.

AJAX is not a tool, it's a methodology, but don't let that stop you from comparing an apple to a catalytic converter. Believe it or not, but if you are good at JavaScript, a prerequisite for using AJAX in the first place, you can write AJAX applications more easily using simple JSP scripts than in PHP. Here's a tale of two scripts, one written in Java using JSP and Apache DBTaglibs (yes, I know it's deprecated) and the other written using PHP:

Here's the Java/JSP version:

<%@ page contentType="text/html; charset=iso-8859-1" language="java" import="java.sql.*" errorPage="" %><br>
<%@ page import="java.io.*" %><br>
<%@ page import="java.util.*" %><br>
<%@ taglib uri="http://jakarta.apache.org/taglibs/dbtags" prefix="sql" %><br>

<%@ include file="include/config-include.jsp" %>
<%
     String owner = request.getParameter("owner");
     String plString = request.getParameter("plID");
%>
<response>
     <% if (owner != null && plString != null) { %>
     <sql:statement id="stmt" conn="conn1">
          <sql:query>SELECT media_library.id, song, album, artist FROM <%= owner %>_playlist_<%= plString %>, media_library WHERE <%= owner %>_playlist_<%= plString %>.id = media_library.id ORDER by artist ASC, album ASC, song ASC</sql:query>
          <sql:resultSet id="rs">
               <song id="<sql:getColumn position="1"/>" title="<sql:getColumn position="2"/>" album="<sql:getColumn position="3"/>" artist="<sql:getColumn position="4"/>"/>
          </sql:resultSet>
     </sql:statement>
     <% } else { %>
          <error>You must supply an owner and a playlist id</error>
     <% } %>
</response>
<sql:closeConnection conn="conn1"/>

And now for the PHP counterpart:

<?php
     header("Content-type: text/xmlnnn");
     include("includes/config.php") or die("I forgot the config script, George!");
     $link = mysql_connect($host, $username, $password);
     mysql_select_db($db, $link);
    
     $owner = $HTTP_GET_VARS["owner"];
     $plID = $HTTP_GET_VARS["plID"];

     $getSQL = "SELECT * FROM media_library m INNER JOIN users u WHERE m.owner = u.username ORDER BY song ASC";
     $results = mysql_query($getSQL);
     if ($results != false)
     {
          print "n";
          while ( ($row = mysql_fetch_assoc($results)) != false)
               print "";
          print "n";
          mysql_free_result($results);
     }
     mysql_close($link);
?>

For the unitiated, those are two scripts that support an AJAX process' backend processing. Now, which of those looks easier to read, the one written as a JSP or the one written in PHP? Don't even get me started on how much uglier PHP is than Java from both a syntactic point of view and from a design perspective. Java is a beautiful and elegant language compared to PHP. One need only compare the two languages' string processing functions/methods to get a very basic understanding of what I mean.

I have nothing against PHP, I really don't, I just wish that people would realize that it is not the well-designed language that it is made out to be. It's also time for a little bit of honesty here about J2EE for website development: it's really not an expensive and difficult thing to do. Personally, I would much rather have to debug a JSP than a PHP script given how much better the error messages are in Tomcat than in Apache/PHP. With free Java application servers like Tomcat and Geronimo, one can easily write inexpensive J2EE-based websites, and JDBC has very mature drivers for MySQL so it's not like the world of cheap databases is in any respects off limits to Java developers. In fact, one of the many reasons why Java is so much better for this sort of development is the fact that if you are using properly-designed SQL, it is much easier to switch a Java program from one database to another than it is for PHP. In many cases you simply change the JDBC driver that you are using, update the connection string and there you have it, a fresh new database server. PHP's database connectivity features are all database-specific so you have to actually change code that accesses the database rather than simply changing a driver which manages all of the server-specific features. Only now are they finally getting serious about this major deficiency with their creation of PDOs.

.NET is a credible threat to Java in that it is very feature rich, robust and quite versatile for all manners of software development. However, given that MySQL is only now gaining features that its bigger competitors have had for a very long time and that PHP is more of ad hoc kludge than a coherent language, it does not represent a real threat at this point. The moment that the PHP team decides to get serious about dropping all of the cruft that has come to be euphemisically called a function/object library is the moment that we Java, and .NET, developers will have any reason to really worry. PHP has a very valid place for prototyping big applications and implementing smaller applications, but in very large applications it still is too immature to be a good consideration unless you have some outstanding developers who could do well with any language.

Anyone who decides to stop using a language based on its age is a fool. Has anyone stopped to complain about Microsoft using large amounts of C and C++ in Windows, considering the fact that C is well over twice Java's age? C has been in practical use for over thirty years now, Java was released to the public a little over ten years ago. By Business Week standards, C is to PHP what caveman grunts are to modern English, but for some mysterious reason no one is using these new fangled languages to develop low-level operating system components. Hell, virtually no one is using them for even the configuration utilities at this point!

Of course, the reason why is very simple. The companies that actually know what they are doing understand that a good developer should be conservative with his or her use of languages. A developer that chooses languages the way that a teeny bopper chooses pop idols is a liability, not an asset, to the company that hired them. Maybe if corporate America would be a little bit more hesitant to buy the latest snake oil promise of One Language To Rule Them All And In The Server Room, Bind Them^tm, there would be fewer problems with security and quality than there are today. If you keep jumping from trend to trend, you cannot build up the kind of maturity that is required to make the software actually work as needed. It's a simple fact of life that is quite often lost on those who know just enough about technology to be dangerous, and have enough ego to think that they know more than the engineers they hired to write their systems.