PHP or Java? by Harry Fuecks commits a discussion in separation. It completely ignores the cumulative effect a world of kludges brings on the programming experience as a whole. He represents the arch-PHP apologist down to the last "but interfaces are possible, if you just..." excuse.
The impressive amount of work arounds for object-oriented constructs in PHP is just that. Work arounds. In all their non-standard, patch-requiring shades of grey. They're not the equivilent to Java's consistent and thorough solution to OOP.
The point is that they don't have to be. It's okay that PHP isn't Java. It's good that PHP isn't Java. It's different tools for different jobs and different types of people. I would never think to recommend Java for web developers just starting out. It's a jungle of standards, open source projects, patterns, and abstractions. That doesn't make Java better. Just different.
An "arch-PHP apologist" - great term! I'm going to duck it though - I wasn't attempting to apologise for PHP at all - the article was intended only to be a response to this: http://www.tek271.com/articles/JavaOrPhp.html - where we find statements like;
Feature: Polymorphism
PHP: Not supported. Methods cannot be overridden.
Java: Supported.
Winner: Java.
That simply isn't true. My article was about corrective therapy.
Many pure Java developers examine PHP and ask "Is this Java?". When they discover that PHP doesn't have an "Abstract" keyword, for example, they write it off. In providing answers to those sort of questions, it frequently looks like PHP has to do everything by work around. Therefore, PHP is doomed... or so the theory goes.
Mysteriously though, it's common that PHP applications exhibit the strange behaviour of "actually working". Somehow, throughout this "kludge" PHP manages to defy the laws of code. Projects like eZ publish (http://developer.ez.no/doc/view/index) and extremePHP (http://www.extremephp.org/xpl/docs/) even dare to write complete class libraries in PHP! How is this possible? Because PHP is a language geared to build web based solutions. It's not for desktop apps. Not for immense back office systems. Just for the web. For reasons, some of which could be a PHD paper, on the web, PHP's programming experience is "king".
As an aside, one interesting was this comment to the launch of www.phppatterns.com (http://radio.weblogs.com/0103807/2002/11/27.html#a969)
'I ran this by a Java programmer I know that I have drawn into the PHP world and her comment was "I'd have never even thought to try patterns in PHP" '
Anyway, if you still think I'm apologisng, try this one: http://www.phppatterns.com/index.php/article/articleview/9
Nice gallery you have, by the way. Do I sense an "abstract" PHP dB class in there somewhere?
Educating Java programmers and others in the possibilities of PHP is a worthwhile exercise. Claiming it's the holy hammer that'll conquer any web-related nail is not. I felt your article had at least equal parts of the above.
"Actually working" is a very broad definition. Sure, I could build a cathedral out of materials from Home Depot, and claim it was "working", but it wouldn't really be an interesting claim. An application has many important features besides "running". Like maintainability, scalability, and reliability.
Look, I'm not out to slam PHP. I'm currently implementing a variety of patterns, abstractions, and libraries in it. It's surely not as bad as many Java programmers would let you believe. But neither is it an all purpose "king" of web development.
Actually, I'd rather compare it to a springer. It can move across the board fast, but not always in a pattern you can use.
Specifically, PHP is sorely lacking in mature and widely applied MVC frameworks, persistence abstractions, IDEs, testing suites, and enterprise solutions.
Java offers an incredible array of choices in all of those areas. Struts, WebWorks, and Turbine for MVC. Castor, Hibernate, and JDO for persistence. IDEA, Eclipse, and JBuilder for IDEs. Cactus, jUnit, and MockObjects for testing. EJBs and application servers for enterprise.
All of those things are "possible" in PHP. I'm personally working on light-weight alternatives in MVC, persistence, and testing. But I doubt that PHP is the best choice for the job (if you have one, often you don't).
What I find more ridiculous in the http://www.tek271.com/articles/JavaOrPhp.html article is this section:
Feature - Variable declaration
PHP - The variable is declared when it is created. Its type is implied from the assigned value. A variable can change its type if it is assigned a new value.
Java - Variables must be declared with a specific data type before usage.
Winner - Java. It is convenient for a small program not to require variable declarations, but for large software, this is harmful. Variables changing their types based on their value are very dangerous in large programs.
This is a common misconception that I'm beginning to think is simply bad education. The notion is that strongly typed systems are somehow 'safer' in the large. It's silly. Strongly typed languages mainly save you from themselves.
As anyone who has worked with PHP (or Perl, Ruby, or Python) for any length of time knows, common sense programming techniques that work for _all_ languages can keep your application reliable and maintainable. Plus, writing in a scripting language faster, and the total code size is smaller. Smaller is better, less bugs and less to maintain.
I've asked some 'strong typing' folks why the think it's a important and at the end of the day the best they can come up with is "it is better because my teacher told me so." I developed for fourteen years in C and C++ and I can't give any reasonable answer for the advantages of strong typing either.
Were I to ask for strong checking in a computer language it would be semantic checking. Something that type checking in no way does.
BTW, the author of the 'comparison' article claimed no experience outside of the strongly typed trinity (C, C++ and Java). Along the lines of the "actually working" comment, the comparison aritcle 'author' never mentioned that any of his Java apps actually "shipped".
Regarding persistence abstractions for PHP, you may want to check Metastorage.
Metastorage is a persistence API generator. This means that it generates classes that map objects so they can be stored and retrieved from persistence containers like relational databases.
Since the code is completely generated by a compiler, it is all optimized to avoid the overhead of computing static data at runtime like SQL queries that are indeed constant.
Metastorage uses a XML format named CPML (Component Persistence Markup Language) to define the classes to be generated with developer defined variables, collections, functions, validation rules.
Metastorage uses MetaL compiler engine to generate optimized PHP code. Since it is based on MetaL, it could also generate Java but ironically Java lacks of standard database API that provides key features like database independent primary key generation (auto-incremented sequences) that in the case of the generated PHP code are provide by Metabase. When Metabase API gets ported to Java, there will be a Metastorage version capable of generating Java code too. Same for other languages besides PHP.
As a nice bonus, Metastorage generates automatically UML class diagrams from the XML component definition.
Metastorage is a persistence API generator. This means that it generates classes that map objects so they can be stored and retrieved from persistence containers like relational databases.
This is in response to the comments by Jack Herrington on strong typing. First, we should be clear of the difference between strong typing and static typing. Strong typing implies that the type system is never violated in a run and attempts to do so crash the code. Static checking is when the compiler returns syntax errors for improper typing. C and C++ and not strongly typed, but what typing they do is statically checked. The fact that you can cast anything to a void * and back to any other type in these languages is evidence of that. Java is strongly typed and does significant static type checking.
Jack states that type checking is not semantics, but it obviously is. The types of expressions imply something about their use. To view this a different way, types are not part of BNF language syntax descriptions. They are part of the static semantics.
As for why both strong typing and static typing are good, they allow you to have a proof of the correctness of at least some part of the semantics of your code. It's not a full proof, but at the very least, static type checking provides proof that some fraction of the intent is correct. Without it you lack proof that any part of the program is correct. Strong dynamic type checking doesn't give you proof, but it does turn logic errors into runtime errors. Similarly, static checking turns runtime or logic errors into syntax errors. We all know what types of errors are easiest to find and fix.
For a good comparison of the extremes in this look at Scheme and SML. Scheme is completely dynamic in it's typing. There is no static type checking so a "compile" phase reports almost no errors unless you have unbalanced parentheses. SML on the other hand is one of the few languages that statically checks the type of everything. It is also functional and allows you to do all the things Scheme can. However, the strong and static typing turns a large number of errors into syntax errors. Jack might even like SML (or its relative O'Caml) because the user rarely declares the types of variables or functions. Instead the language infers it.
