4 ms·

Most of my work these days is Java too, fwiw. But only because I need Lucene and Hadoop ;-) The main bad habit is a gross overuse of patterns to compensate for

by smanek 16y ago

Most of my work these days is Java too, fwiw. But only because I need Lucene and Hadoop ;-) The main bad habit is a gross overuse of patterns to compensate for language stupidity (see: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/). A few particular examples include: - Too much global state. You call it a Singleton. I call it a global variable with a fancy name and a lot more code. - You lose the ability to think functionally and dynamically. You can see the core of the architecture much more clearly if your default thought is 'I want to pass a function' or 'I want to call a fn based on rutime types.' And then you should convert that to what's implementable in language X (strategy pattern and visitor pattern, respectively for Java). Thay way you don't lose sight of the forest for the trees (and can implement what you're trying to do without cruft in a good language). - Verbosity. It's bad enough that passing a small fn (1 line of code in a decent language), requires a separate class and 20 lines of code in Java. On top of that the type system is too weak to actually stop most interesting errors but just strong enough to be annoying. And for some idiotic reason, they won't even implement compile time type inference which would save lots of verbosity and maintain code/bytecode compatibility.

kbd 16y ago
I'm personally mad at Doug Cutting for perpetuating Java. Java is a virus. If Lucene and Hadoop were written in C/C++ you'd be able to easily use them from basically any language. Because they're written in Java, it forces the rest of your code to live in Java land as well.
- nickolai 16y ago
  there is a C++ port of Lucene (named CLucene iirc) Not sure if there is such thing for Hadoop though.
  - timr 16y ago
    Yeah, but because it's not the main project, the CLucene port is perpetually the red-headed stepchild. It runs several versions behind the Lucene trunk, and therefore, you have to choose to ignore its disadvantages. ...which is a shame, because I agree with the OP that the choice of Java was a mistake for a large, high-performance system.
- regularfry 16y ago
  Think of it from his point of view: if you've already got a large chunk of code and working systems in Java-land that you want to strap a text indexer to, what language would you pick?
Sandman 16y ago
I agree with you about the verbosity of Java, it's driving me nuts. Also, overuse of XML in java-related frameworks/platforms etc. I mean, when it gets to the point where you have to use complex logic to perform a task, you have to start wondering whether xml is the way to go... As for overuse of patterns - well, to be honest, I sometimes actually wish that my colleagues would learn some (at least basic) patterns. Quite a large number of them wouldn't know how to implement Strategy, for example. As for your other points.. I don't know. I think this is debatable. What does too much global state mean? Is having singletons in your application inherently wrong, because they introduce global state? I don't think so. Overuse of singletons (and overuse of any pattern for that matter) is certainly a code smell, but there are simply some situations where singletons are appropriate. Or would you argue that this is true for Java simply because of bad design of the language itself? What I, personally, dislike about Java is it's really bad handling of lists. You see, as somebody working on Java enterprise projects, I constantly have to do something with lists, I fetch them, sort them, filter them, perform operations on certain elements of the lists etc. And it's incredible how verbose and ugly and littered with for-ifs the code gets. Yes, members of JCP EC, we need those closures, and we need them now.
- grayrest 16y ago
  > What does too much global state mean? Is having singletons in your application inherently wrong, because they introduce global state? I don't think so. I do. If you have an hour, the following talk by Rich Hickey (clojure) covers philosophy behind global state being the problem. This is not a code talk and he takes his time getting into it so it's not the easiest talk to get into but it does explain the mindset. http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... To answer your question more directly: I believe Java's lack of functions/closures lead to excessive factory use, which tend to be singletonish and so you get the set of dependency injection/IoC frameworks that simply don't exist in other languages but exist in Java due to too much global state. There are other symptoms, but this is the first one that came to mind.
axod 16y ago
I disagree with all of that, but I doubt my opinion matters here. Hardly ever use globals, never use patterns, I think in code , dynamically... The whole point is to make passing in functions hard. Passing functions everywhere leads to spaghetti code.
maweaver 16y ago
> It's bad enough that passing a small fn (1 line of code in a decent language), requires a separate class and 20 lines of code in Java. No need to exaggerate, it's only a few extra lines functionTakingCallback(new Callback() { public void fn() { ... }}); I agree it's verbose enough to be annoying, but hardly a deal-breaker imho. EDIT: Just occurred to me that you might be looking at it from the other side, where you would have to define the callback class. Still, defining a static nested with a single function is only 3 lines of code.
kaffiene 16y ago
Saying that you can't think functionaly in Java is not a "bad habit" - that's a style choice. Likewise, being verbose is not a bad habit - it's an issue of style. As for global state - using singletons is a design decision. If you don't like them, don't use them! So many people on HN hate on Java just because they've made the switch to functional programming. All power to you, but none of what's good about FP makes Java bad - it's just different. I'd agree that there are some inherent design issues with Java - I've never liked primitives and I don't like how generics were implemented but other that that, it's a really excellent tool for a number of tasks. Just because it doesn't look like what you like, doesn't make it bad (this reminds me of when Java came out in the first place and all the C++ programmers were saying that it was useless because it didn't have operator overloading. not bad, just different!)

by smanek 16y ago

kbd 16y ago

I'm personally mad at Doug Cutting for perpetuating Java. Java is a virus. If Lucene and Hadoop were written in C/C++ you'd be able to easily use them from basically any language. Because they're written in Java, it forces the rest of your code to live in Java land as well.

nickolai 16y ago
there is a C++ port of Lucene (named CLucene iirc) Not sure if there is such thing for Hadoop though.
- timr 16y ago
  Yeah, but because it's not the main project, the CLucene port is perpetually the red-headed stepchild. It runs several versions behind the Lucene trunk, and therefore, you have to choose to ignore its disadvantages. ...which is a shame, because I agree with the OP that the choice of Java was a mistake for a large, high-performance system.
regularfry 16y ago
Think of it from his point of view: if you've already got a large chunk of code and working systems in Java-land that you want to strap a text indexer to, what language would you pick?

Sandman 16y ago

I agree with you about the verbosity of Java, it's driving me nuts. Also, overuse of XML in java-related frameworks/platforms etc. I mean, when it gets to the point where you have to use complex logic to perform a task, you have to start wondering whether xml is the way to go... As for overuse of patterns - well, to be honest, I sometimes actually wish that my colleagues would learn some (at least basic) patterns. Quite a large number of them wouldn't know how to implement Strategy, for example. As for your other points.. I don't know. I think this is debatable. What does too much global state mean? Is having singletons in your application inherently wrong, because they introduce global state? I don't think so. Overuse of singletons (and overuse of any pattern for that matter) is certainly a code smell, but there are simply some situations where singletons are appropriate. Or would you argue that this is true for Java simply because of bad design of the language itself? What I, personally, dislike about Java is it's really bad handling of lists. You see, as somebody working on Java enterprise projects, I constantly have to do something with lists, I fetch them, sort them, filter them, perform operations on certain elements of the lists etc. And it's incredible how verbose and ugly and littered with for-ifs the code gets. Yes, members of JCP EC, we need those closures, and we need them now.

grayrest 16y ago
> What does too much global state mean? Is having singletons in your application inherently wrong, because they introduce global state? I don't think so. I do. If you have an hour, the following talk by Rich Hickey (clojure) covers philosophy behind global state being the problem. This is not a code talk and he takes his time getting into it so it's not the easiest talk to get into but it does explain the mindset. http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... To answer your question more directly: I believe Java's lack of functions/closures lead to excessive factory use, which tend to be singletonish and so you get the set of dependency injection/IoC frameworks that simply don't exist in other languages but exist in Java due to too much global state. There are other symptoms, but this is the first one that came to mind.

axod 16y ago

I disagree with all of that, but I doubt my opinion matters here. Hardly ever use globals, never use patterns, I think in code , dynamically... The whole point is to make passing in functions hard. Passing functions everywhere leads to spaghetti code.

maweaver 16y ago

> It's bad enough that passing a small fn (1 line of code in a decent language), requires a separate class and 20 lines of code in Java. No need to exaggerate, it's only a few extra lines functionTakingCallback(new Callback() { public void fn() { ... }}); I agree it's verbose enough to be annoying, but hardly a deal-breaker imho. EDIT: Just occurred to me that you might be looking at it from the other side, where you would have to define the callback class. Still, defining a static nested with a single function is only 3 lines of code.

kaffiene 16y ago

Saying that you can't think functionaly in Java is not a "bad habit" - that's a style choice. Likewise, being verbose is not a bad habit - it's an issue of style. As for global state - using singletons is a design decision. If you don't like them, don't use them! So many people on HN hate on Java just because they've made the switch to functional programming. All power to you, but none of what's good about FP makes Java bad - it's just different. I'd agree that there are some inherent design issues with Java - I've never liked primitives and I don't like how generics were implemented but other that that, it's a really excellent tool for a number of tasks. Just because it doesn't look like what you like, doesn't make it bad (this reminds me of when Java came out in the first place and all the C++ programmers were saying that it was useless because it didn't have operator overloading. not bad, just different!)