Here's James Gosling explaining why Java isn't a "scripting" language"

The biggest was concerns about performance and the inevitability of scale. I can't remember how often I've had experiences where someone has proudly shown me some system they've put together using the scripting-language-du-jour: things like an Adobe Illustrator clone written entirely in PostScript; a satellite groundstation diagnostic system written as TECO macros; a BASIC compiler written as Emacs macros; fourier transform algorithms in PostScript... This list is endless. They always ended with "this is so cool, but I'd like it to be as fast as {C,Assembler,whatever}". People get into scripting to quickly build small quick things, but they often grow far beyond where the initial concept started.

Another was about testing, reliability and maintainability. One of the common properties of scripting languages is brevity. This tends to lead to omitting declarations, weak typing and ignoring errors. Generally a great thing if you're quickly putting something together; not so great if you want checks and balances that crosscheck correctness.

It's telling that he lumps all scripting/dynamic languages together as weakly typed (casting in Java, anyone?). Makes me wonder if he's even looked at Smalltalk or Ruby - since both are strongly, but dynamically, typed. In Smalltalk, you can't get a type error - you'll get a well understood exception.

Then there's his assumption of slowness - not all dynamic languages are interpreted. Lisp, for instance, has implementations with type inferencing and all the speed of optimized C. Most Smalltalk implementations use a JIT, and are plenty fast (although, doing arithmetic tests is not an area Smalltalk shines at). Ruby is interpreted, but there's at least one project - YARV - out to create a JIT.

The fun part is, Gosling caught a lot of crap for that post, and mostly backed off, retreating into the "chains are good for you" position:

One of the slogans that was brought up in the commentary to my previous blog entry was "freedom vs. safety". Once upon a time I used to believe that: it has certainly been conventional wisdom for years. But a lot of the time, the truth is actually that safety is freedom (eg. a good safety harness and rope give you the freedom to climb a mountain).

When I'm writing a function and declare a parameter to be an Image, I am free to trust that it is an Image. I'm free to trust that no one's array access has smashed my data structure. Examples abound.

Ahh yes, argument by assertion. "Examples abound", so he needn't give any. I've made this point many times - the kind of error that type checking catches is extremely rare - it's come up a handful of times for me over the last 13 years of Smalltalk development. The kind of type checking that Java requires comes at a high cost - it catches errors that almost never come up, and adds in expensive rigidity (generics are simply the latest attempt by the Java guys to muck their way past the casting issue).

Which reminds me - casting is a lie to your compiler, and walks right past this vaunted type safety. So if the "safety"offered by Java style typing is so phenomenal, then why do you allow casting at all? Wouldn't you be even more safe and more free without it?