Why Do Cool Kids Chose PHP to Build Websites?

PHP Developer's Journal

Subscribe to PHP Developer's Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get PHP Developer's Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

PHP Authors: Hovhannes Avoyan, AppDynamics Blog, Trevor Parsons, Andreas Grabner, Harald Zeitlhofer

Related Topics: Java EE Journal, Java Developer Magazine, PHP Developer's Journal

J2EE Journal: Article

Java vs Dynamic Languages: Sun's James Gosling "Didn't Get The Memo," Says Blogger Ryan Tomayko

"I completely forgot about James Gosling..."

I’ve been blissfully neglecting to blog for months with the assumption that a large part of our goal was completed. After watching good people like Martin LaMonica and Jon Udell balance out the mainstream tech press with coverage of lessish tools and languages, and having seen forward looking companies like RedMonk inject themselves into the traditional analyst racket with smart, honest, and unignorable critique, and having seen herds of Java luminaries migrate to simpler, more agile tools and languages, and after hearing Bill Gates say that less code was the only metric, and having watched David, Bill, Ian, Adrian, Phillip, Aristotle, Harry, Mark, Mark, Chad, Curt, James and many other extremely talented programmers dismantle all the common hollow arguments for superfluous complexity and replace them with simple methodologies and working code, after all that I just figured there wasn’t much to do around here.

But I completely forgot about James Gosling:

"There have been a number of language[s] coming up lately," noted James Gosling today at Sun’s World Wide Education & Research Conference in New York City when asked if Java was in any kind of danger from the newcomers. "PHP and Ruby are perfectly fine systems," he continued, "but they are scripting languages and get their power through specialization: they just generate web pages. But none of them attempt any serious breadth in the application domain and they both have really serious scaling and performance problems."

We’ll get back to that in a second.

I believe that a majority of people in IT now consider dynamic languages like Perl, Ruby, Python, and PHP to be very much capable of sitting at the table with Java and .NET for a wide range of common technical problems. Similarly, straight-forward systems like REST, Microformats, and Atom are generally considered legitimate alternatives to the vendor/analyst/press peddled technologies like WS-* for a wide range of integration issues. In other words, I could walk into most shops during a technology evaluation and put these technologies on the table as legitimate considerations without being too worried about being laughed out of the room. This is not to claim superiority for a given task, just that the competitive playing field is beginning to level off.

This was not the case last year at this time, so what happened? Something must have changed. None of these technologies underwent huge feature or stability increases in the past year. I’m unaware of any breakthrough in scaling these systems past what they’re already capable of. There have been some improvements in running dynamic languages on the mainstream VMs, which many predicted would lead to quick acceptance, but that’s not it either. So what changed?

Minds changed. Respectful debate, honesty, passion, and working systems created an environment that not even the most die-hard enterprise architect could ignore, no matter how buried in Java design patterns. Those who placed technical excellence and pragmaticism above religious attachment and vendor cronyism were easily convinced of the benefits that broadening their definition of acceptable technologies could bring.

The people who are still unconvinced are those that just don’t care or are too lazy to spend a small amount of time researching and validating the arguments, which brings us back nicely to James Gosling’s recent statements.

On The Current Quantity of Language

“There have been a number of language[s]

This part is notable because it’s actually true. There have, in fact, been some number of languages. While I stand steadfastly by James’ analysis of the current quantity of language, we will quickly diverge in opinion from here.

A quick note to aspiring Java pundits: play close attention to the next few statements. While none of them have any basis in reality, they have proven sufficient in creating fear and uncertainty in the minds of those who are evaluating these technologies.

On “Scripting Languages”

“PHP and Ruby are perfectly fine systems,” he continued, “but they are scripting languages

James pulled this directly out of “Effective Java Advocacy Beans”, section 6.8.3 “Dealing with questions on dynamic languages”:

