Wednesday, March 01, 2006

4 Reasons Java Will Outlive PHP (My interview with IEEE...)

I had the good fortune to be interviewed by an IEEE magazine in February to comment on the demise of Java (vs. PHP). A 45-minute interview turned into a paragraph in the article, but I thought that I might put all of my thoughts up on my blog.

Why Java won't be superceded by PHP

  1. Object-oriented principles (encapsulation) and tools (javadoc, UML) mean that over the lifetime of a software project, Java will:
    a) be easier [and therefore cheaper] to maintain.
    b) be easier to model & document.
    c) allow for easier re-use.

    It was mentioned in the article, but I'd like to re-iterate the point here:

    I have worked as a consultant for over ten years now. I am rarely going to a client site where everything is working wonderfully. For the most part, I'm getting called to a client site because of some disaster - "We need to get this release done in a month, we've got ten people working on it, and we're not going anywhere..." [sometimes I work on great projects, but often I am cleaning up messes]. I love reading peoples blogs about writing wonderful code that is commented, and unit tested, and completely documented, with requirements, design, and implementation documents. I almost never see these. I frequently walk in to a client site where generations of developers have heaped code on top of code - a favorite saying I heard was "There is never time to do it right, but always time to do it twice" - Meaning that people knew they were doing it the wrong way so that they could meet a deadline, and hoping that one day they'd actually get a chance to do it properly - but that day wasn't anytime soon.

    In most cases, documentation at a client site is negligible, but the code doesn't lie, so the best way to figure out how things work today is to go through and understand the code. Typically, for a Java project, I'll run javadoc, I'll import the code into a UML tool, and I'll track down and/or generate an ER diagram for the database schema. These give me a nice high-level view of the application, and a good starting point from which to drill down.

    Reading the changelog for PHP, I shuddered when I read the first point for the 5.1.1 release:

    Version 5.1.1

    * Disabled native date class to prevent pear::date conflict. (Ilia)

    This is pretty scary. They had to change the language -- PHP -- the core -- because an established library was already using the name "date". Yikes.

  2. While PHP has an object-oriented paradigm, the code becomes similar to Java (but missing the benefits of encapsulation with private/protected), meaning that the benefits of PHP in terms of super-fast development of pages are all thrown out the window.
    Perl [a language I write scripts in every other day] has an object-oriented framework, however I suspect that 98% of Perl code written today is not object-oriented.

  3. Java has a large and well established body of software tools that make design and analysis easier. I can programmatically check the quality of code with checkstyle. This can be integrated into my IDE. I know that over time the body of PHP tools will just grow larger and more robust, so in ten years from now, this will be a moot point.

  4. Java's native support for threads and concurrent programming. There is a huge class of computational problems that are easily solved by breaking the problem up into "workers" who each perform small actions, without needing to worry about the big picture. Workers exist in any kind of "pooled" environment - pools of database connections for example. PHP doesn't support threading, and none of the documentation discusses threading. In fact, as I tried to find documentation about the internals of PHP, I could not find if requests are processes serially or in parallel.


Don't get me wrong. It's possible to write bad Java code. It's possible to write great clean PHP code. The constructs of the languages, however, make it easier to write clean Java code. I have already started seeing PHP code getting passed from developer to developer and going from bad to worse - I can only imagine what these little projects will look like in 10 years.


Anonymous Anonymous said...

Sadly, I think you're missing the point.

How many web apps are still around from 10 years ago?

Yes, OOP principals are quite nice, but to say that Java will outlive PHP completely ignores why PHP made the jump that it did.

It seems that most Java folks are more purely abstract than realistic (just like any true academic person in any field).

Life cannot always be quantified into tiny little perfect bits that follow our ideas.

PHP is not the popular language it is because of it's attractiveness to Computer Science grads.

If it were, it would be stuck in the same place Java is.

PHP is popular for the very reasons you're saying it's going to die: that most people are not computer scientists, most people don't want to be, and most people really dislike computer science.

Can and should those principles go into development in any language? Yes.
But the beauty of PHP is that you don't have to.

Also, the barrier to entry is incredibly lower than Java, allowing more people discover a love for programming that they may never have found otherwise.

November 01, 2006 8:19 PM  
Anonymous Anonymous said...

PHP is going to die because Ruby on Rails is here.

November 01, 2006 8:51 PM  
Anonymous Anonymous said...

Ruby on Rails? Jeez... Give me a break. Ruby has it's place, as does PHP. Neither will kill either one off.

November 01, 2006 10:43 PM  
Anonymous Anonymous said...

First off, I'm not a Ruby programmer :)

From the studies and blogs I've read, it's Java programmers who are switching to Ruby. Ruby was designed AND developed to be all the things that Java was meant/hoped to be.

Here are a couple blog entries for the open minded:

BTW, if you search Google for "Ruby vs Java", you'll see that there are 11,000 results. So clearly, it's on a LOT of peoples minds.

In time, who knows. Ruby could end up as screwed up as Java and then there will be another kid to takes it place. I'm crossing my fingers it's not a language from Billy aka MS.

November 02, 2006 12:28 AM  
Anonymous Anonymous said...

I'm not the same as anonymous above, but I heard that most Java guys who play with Rails, still use both Java and Rails/Ruby.

On the other hand, the PHP coders who moved to Rails, tend to leave PHP completely because they need an easy-to-use scripting language in place of PHP. Rails is more than that obviously, but it covers their need that they used to get from PHP.

Sure PHP won't die, after all, COBOL is still ALIVEEEE.
But PHP's crowd will shrink by large and most of them will move to Rails.

