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

Posted by Dave Benjamin on March 23, 2006 at 03:20 PM 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 05:33 PM 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 24, 2006 at 02:22 AM 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 24, 2006 at 05:34 AM 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 24, 2006 at 06:57 AM 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 08:24 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 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6389769.

=================================================

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 >();

Allow:

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();

Allow:

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;
}

Allow:

class IntWrapper public int i;

And instead of:

public String toString() {
    return "Hello";
}

Allow:

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.

JUSTIFICATION :

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.

CUSTOMER SUBMITTED WORKAROUND :

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 03: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
		d.setTime(0);
		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:

if(badData){
	return;
}

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 09:39 PM PST #

public class Bob{
  String str;
  public Bob() {
    str = this.String();
    str = new String();
  }
  String String() { return "Bob"; }
}

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 09:20 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 12:26 PM PST #