First, call anything not statically compiled a “scripting language”. Attempt to insinuate that all languages without an explicit compilation step are not to be taken seriously and that they are all equivalently shitty. Best results are achieved when you provide no further explanation of the pros and cons of static and dynamic compilation and/or typing and instead allow the reader to simply assume that there are a wealth of benefits and very few, if any, disadvantages to static compilation. While the benefits of dynamic languages–first realized millions of years ago in LISP and Smalltalk–are well understood in academia, IT managers and Sun certified developers are perfectly accepting of our static = professional / dynamic = amateurish labeling scheme.

This technique is also known to result in dynamic language advocates going absolute bat-shit crazy and making complete fools of themselves. There have been no fewer than three head explosions recorded as a result of this technique.

Also, avoid the term “dynamic language” at all cost. It’s important that the reader not be exposed to the concepts separating scripting languages like bash, MS-DOS batch, and perl-in-the-eighties from general purpose dynamic languages like Ruby, Python, Smalltalk, and Perl present day.

We’ve tried our best to clear up any ambiguity related to the term “scripting language” in the past:

On “They Just Generate Web Pages”

and get their power through specialization: they just generate web pages.

Gosling shows his ignorance regarding the current feature set provided by dynamic languages and what people are using them for. A cursory glance over rubyforge.org’s project tree reveals that the number of projects that “just generate web pages” are really quite small: 151 of 1,342 total projects are registered under Internet::WWW/HTTP::Dynamic Content and many of those projects are related to using the web (HTTP/URIs) as a platform for integration more than they are for “generating web pages”. I expect Perl and Python break down even wider.

Update: Seo Sanghyeon provides a list of popular Python related applications that have nothing to do with generating web content.

I’d also like to note that exposing resource representations via HTTP/URLs has been moving into areas other than “generating web pages”. This was the plan when HTTP was originally designed but has only recently begun to really catch on. Specialization and enhanced capabilities related to generating and serving hyper-media over HTTP are and will continue to increase in value. The web server is becoming a key piece of integration infrastructure. What James refers to as “generating web pages” is now a general purpose technique for exposing resources to anything outside of the application process.

On “breadth of application domain”

But none of them attempt any serious breadth in the application domain

It’s hard to determine what kind of breadth is missing when you consider the capabilities provided by modern dynamic language environments, the platforms they run on, and the extensions and bridges that allow them to use damn near any other program or library available. James uses the example of “interplanetary navigation”, which is a really good example except that it isn’t; most of us aren’t working at NASA and those of us who are working at NASA are doing things like trying to get the payroll and accounting systems working together or building simple productivity applications. Gosling seems bent on meeting the needs of the 20% while leaving the 80% with a platform that’s losing bids to dynamic/agile shops.

“That’s the kind of power I do not envy”.

Lastly, Peter Yared (former Sun hacker) and the rest of the folks over at ActiveGrid should also be interested to learn that no one is attempting to widen the viability of dynamic languages in the “application domain”.

On Scaling and Performance

and they both have really serious scaling and performance problems.

It is simply not possible for me to add anything to the massive set of material addressing this topic.



Why people are upset

There have been multiple responses to Gosling’s statements ranging in sentiment from outrage to amusement:

All we’re asking is that you stop spreading misinformation about the current state of dynamic languages to the press, analysts, and your customers. This does not require you to champion or otherwise support these technologies - just stop lying about them. One year ago, this type of behavior could be attributed to a lack of documentation and discussion on these issues, today it’s impossible to attribute to anything but malice.

More Stories By Ryan Tomayko

Ryan Tomayko is a programmer specializing in web architecture, dynamic
languages, and F/OSS. Former enterprise architect and Java consultant,
he is currently dedicated to applying the advantages of LAMP
infrastructure and web architecture to problems facing US
healthcare. Ryan is Co-Founder, Proserve Health Informatics, a provider
of on-demand healthcare applications for self-funded organizations. He's
also the creator of lesscode.org, a group weblog crusading for the
simplification of tools and processes in IT.
You can find him at http://del.icio.us/rss/rtomayko and http://lesscode.org/.

Comments (16)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.