|
Java vs Dynamic Languages: Sun's James Gosling "Didn't Get The Memo,"
|
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:
Wikipedia: Scripting Language describes the difference between specialized scripting languages and general purpose dynamic languages.
The State of the Scripting Universe Van Rossum, Thomas, Hobbs, Conway, Pall weigh in on this misconception and others.
Web Dominated by J2EE? is a rant on an article spreading the same misinformation.
Arrogance, ignorance, and a blinding Sun is David Heinemeier Hanson correcting the same misinformation somewhere else.
RADlab, scripting and scale, a blog entry by Gosling saying the exact same stuff and a comment thread full of people correcting Gosling’s dated evaluation of dynamic languages.
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.
|
|
|
