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.