Des Traynor did a little post about how languages are not all the same, and Jeff Atwood jumped in with a C# version. Java came out looking really bad at 15 lines for a simple program, but frankly, the reason isn’t because of Java; it’s because of the coding styles used.
(Note that Des didn’t count line with just braces towards the line count; that’s why Java weighs in at 15, rather than 24 on his site).
The original Java version can be seen at Des’s site. First off, anyone who knows how to read should be able to spot that line 6 is redundant; the variable isn’t used. So we’re down to 14 already.
Then, who creates a File from a String then uses that to create a FileReader? FileReader has a perfectly good String constructor, where the String is the file name. Oh, and the normal technique (in my experience) with Readers is to chain them up. Also, FileNotFoundException is an IOException, and none of the other examples attempt to distinguish between different types of read errors, so why does the Java version?
Hmm… Jeff didn’t use a ‘using namespace’ declaration in the C# version… well, we can do that for Java. So, after all that, we get this for the Java version:
class readAFile {
public static void main(String args[]) {
try {
java.io.BufferedReader br = new java.io.BufferedReader(new java.io.FileReader("readAFile.java"));
for (String line = br.readLine(); line != null; line = br.readLine()) {
System.out.println(line);
}
br.close();
} catch (IOException ioe) {
System.out.println("Could not read from " + "readAFile.java");
}
}
}
Only 14 lines even if you count all the empty-brace lines; 10 if you don’t. 11 if you want to put back the import statement, and if you did, then you’d have code like I would normally write it.
But coding idioms tend to account for more in the line count stakes than the language itself. Consider that the Java example (both mine and Des’) catch a specific exception, and use a block to handle it. The Perl and Python implementations use a “catch all” mechanism, and handle it all on the one line. Further more, the Python and Ruby implementations both do the actual loop processing in a separate block on the same line.
If the Java code were to combine those two techniques, it would look like this:
class readAFile {
public static void main(String args[]) {
try {
java.io.BufferedReader br = new java.io.BufferedReader(new java.io.FileReader("readAFile.java"));
for (String line = br.readLine(); line != null; line = br.readLine()) { System.out.println(line); }
br.close();
} catch (IOException ioe) { System.out.println("Could not read from " + "readAFile.java"); }
}
}
p.. Two lines less.
Also, there's a rich set of 3rd party libraries for most of these languages. Consider using a FileReader that supports java.lang.Iterable and tidies up itself... there are a number of implementations out there. So you get this:
class readAFile {
public static void main(String args[]) {
try {
for (String line : new TextFile("readAFile.java") { System.out.println(line); }
} catch (IOException ioe) { System.out.println("Could not read from " + "readAFile.java"); }
}
}
Hey, down to 5 lines! The Python one was four (if you take out the #!/usr/bin/python, as Des did for the Perl one), but then the Python one hasn’t created a class, either.
(FWIW, Jeff could easily have down the same to the C# version)
So there you go: conclusive “proof” that Python and Java are equivalent… 😉
And that’s why these line-count comparisons are silly.
Share this:
Software is too expensive to build cheaply.... 
The python version was also a little outdated, since about 2.2 I think you can directly iterate over file objects, not to mention the fact that ‘r’ is the default mode when opening a file.
i.e.
for line in file(‘foo.txt’):
print line
I don’t much like the style used to reduce line counts with it either, after all, you could do it in _1_ line in python with the appropriate exec / eval.
First off, thanks for your trackback. As I explained I basically copied the Java code from Suns website.
Obviously when editing I forgot to remove line 6.
It was not the intent of my post to make Java look bad (I am fond of Java as a language), it was to show how scripts are typically shorter than OO programs, and for many programs you will be far more productive in a scripting language.
I do not think that scripting languages are the only way to do things, that much is pretty clear in the post in my advice to undergraduate students I hope.
I did point out that my example was anecdotal and in no way scientific, so please don’t think that I really believed I had proved anything. I don’t.
You have pretty much streamlined the java program and used 3rd party libraries to get a 5 liner, kudos for that, but I guess I was going with the standard way of doing things. Take this Copy program from suns website…
http://java.sun.com/docs/books/tutorial/essential/io/filestreams.html
Thats the style of Java I was comparing to scripts.
Des, that’s basically why I put up the first version (the 9-liner) first. The second version (7 lines) is the same, except that it’s used the same “technique” of putting simple blocks on the one line, and that’s distinctly an idiom.
> And that’s why these line-count comparisions are silly.
Well, I agree, but as Des pointed out, the line counts are only used as a rough measure of language productivity– not as a language deathmatch scoring system.
> Also, there’s a rich set of 3rd party libraries for mose of these languages. Consider using a FileReader that supports java.lang.Iterable and tidies up itself… there are a number of implementations out there. So you get this:
Right, the main loop is basically identical across all the languages shown.
There are even ways to execute .NET code in a script-like mode where no main function / includes are required, which removes some of the OO “tax” as well. I really wish there was a script edition of the .NET runtime, but there isn’t yet– something called “Monad” is supposed to do that. It won’t ship in Windows Vista (sadly) but as part of a future Exchange release:
http://www.reskit.net/monad/
It’s actually really, really cool, and it’s a damn shame this won’t make it into Windows Vista.
And since the study Des and I cited also points out that individual programmer skill variances were greater than any of the language variances, I’m inclined to say NONE of the language choices* really matter other than personal preference or some other specific requirement.
* modern languages, eg, post C and post C++
Jeff, gotta agree with that one: individual skill outweighs all the other factors, on a moderate-sized project or more.
Scripting languages definitely win for productivity down at the small level, but they reach parity as the size of the project increases.
You can simplify your example even further by throwing the exception from the main method:
public static void main(…) throws IOException { … }
🙂
Ah, Eric, but that would have been cheating; all the other examples had an exception handler, so the Java one should as well.
I’d agree with Robert here. It also relates to what what Steven Cambell said on the other thread (http://www.codinghorror.com/blog/archives/000365.html)
“The strength of OO Languages is not their brevity, its their ability to handle complexity”.
Could the reverse be said for Scripting languages?
Des,
Well, that would depend entirely on how you define ‘scriptinig language’, after all, what distinction are you drawing between java as an ‘oo’ language and python as a ‘scripting language’? I’ve never really been able to obtain a decent explanation of the latter beyond “a language people commonly use to write scripts” which for me translates into “a language that I am productive in and has quick hooks into the OS”.
Clearly (IMHO) python handles complexity just as well as java, whether or not you see it as an object oriented language or a ‘scripting language’.
Most common definition of a scripting language I’ve heard of is one that has a built-in interpreter, which is also the primary mechanism for execution.
Thus, Perl, Python, and Ruby are all scripting languages. Basic is also, but Visual Basic is not, despite its “eval” function, as it has a separate compiler. Even Python’s optional compilation process doesn’t disqualify it as a scripting language, as it uses the interpreter to “compile”.
Note that under this definition, Smalltalk probably counts as a scripting language.
The issue I have with that definition is that it stereotypes the language based on an implementation. The fact that cPython’s runtime semantics can hide the compilation step (it’s still there under the covers of course) is a property of cPython alone, not necessarily the language. There are languages out there that have dynamic interpreter implementations and static compilation implementations.
That being said, i’d agree that the definition is probably the most common.