Scripting flamewar

I made some comments recently about scripting languages that generated flame storms in a variety of places. For example, JDJ and Artima. Yes, I did say those things. But there's a lot of context missing, and they're the flippant soundbite version of what should have been a long and careful explanation that could easily mushroom into a series of PhD theses. Amongst all the flamage there are all kinds of generalizations about "scripting languages" versus "compiled languages". My big problem with a lot of it is simply that these two polarizing categories are a pretty poor way of capturing the distinctions between language designs. The terms are almost as goofy as "Republican" versus "Democrat". Taking huge multi-dimensional spaces of choices on different issues, then combining and simplifying them all down to a brutally simple binary choice is goofy.

Over the years I've built quite a lot of scripting systems. I've also built a number of compilers for non-scripting languages. Given enough beer I'll even admit to having implemented a Cobol compiler for money in the deep dark past. But I've done more scripting systems than non-scripting systems.

There are issues in the tradeoffs between the two linguistic spaces all over the place. Someday I'd like to write a long tour through them, but there just aren't enough hours in a day. I have a hard time getting enough time to do even trivial blogging: being truly thoughtful takes a lot of time. But I'll try to cover a few.... For now, I'll make the generalization that "scripting language" means one that is interpreted with dynamic runtime typing, and the other camp is languages that are compiled to machine code and have static runtime typing. This is a broad over-simplifying generalization, but it matches pretty well what goes on in common conversations.

Raw execution performance: One of the usual arguments for scripting languages having acceptable performance is that the overhead of interpretation and dynamic typing doesn't matter. The performance of the system is dominated by other factors: typically IO and the language primitives. For example, PERL apps usually spend the majority of their time in file IO and string primitives. I've strongly made this argument in the past, and it's quite valid. But having observed developers usage patterns, the two most common things that happen to erode the argument are:

  1. Developers start doing things that are outside of what the language primitives are good at. For example, PostScript has great primitives for rendering. So long as you're doing rendering, it flies like the wind. But then someone goes and writes a game that's heavily based on rendering, and a piece of it needs to do collision detection between missiles and targets. Physics in PostScript: a bad idea.
  2. Developers start clamoring for new primitives. Some are too specialized to be reasonable "I want a fast collision engine", some are rational "object oriented programming has become the dominant style in PostScript, but the OO model is implemented in PostScript as a library and is slow".
