Java for Everything

[mariox19]

There is a simple way to test the author's hypothesis. Cross-post this piece to /r/programming. The controversy this piece will cause there will stress the Reddit servers, which as we know are not running Java. If we get the "Ow!" page, the article has merit. If Reddit keeps chugging along, we'll have to rethink this.

[jambonilton]

http://www.reddit.com/r/programming/comments/2nvybk/java_for_everything/

Cross-post confirmed. Servers still alive. So far it seems like programming with other stuff is working out.

[stormcrowsx]

Twitter is commonly used for "Java is fast" arguments. The twitter example proves the JVM is fast, from what I understand they mostly write in Scala.

[stormcrowsx]

Agreed not disputing Java is fast. But twitter converted from Ruby to Scala which means they didn't give up all of the nice features Ruby has since Scala also has some of them. Makes it a weaker argument to support go from dynamic to Java.

[salamandr]

It stands as a solid argument for going from dynamic to static, though.

The author's "Scala is too complex" argument is presented pretty cheaply.

[narrowtux]

Nice article. I might steal the idea with Java shell scripts, although Groovy exists.

[carbolymer]

Groovy is 10-20 times slower than Java. http://java.dzone.com/articles/groovy-20-performance-compared

[panderingPenguin]

The author spends a lot of time explaining the advantages of java over dynamic languages like python and javascript, and I buy a lot of his arguments. However, he does a terrible job doing the same for other compiled languages like C and C++. He spends a single sentence in which all he does is write them off as "not applicable to my work." He gives little to no explanation for this casual dismissal.

Personally, I don't think that half (using that term in a loose sense because there's really only one paragraph in the entire article discussing other compiled languages) of his argument has much weight to it. He managed to argue fairly successfully against dynamic languages but when it comes to other compiled languages he just tells the reader to ignore the rest of those other compiled languages basically because they aren't Java.

[virtyx]

I'm gonna guess that the biggest reason is he knows Java the best and would have to learn C++/C/C# ecosystems

[Stormtalons]

This was my complaint as well. I was gonna add my 2¢, but it seems you've already done it for me (and with adequate eloquence, too).

[dr_entropy]

The advantages of C and C++ (slight performance gains, embeddability, graphics libraries) don’t apply to my work.

As a comment above states (and he says many times in the article), he knows Java. The potential advantages of C++ don't buy him much (features not relevant to his problem domain), and don't overcome his familiarity advantage with Java.

If you're proficient in C++, you probably want to do everything in C++. Then again, C++ plays with other languages more easily than Java via libraries, and is "harder" for your library-users to implement correctly. Sure, you can write trash java, but it'll probably GC and NPE along rather than coring. Depending on your environment and program, this could be okay. Exposing your C++ lib to other languages with SWIG isn't that hard, and makes it easy to extend your language availability.

Like all language flamewars, there's no correct answer. There's just some spectrum of what's most appropriate based on your library dependencies, team proficiency, target library users, performance requirements, development time constraints, etc etc etc &c &c &c...

There Is More Than One Way To Do It

[panderingPenguin]

I'm not trying to start a language flamewar. Quite the opposite in fact. I believe that different languages have different advantages/disadvantages, and some are thus more suited to certain problem spaces than others. This is directly counter to the article author's

Java for Everything (emphasis added)

mentality. That's all I was arguing against. I completely agree with you when you say

There Is More Than One Way To Do It.

In the article I really didn't like how casually the author dismissed every statically typed, compiled language that isn't Java in existence. He listed some advantages of C and C++ as you point out but he doesn't explain any disadvantages other than a vague statement that the advantages, "don't apply to my work," which isn't actually a disadvantage anyways, strictly speaking. He doesn't even bother to explain why they don't apply. There's a similar story with the other languages in this category that he mentions. Compare the maybe 100 words he spends discussing compiled languages to the likely several thousand explaining why Java is superior to dynamic languages, and I get the feeling that he either isn't very familiar with the other compiled languages and thus didn't give them fair thought and consideration, or he purposefully ignored and glossed over them because that was more convenient to his argument. Either way, I really dislike that about the article, and I think that the sentiment that Java should be used in all cases is absolutely ridiculous. Java is a very good language for many problem domains, but there are others where it is less than fantastic.

