Funny you use this example, because using line input is thing from the past. For me it's a "smelling".

I often see people demonstrating their point with line input or regexes, both of which are misused 90% of the time.

I'm convinced that ruby leads to shorter code at equivalent behavior; however I'm far from convinced that size is everything, because of various remarks of Donald Norman in his excellent book "the design of everyday things". For example: "place constraints in the world and not in the head", so if the constraint exists, it should be visible (which doesn't imply java type system, we can imagine something shown by the IDE that would not be code).

Apart from the language war, there is a community war. I don't use many "normal" java tools, because I feel they are dumb. But I feel there is a strong base of low-educated people in the new java-critics community, people that can only count lines, repeat the leader, cannot create new thinking by their own. And this is not new, a few well-intentioned leader get spoiled by dumb masses is common thing everywhere. But this is tragic, because where java (and C#/.net) represented a progress hover the mainstream C and C++ by using explicit typing and collection the last technology in interpretation and GC in a single product, and removing explicit pointer manipulation, python or ruby are nothing new, they are basically old tech languages, with old tech (if not dumb) interpretation. O'caml and Haskell (and the "new" bunch of logic/functional language like clean, curry etc.) did propose some innovation. O'caml did propose a new balance for generics and side effects ("weak types"), an interesting GC, some new type systems, Haskell proposed some interesting optimizations (massive rewriting thanks to laziness) a new compromise for mixing laziness and side effects, Concurrent Clean too, with its "unique" types.

The main problem with languages is people, and it has nothing to do with the line count. Because if you count the lines to make your language choice, then you can't criticize your boss when he manages by headcount chopping, when he imposes the new fad of the moment in the project etc. because you entered his system.

In my last job we divided the codebase by 5 without changing the language, we mainly trained people (management and ourselves the "newly hired" included) and removed stuff (because shit does not only come from development). Doing shit is not a language problem, it's a people problem.

Can you perhaps suggest a better pair of Java and Ruby programs that would serve as a counterexample?

A good contrast to make between Java and other languages on over-typing is Java's lack of a way to return multiple items at a time without making a container class.

How do other languages do it? I can't actually imagine it, odd as it sounds? You don't mean returning maps, I presume?

def return_three_values "1,2,3".split(',') end a, b, c = return_three_values

Like that?

(For the love of god, how do I get that in a pre tag?)

If you indent something a little,

 it will look like this
 as you would expect from
 a <pre> tag

Ahhh, I tried that, but apparently it doesn't work if you do it on the first line. So here it is, not on the first line.

  def return_three_values
    "1,2,3".split(',')
  end
  a, b, c = return_three_values

That's just returning an array, though, which Java could also do. What Java can't do is to assign variables to array values as in your example.

So, yes, the lack of assignment is part of the problem. But, of course, the duck-typing is half the fun of something like that. I can return anything (of any type) I want in a tuple of any size just by comma delimiting. Java arrays aren't that flexible, and worse, if you use one that holds more than one type (say Integers and Floats), you have to cast them to Object before you drop them in, and you get to cast on the way back out. Lots of type-related overhead to simulate something that should be easy.

Agreed, the inflexible arrays are quite annoying, maybe THE most annoying aspect of Java.

There are so many things wrong with your example! You basically wrote the ugliest Java code you could possibly think of for this simple program.

First, in order to get an objective comparison of code length you should at least use the same (length) variable names. You used "lineTokenizer" in your Java example and "l" in your Ruby example!

Second, you could have just written System.out.println(sum) in Java. The fact that you had to write System.out.println(Integer.toString(sum)) shows your lack of basic Java knowledge.

Lastly, the brackets around your one-line while loop in Java are unnecessary, unlike the brackets around your closure in Ruby.

Also, the Java main method declaration is irrelevant to your point, since it's written only once per program, and is automatically created by any IDE.

How about this equivalent Java code to match your Ruby example:

  int count = 0;
  Scanner s = new Scanner(System.in);
  while (s.hasNextInt())
    count += s.nextInt();
  System.out.println(count);

Not so different now, is it? You can write concise code in any language if you know how to use it.

Um... I didn't write the example. I took it from a site that encouraged developers familiar with a language to submit solutions.

The developer of the Java solution posted something I'd consider reasonably representative of the Java I would likely encounter from most Java programmers and I while I have almost no personal experience with Ruby, I have the feeling the Ruby solution is reasonably close to what Ruby programmers write.

While you can write concise code in any language, it seems few Java programmers bother to.

Perhaps you should submit your solution to the original site: http://shootout.alioth.debian.org/

Using an example from a benchmarking suite to illustrate language conciseness doesn't make any sense. We all know that conciseness is inversely proportional to speed. Whoever wrote that Java code was trying to write the most performant, not the most concise code. He did a great job, by the way, since for that particular benchmark, Java outperforms Ruby by a factor of 20! (http://shootout.alioth.debian.org/gp4/benchmark.php?test=sum...)

Sorry for initially assuming that you wrote the code. I wasn't familiar with that site, so I didn't register your original allusion to it.

Au contraire, the very fact that the programming benchmark site neither rewards or punishes conciseness makes it a good place to see how important it is to the average programmer when also dealing with an explicit performance criteria.

Also, I think your statement that conciseness is inversely proportional to speed is rarely true. It certainly doesn't hold for the programming examples at the shootout site.

I don't think that Ruby code will do what the original poster at the language shootout thought it would, as it's not equivalent to the Java code above it. If it were correct though, you could improve it by being more Ruby-like and doing it like this:

puts STDIN.inject {|sum, next_number| sum.to_i + next_number.to_i}

. . . or something.

I don't think that Java programmer was up to scratch, although admittedly Java won't get as short as Ruby. I would count that readline construct of Ruby as kind of cheating, though. It's a specialized feature that doesn't say much about the brevity of Ruby in general.

Cheating would be putting an open paren at the top of the file, a close paren at the bottom, and implementing it in Scheme as

   (apply + (read))

I've done things like that often enough (putting parens around file contents or each line of an ascii file) that I wonder if it would be worth writing a macro that inserted the parens for you on the fly as you read the file before handing it off to the code you want to execute.

I know that was vague, but I just get the feeling I'm often doing something semi-manually in Emacs that my code should be doing for me.

If that is wrong (cheating) - then baby, I don't ever want to be be right !

code as data wins again ! (but with great power, comes great responsibility).

It isn't only the language, it's the libraries and the programming community.

If you write the kind of Java that other Java programmers appreciate, you'll soon end up with lots of files full of long lines.

Ruby seems to encourage brevity everywhere.

I say seems because apart from a few Capistrano configurations I haven't done any practical Ruby programming. I have however written more lines of Java than I want to admit.

I only did some small exercises with Ruby and experienced a lot of problems that I never had with Java. But that was just because of the dynamic typing aspect I guess (and the mutable strings). It took me rather long to write a 30 line Ruby program. That doesn't mean anything, I was a beginner in Ruby and I am probably an expert in Java. I am just saying that I am still not convinced the brevity is the killer argument.

With Rails I had a similar problem, basically I stopped trying it when I hit the ActiveRecords part, because I thought configuring the OR mapping through the hasmap sucked big time: I had to look up everything in the ebook (PDF sucks), whereas Java+Hibernate+Annotations is just a breeze in Eclipse. I am still tired of Java, but as I said in another post, I am not yet sure how to best replace it.

Also, I have seen a lot of very bad Java Code. Maybe it is also the new Cobol in that respect, too many not so good programmers have been let loose on Java and give it a bad name.

I personally don't think that verbosity is an aim of Java. What I usually aim for, though, is understandable code.

that ruby code looks awfully verbose. you probably want

puts STDIN.inject(0) {|sum,line| sum + 1}