There are a bunch of ways to respond:
  1. "Buzz off". My personal favorite. Don't use a hammer to tighten a bolt.
  2. Start adding more primitives. This is hopeless: you drown in wave after wave of requests.
  3. Put in a facility for developers to write their own primitives. eg. link hunks of C code into the interpreter. Can work pretty well, but the linguistic universe schism can be problematic. Not only do developers then need to learn two environments, but because of the cross-language calls each language can impose difficulties on the other (eg. doing a language with a good garbage collector has a hard time interacting well with C's malloc/free regime.
  4. Make the "scripting language" fast enough to implement primitives. It tends to end up not looking much like a scripting language. This is roughly the road I went down with Java: to see how close to a scripting experience I could get while being able compile obvious statements like "a=b+c" into one instruction in the common case. I could have gone down the road of making declarations optional, but I intentionally didn't.
Worrying about scale, evolution and testing: strong compile-time types dramatically improve the ability of the tools (compiler, IDE, ...) to do global checking and manipulation. Some people like this. Some don't. There's a fair amount of evidence that these sorts of facilities are really helpful in dealing with systems that get large, evolve over a long time or require large teams. The most-often-cited reason for preferring dynamic typing is that it can make the development process easier: no need to bother typing all those yucky declarations.

There are a variety of middle-ground solutions:

  • One is to allow, but not require, declarations. This is particularly common in Lisp dialects where you can sprinkle declarations like (fixnum i j k) where needed to cause the code generators to generate efficient code. The big problem is figuring out the "where needed" bit. Sometimes it can be dicey to figure out all the places where there are issues. Often there are no real performance hotspots: no loops burning up all the time. Rather, it's a "peanut butter" problem where it's spread everywhere: you have to tune everything to make a difference.
  • Another is to make the language be strongly/statically typed, but to make the declaration process more transparent. One extreme point in this space is ML which does extensive type inferencing (leading sometimes to developer confusion because they can't figure out what the type inferencing engine is doing). An operator that I've long wanted to add to Java is "declare and assign":
    v:=eDeclares v to have the same type as e, and assigns e to v. "x:=r\*sin(t);" would be roughly equivalent to "double x = r\*sin(t)".
    v:==eJust like :=, except that it makes v final

    There's a lot more to say, but this is enough for today...


Yes, people tend to forget about trade-offs (I think economists term this as opportunity cost). I think people should stop looking for the silver-bullet. Maybe a "cease-fire" in this flame war is figuring out ways of getting scripting languages and non-scripting languagues to work together.

Posted by Hon Hwang on March 23, 2006 at 05:46 AM PST #

What does it mean for a language to be interpreted? Is Python interpreted? Is Java?

Posted by Dave Benjamin on March 23, 2006 at 07:20 AM PST #

What does "declare and assign" provide me as a developer? Lesser keystrokes? That is what an IDE should provide, not necessarily the language. C# 3.0 (yuk) wants to add implicit typing.

For example:

var x = new Foo();

And the compiler changes var to Foo for you. I honestly do not see what this gives me. In fact I think it is dangerous.

Compare the following two lines of code:

Foo x = y;
var x = y;

Which is more readable and less ambiguous?

Trust me, I am all for ease of use, but not at the expense of other "good" things. Especially since the IDE can help you in that regard.

I believe we have reached a point where the language is "good enough" and now our tools need to help is in other ways.

Netbeans 5.0 is a wonderful way of doing that! :)

Posted by Abraham Tehrani on March 23, 2006 at 07:39 AM PST #

"Start adding more primitives. This is hopeless: you drown in wave after wave of requests."

How is it different than to keep adding support to new versions of JSDKs/JREs, IDEs (NetBeans, Java Studio Creator), etc?

So far, the competition is closer to loading the VM in the operating system. So I guess people won't rewrite everything in Java in the future. That is, it would be great if the JVM could be integrated with the OS, right? :-)

Posted by Joao Pedrosa on March 23, 2006 at 09:33 AM PST #

Interesting idea with the operators, clean augmentations like that always seem like excellent options to consider. And thank you setting the scripting fiasco/record straight!

I know I'm not the only one getting tired of certain people ramble on and on like they'd just be introduced to the concept of a scripting language.

Posted by Ivan on March 23, 2006 at 09:58 AM PST #

Apart from PhD theses in CS, there's also room for theses in Economics, or maybe Sociology as well; at least room for an essay. What is missing in this discussion is the economic world we live in. In business environments, Java takes up the lion's share of the market, and people who specialize (or want to) in other languages (outside of stalwarts like C, C++ or alternatives like .Net) are frustrated. And people who can no longer make big bucks promoting the "new" Java technology are now looking for new places to make big bucks, like "new" dynamic technology that will, surprise! suddenly make development much easier. People are not just arguing on technical grounds but also economic ones (on all sides of the issue). Certainly a mess. Thanks for clarifying your point of view. Cheers, Patrick

Posted by Patrick Wright on March 23, 2006 at 06:22 PM PST #

[Trackback] I've just read James Gosling's post on how he got flamed for daring to say that scripting languages aren't a panacea. Whereas the old language crusades used to be fought between "compiled languages" it seems the new jihad is between "compiled" and "...

Posted by Alan Burlison's Blog on March 23, 2006 at 07:05 PM PST #

[Trackback] Welcome to today's IT Blogwatch, in which Microsoft reorganizes, Scoble keeps schtumm, and bloggers smell a rat. Not to mention the Vice President has a rider, just like his rockstar friends...

Posted by Computerworld Blogs on March 23, 2006 at 09:34 PM PST #

"You fool! You fell victim to one of the classic blunders! The most famous is never get involved in a land war in Asia, but only slightly less well-known is this: It is never PERL! It is "Perl" for the language and "perl" for the interpreter!"

Posted by Bob on March 23, 2006 at 09:50 PM PST #

"Lesser keystrokes? That is what an IDE should provide, not necessarily the language." An IDE won't provide you clear, dense, easy to read code. With it, you can just output longish endless lines of autocompleted method calls, but it won't all of a sudden be any easier to read and make sense of that gibberish output in the long run... That's another huge advantage of denser, compact languages like Python, Ruby, Haskell, Scheme and the likes: powerful, very high-level primitive operators and datatypes which do away for most of the need for lots of libraries providing the same...

Posted by nemesis on March 23, 2006 at 10:57 PM PST #

I believe grouping all dynamic languages into scripting languages is over generalization. For example, there are some scripting languages that are domain specific, but others are general purpose like Java, C#. Also, with the Moore's law, computing is becoming cheaper and faster so scalability and performance will have less influence. The same kind of scalability and performance concerns were expressed about Java. The time for dynamic languages has arrived and they pose serious threat to widely spread languages. This does not mean the dynamic languages will replace statically compiled languages, but will start to eat their way into widespread use. Clearly, this has been recognized by Sun as Mustang will have strong support for scripting languages, but may be they can embrace it more.

Posted by Shahzad Bhatti on March 23, 2006 at 11:03 PM PST #

Huh. Currently all Common Lisp implementations with compilers are as fast as Java with HotSpot. Is that fast enough?

Posted by Notany on March 24, 2006 at 12:24 AM PST #

"scripting languages that are domain specific, but others are general purpose like Java, C#"

Your view of scripting is so twisted i don't even know where to begin. I just know i wouldn't like to do quick scripting jobs by glueing together other tools with java or C#...

Posted by nemesis on March 24, 2006 at 12:36 AM PST #

I submitted the following request for enhancment that is along the same lines as James's suggestion. You can vote for this RFE at


Shorter Syntax for Common Operations

Java is quite verbose, but this verbosity can be eliminated quite easily:

0. Introduce the <code>var</code> keyword.

EG instead of:

ArrayList< String > strings = new ArrayList< String >();
var strings = new ArrayList< String >(); // also see 1 below
Similarly allow:
final strings = new ArrayList< String >();

1. Make the <code>new</code> keyword optional.

EG instead of:

String s = new String();
String s = String();
Combining 0 and 1 allow:
var strings = ArrayList< String >();
final strings = ArrayList< String >();

2. For methods and classes make the curly braces optional if there is only one statement. IE like <code>for</code>, <code>if</code>, etc.

EG instead of:

class IntWrapper {
    public int i;
class IntWrapper public int i;
And instead of:
public String toString() {
    return "Hello";
public String toString() return "Hello";

3. If a class needs to only implement a single method that is defined in either an abstract class of an interface, then allow the method qualifiers, return type, name, and the arguments types to be omitted.

EG instead of:

class MyAction implements ActionListener {
    public void actionPerformed( ActionEvent notUsed ) {
        textArea.append( textField.getText() );
Allow (only using simplification 3, see below for an example using rules 1 to 3):
class MyAction implements ActionListener {
    ( notUsed ) {
        textArea.append( textField.getText() );
Now an example of combining all rules 1 to 3, instead of:
textField.addActionListner( new ActionListener() {
    public void actionPerformed( ActionEvent notUsed ) {
        textArea.append( textField.getText() );
Allow (using all 3 simplifications):
textField.addActionListner( ActionListener() ( notUsed ) textArea.append( textField.getText() ); );
These rules would reduce verbosity, be easy to implement and would be backwards compatible.


The syntax in Java is quite long and this has led to a number of related languages that have shorter syntax but are otherwise similar, e.g. Scala, Groovy, and Nice. Also there are plenty of requests for features that amount to little more than short syntax, e.g. closures (5014235) and functors (5061325) are closely related to inner classes.

All of these issues could be addressed with the shorter syntax suggested and this would be a relatively minor change to Java yet bring many of the benifits offered by Scala, Groovy, Nice, closures, and functors.


Whilst modern IDEs do reduce typing; some people prefer a text editor, some environments like embedded can't run IDEs, and there is always the need to present textual examples in papers, tutorials, books, etc.

Posted by Howard Lovatt on March 24, 2006 at 07:55 AM PST #

I like Howard's suggestion for "var", "final", and making "new" optional. I would also like to have a multi-line (verbatim) string literal. :-)

Posted by Fuerte on March 24, 2006 at 06:55 PM PST #

I'm not sure sure about all those changes or the need for some of them.

<em>0. Introduce the <code>var</code> keyword.</em>

To make this change, a new keyword would be introduced, causing any program that uses the word 'var' as a variable name (and I would imagine there are quite a few) to fail to compile, requiring tedious changes and full regression testing of any affected class. The only other keywords free for use are 'goto' and 'const', neither of which really seems to fit what you're going for.

<em>1. Make the <code>new</code> keyword optional.</em>

And what happens in this case when some clever maintainer comes along and adds a new method:

public class Bob{
	public Bob(){
		String str = String();

	// . . . complex logic ...

	public String String(){
		return "Bob";

While that case may not be so bad (str probably gets a new value later, anyway), what about this case where a future coder attempts to create a quick utility method for themselves. While they identify the risk to their own code, they fail to check for other errors this might cause.

public class Robert {
	public Robert(){
		Date startTime = Date(); //get the start date to log metrics on total runtime

	 \*	Returns a new <code>Date</code> object with time set to zero.
	 \*  @returns firstMillisecondDate date on the first possible millisecond for
	 \*	         a <code>Date</code> object.
	public Date Date() {
		Date d = new Date(); //used deprecated 'new' keyword to avoid calling self
		return d;

Again, while these examples may seem be a little extreme, they should not be ignored and would pose a risk to legacy code.

<em>2. For methods and classes make the curly braces optional if there is only one statement. IE like <code>for</code>, <code>if</code>, etc.</em>

I don't see any issues with this one, it makes the code a little confusing if you're not used to it, but it does save a few characters. This reminds me of one piece of syntaxy goodness I always enjoy in Perl that I'd enjoy having in Java. For short, simple if statements, you can prefix the if with the action to take. Here's an example. Instead of:


or if(badData) return;

In Perl you could so this:

return if (badData); or return if badData;

I probably mistype my if-statements once a day when I try you use Perl-style in Java. I don't know, sometimes I just like the way it makes the program read, it's a little more natural for me. I'm sure there a thousands of other programmers out there that would hate, but I just kind of like it. :-)

<em>3. If a class needs to only implement a single method that is defined in either an abstract class of an interface, then allow the method qualifiers, return type, name, and the arguments types to be omitted.</em>

This one would just be another matter of taste. Looks a little confusing and arbitrary to me. I like being able to see exactly what a method is supposed to do: return type, parameters, exceptions, everything. I just see a little risk here, for a maintainablity point of view, for confusing code. Trying to modify someone else's code in the first place is a nightmare, much less when they chose to take shortcuts, either variable names (\*cough\* var \*cough\*) or clever tricks with the language to cut out a few curlies.

I think they are all interesting ideas and it's great to hear people being excited about Java and it's future, so keep it up, please.

Posted by Tim on March 25, 2006 at 01:39 PM PST #


Thanks for the comments, I didn't really explain myself that well on some of the points - so I will try and do better :)

1. Sure <code>var</code> is a new keyword and you would have to refactor code. Refactoring isn't too bad these days because IDE's are good. Also you could compile with <code>-source 5</code> (or similar). I didn't find the introduction of <code>enum</code> to be a problem and I guess <code>var</code> would be the same.

2. A method having the same name as class would have to be qualified like any other name clash (or use <code>-source</code> and or refactor), e.g.:

public class Bob{
  String str;
  public Bob() {
    str = this.String();
    str = new String();
  String String() { return "Bob"; }
Just a further note on <code>new</code>; I am not preposing that it is deprecated, it is needed to qualify use as above.

3. Not needing curly brackets and default for overridden methd, sure some people may well prefer the longer form. It might even be possible to use a pretty printer to swap to your prefered form, e.g. Jalopy does this for <code>if</code> etc.

Thanks again for your comments - Howard.

Posted by Howard Lovatt on March 25, 2006 at 03:05 PM PST #

It's interesting too see that you have exactly the same defensive reactions people had when Java started to grow. I know languages like Ruby are "currently" as flexible as Java is, and they lack the tools that Java developers have came to take as granted. But isn't it just a question of time/money just like what happened with Java? I've been programming with Java for the last 6 years, and I can't deny that my first encouters with ruby gave me a powerfully strong first impression. take things like closures and mixins, you'll see that as a language in itself, ruby is more elegant and concise than Java. I can write code that looks better, is more dynamic and fun to work with in ruby that I could ever dream of writing in java. Of course, java has it's strong points as a language, and \*currently\* as a platform, it's unbeatable as microsoft painfully learned. But in a free market the today's champion can turn into history in a blink. Simply getting into "denial mode" and using a kind of argument of authority to try to spread FUD is simply not going to work. We all respect Mr. Gosling accomplishments, but we respect even more hard facts, and this is not what we've seen on his commentaries. Change is good, and only by embracing it, Java can continue to be so wonderfully successful as it has been up till now.

Posted by Marcos Eliziario Santos on March 27, 2006 at 01:20 AM PST #

"v:==e Just like :=, except that it makes v final" This would be clearer I think: final v := e; (on the off chance you ever add it :-)

Posted by D'Arcy on March 27, 2006 at 03:17 AM PST #

I watched Java getting popular 10 years ago and joined the fun early on (moving from C++ to Java). Still like Java and also do quite some C# which is more or less the same. Observing what is happening around Ruby (and Ruby On Rails in particular) I recognize the exact same momentum/enthusiasm and also recognize that Java is getting stale. I think Sun (and Gosling) would do well to embrace Ruby on the Java JVM platform in order to keep Java (the platform) relevant 10 years from now. The weakness in Ruby is the JVM which is the chance for the Java JVM technology. By combining Ruby the language with the Java VM + java libraries, Sun could produce the killer technology for the next 10 years (and easily outdistance C# and .NET).

Posted by Morten Christensen on March 29, 2006 at 04:26 AM PST #

> It's interesting too see that you have exactly the > same defensive reactions people had when Java > started to grow. This argument is used so often that I'm getting sick of hearing it. Don't you people have better and smarter arguments instead of "been there ... Ruby is the new Java" ? I wonder what analogy was used when Java was the new kid ... oh, I remember, Java had applets ;)

Posted by Alex Dolftei on March 30, 2006 at 02:27 AM PST #

Post a Comment:
Comments are closed for this entry.



« April 2014