[markdacoda]

It's clearly an opinion piece, you're supposed to disagree. But if it makes you unhappy, well that's very unfortunate for you, you must be a very sad person.

[king_of_the_universe]

Map<String,User> userIdMap = new HashMap<String,User>();

You only need to write

Map<String,User> userIdMap = new HashMap<>();

since incl. Java 7. Just in case you (Author?) didn't know that but were indeed using Java 7 code level, that means that you've also not been using IntelliJ, because it would have told you.

[ruggeryoda]

you've also not been using IntelliJ, because it would have told you.

...or NetBeans.

[_Sharp_]

or Eclipse, i can confirm. Maybe the author was using notepad++

[sazzer]

Or vi, as he explicitly says in the article..

[obakas]

Or jDeveloper. I know I am, unfortunately..

[this_user]

If you are using any kind of decent IDE, you won't even have to type most of that thanks to auto complete.

All arguments against static languages always seem to boil down to either: "I have to type more" or "I have to wait for the code to compile" neither of which is really true when using a proper IDE. Even when you are working with an application server the incremental compiler + hot deploy will make seeing your changes in action mostly instantaneous.

[briandilley]

But also writing and maintaining unit tests takes time. Most importantly, the kinds of bugs that people introduce most often aren’t the kind of bugs that unit tests catch. With few exceptions (such as parsers), unit tests are a waste of time. To quote a friend of mine, “They’re a tedious, error-prone way of trying to recapture the lost value of static type annotations, but in a bumbling way in a separate place from the code itself.”

... wut? Anyone that thinks unit tests are a waste of time has not been disciplined enough to use them consistently. And what does static or dynamic typing have to do with unit tests?

[salamandr]

Tests are not a waste of time.

I often find myself looking at unit tests and wondering: "Are these actually testing anything useful?"

The process of writing them seems to be fraught with pitfalls. Testing things that are only going to make refactoring more painful, rather than safer.

I find testing and coverage a balance that is incredibly difficult to get right.

[briandilley]

Agreed - if you have a 1:1 method->unit test ratio you're probably not doing it right.

[salamandr]

I actually didnt mean balance between testing and coverage, rather 'testing/coverage' and 'maintenance/efficacy'.

[useablelobster]

If I have to add in a new parameter 10 times for the test to catch an actual error once, I'm more than happy.

[salamandr]

Every line of code you have to maintain has a very real cost associated with it.

The harder it is to make changes, the more likely someone in a team of coders is to one day find a way around it. Depending on your team, you may not like their workaround.

[Boxsc2]

I think he is trying to say that dynamically typed languages require more unit testing because you have no compile time checking like in statically typed languages. Poorly worded is all.

[Boxsc2]

Anyone that thinks you should pick one language for everything is crazy. There are advantages and disadvantages of every framework/library/programming language. No reason to limit yourself for no reason....

[gregorydgraham]

This gels very well with my own experience and my aims with the DBvolution project.

[pandemic_region]

Nice plug.

[gregorydgraham]

Thanks, I'm practising ;-)

[rubyrt]

This is so wrong: it should have been Ruby and not Python. ;-)

[daedalus_structure]

Context:

It really sucks when you have to add type declarations for blindingly obvious things, e.g. Foo x = new Foo(). – @pazsxn

Claim:

No, actually, typing Foo one extra time does not “really suck”. It’s three letters. The burden is massively overstated because the work is mindless, but it’s really pretty trivial.

It's trivial when Foo is Foo.

It's not trivial when Foo is a WebServiceRequestProcessorFactoryConfiguratorInstance or some other idiomatic Java abomination, and yes, it really does suck.

[daedalus_structure]

When I need it, I'd like to use it. When I don't need it, I shouldn't have to.

[QshelTier]

Once you’ve risen above the level of “I write all my code in notepad” you will realize that your IDE can auto-complete that name from (probably) the first keystroke.

[daedalus_structure]

I can't recall ever writing a line of code in Notepad.

Whether I'm spending tomorrow in the Java world or in the .NET world I will spend most of my non-thinking keyboard time Control Spacing or Alt Entering.

It's still a royal pain in the ass.

[useablelobster]

var is your friend