About the Author

Chris Shiflett

Hi, I’m Chris, a web craftsman making things like Mapalong & Brooklyn Beta with my friends at Analog.

Gosling Didn't Get the Memo

I just read a smart critique of James Gosling's recent interview. It's worth a read.

For those who don't have the time or inclination to read the interview, it's basically the creator of Java trying to explain why PHP, Perl, Python, and Ruby do not pose a serious threat. One of his first statements is, "PHP and Ruby are perfectly fine systems, but they are scripting languages." In the critique I just mentioned, Ryan Tomayko dismantles this argument with a style reminiscent of The Daily Show:

James pulled this directly out of "Effective Java Advocacy Beans," section 6.8.3 "Dealing with questions on dynamic languages."

Ryan provides an excerpt:

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.

The entire response is both entertaining and informative.

Note: Jeff Moore also provides some good commentary on the interview.

About this post

Gosling Didn't Get the Memo was posted on Mon, 13 Mar 2006 at 13:29:40 GMT. Follow me on Twitter.

5 comments

1.Ivo Jansch said:

I think the 'scripting language' is not so much about 'to compile or not to compile', but the major thing here is 'persistence'.

In a java environment, be it a Swing application or servlets or beans, you have native persistence. Objects persist over requests, and this has its own set of disadvantages.

The major drawback of PHP is in its very nature that for each request, a script is reexecuted. Ofcourse we have sessions, of course we can serialize stuff, but those are basically workarounds for the lack of object persistency. (not to mention that persisting objects in sessions only works per user).

PHP5 has better OO support than PHP4, but in my opinion, true OO is only useful when the objects persist after a page completes.

Mon, 13 Mar 2006 at 17:28:40 GMT Link

2.Ivo Jansch said:

Sorry, I meant to say 'advantages and disadvantages' where I said 'disadvantages'

Mon, 13 Mar 2006 at 17:29:41 GMT Link

3.Peter Pistorius said:

Good comments, didn't know that about Java ...

Mon, 13 Mar 2006 at 18:16:21 GMT Link

4.timvw said:

I still have to see a good formal definition of "scripting language" and especially how it's different from a good formal definition of "programming language"... (Untill then i find it useless to make the difference and i'll call them all programming languages.)

Mon, 13 Mar 2006 at 19:22:38 GMT Link

5.John Collins said:

Is persistence always a good thing, especially for a default behaviour? There are instances where it is required, for example for a web daemon or bot, but just for a normal web page/servlet?

I do not think that persistence is a required as you make out, as it is not memory efficient. Why would you want your objects to remain in memory, unless you were sure that they were going to be used again? If they are not required, it is just using up memory on the server.

Java is very weak on the web server front, especially when you factor in the need for constant restarts every time you change the application. This need for restarts when combined with object persistence makes Java a really bad option for commercial, shared web hosting, as the administrator overhead is massive.

PHP needs a persistence mechanism for those instances when it is required, but I don't believe that it should ever be the default behaviour for objects.

Mon, 20 Mar 2006 at 09:18:09 GMT Link

Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.

Work and Books

Analog Essential PHP Security HTTP Developer's Handbook