Java crowd only moves to Rails to cover non-enterprisey apps (lots of them obviously), but they won't just abandon Java.

November 02, 2006 3:51 AM  
Anonymous Anonymous said...

Why you don´t write the article 1000 Reasons Ruby Will Outlive Java?
it´s more realistic.

November 03, 2006 7:58 AM  
Anonymous Anonymous said...

I dislike these my-language-is-better-than-yours discussions--they're rather pointless. Every tool has it's place. The comments here seem to have strayed--now we're comparing a Ruby framework to Java and PHP? Apples and oranges, people! As a PHPer, I don't feel threatened in the least by Rails, Ruby or Java. Program and be happy!

November 03, 2006 11:51 AM  
Anonymous Anonymous said...

First off, I'm not really a language evangelist. Every established language out there has its beauties and uglinesses.

Comparing Java and PHP is like comparing a bread knife to a swiss army knife. PHP is mainly focused on web development, whereas Java is quite multi purpose. How many times have you needed a multithreading mechanism in typical web development situations? On the other hand, you'll want multithreading in many other areas of development (sometimes closely related to web development), that's why they are of great use in Java. And as for not having database connection pools in PHP, has that ever been a problem for you when working with PHP? I didn't think so.

As for documenting - there's phpdoc ( for PHP, just as there is javadoc for Java.

While PHP has an object-oriented paradigm, the code becomes similar to Java (but missing the benefits of encapsulation with private/protected), meaning that the benefits of PHP in terms of super-fast development of pages are all thrown out the window.
There are a few things I don't understand in this paragraph. First, as of PHP 5, PHP _does_ have access modifiers such as public/private/protected (no default/package access as you have in Java, because PHP has no concept of packages/namespaces). Furthermore, I don't really understand what the relation of that is to "super-fast development of pages". You can still create clean OO code without having access modifiers, as long as you approach the state of your objects with getters/setters. It's just not _ensured_ that your object state won't be modified by bypassing the objects' behaviour. What I see as a bigger disadvantage of PHP, is simply the lack of packages/namespaces. It's rather tedious to write large applications and maintain backward compatibility in PHP because of exactly that (your example of the Date class issue is directly related to that).

Why don't you see well documented code, along with unit tests and such? I think there are various reasons for that. First, there is the time thing. Product Management often halfs development time in order to get the deadline, and there's simply no time for, or even sense in writing precise requirements upfront. Methodologies such as eXtreme Programming were introduced to deal with change during a project. As for unit tests, you're right, they're often not there. This has two possible reasons, from my experience.
1) the developers know they have to write unit tests in order to create a consistent test suite, but there's usually no time (they don't write tests upfront, like in Test Driven Development)
2) the developers are not trained to use Test Driven Development; it's a skill all developers on the team will have to acquire. Some developers just "won't get it"
TDD is not language dependent, but it is certainly _culture_ dependent. The Java culture (yes, you could call it "more academic") is more likely to have acquired such disciplines, or at least be aware of such disciplines.

As for Perl, I think most code isn't written in an object oriented way because of 2 reasons
1) Writing OO code in Perl is not very straight forward (it doesn't have a "class" keyword for example, Perl 6 is going to change that)
2) The majority of scripts written in Perl solves one specific problem (database backups, text/XML crunching, that kind of stuff), and maybe having OO in there seems like overkill.

I have already started seeing PHP code getting passed from developer to developer and going from bad to worse - I can only imagine what these little projects will look like in 10 years.

If you expect your application to live for 10 years, yes. Same goes for Java code.

November 04, 2006 7:34 AM  
Anonymous Anonymous said...

I disagree. I think that php will be fine. It will live as long as anything else on the web. joe sanders

December 07, 2006 6:39 PM  
Anonymous Anonymous said...

It pains me to say this (honestly it really does!) but your reason 1 is kind of messed up.

I'm in a similar circumstance - i've been working as a senior engineer and consultant for 10 years (+ a couple more) and point 1 (OOP principals) is the very reason why i've made a good living.

You're completely right about OOP being self-documenting, however if we judge things purely from that perspective then surely Python is king (most projects are well laid out in OOP with functional elements, methods/functions are always a reasonable length because indentation as a language feature forces you to write tight pieces of code).

The thing that's made me most money (and given me the least satisfaction) is that OOP (especially Java and it's starting to become prevalent in .NET coding) programmers aversion to databases (except as containers for information) and the use of multiple abstraction layers (including Object Persistence mechanisms).

This obscures what the machine is really doing and thus performance issues start to come to the fore.

With PHP projects i've found that they're often more efficient with resources (as there's less abstraction - so people know they're calling a DB and running some SQL) and also when you find something stupid going on it's easier to fix.

In contrast I've had a hell of time tuning up Hibernate (do we really want to write HQL) and SDO projects (and then rewrite parts of other tiers to do something critical faster?).

I see it this way - Java's got a great language without all the awful PHPisms and the PHP folks don't seem to be fixing that up for PHP6 (see my moaning blog posts as i don't want to cut and paste into this comment! - Grrr argghhhh! PHP consistency for example). It also is getting more difficult to start dealing with (especially for small projects see Java: (IMHO) Why independent application builders are shying away from it).

PHP and Java both have their place, lets face it neither is going anywhere any time soon. Rails I personally think is a bit of a flash in the pan (it uses the ActiveRecord pattern which is an anti-pattern IMHO in some cases as people hack around to do things that they can't do easily).

February 24, 2008 1:41 PM  

Post a Comment

<< Home