7 ms·

Why I love everything you hate about Java

114 points by of 14y ago

argv_empty 14y ago
The article explains why closures are a poor man's objects. Be sure to read the comments to see why objects are a poor man's closures.
- w0utert 14y ago
  The comments do in fact contain more interesting insights than the article itself. Good discussion.
- zanny 14y ago
  Both are a poor mans structs with name mangling!
  - anonymous 14y ago
    But really, those are all just fancy names for 'void*' for people who can't remember two things at once.
    - cpeterso 14y ago
      A pointer itself is not a composite data type. It can't remember two things at once.
      - jerf 14y ago
        void* is the zombo.com of pointers. It can do anything. The fact that it can do absolutely, utterly anything is precisely why it is useless.
        lurker14 14y ago
        Useless? The software running the computer you are typing on is full of void*.
        jerf 14y ago
        All the pointers are void *; and yet, none of them are.
ekyo777 14y ago
This article doesn't say much about Java, it is mostly about OOP patterns
- codewright 14y ago
  >it is mostly about OOP patterns It's mostly about why I love Clojure's partial / Haskell's currying.
  - josteink 14y ago
    As someone who has spent a little time into F# and other languages where currying are the default behaviour for any function, this is the one thing I find myself missing the most in clojure. Yes, I see why wee need partials and can't have currying by default. It would seriously mess up destructuring. Yes, I get that. I still miss it though.
    - codewright 14y ago
      I'd rather have destructuring.
kevingessner 14y ago
tl;dr: "different languages are appropriate for different uses"
- danabramov 14y ago
  or different habits, for that matter.
oconnor0 14y ago
I find it odd that while the article is titled about Java, all of the code examples are in Scala. The statement "function composition is a degenerate case of the Decorator pattern" in the blog is bizarre to me. OO languages like Java have to resort to the Decorator pattern to handle their lack of composibility; that seems far more degenerate than a language that supports this kind of composition without hacks. Also this article is 2.5 years old.
- mercurial 14y ago
  Agreed. Most design patterns are workarounds around missing features in a language. You can go around and pretend the reverse is true all you want, but it doesn't make it so. Also, looks the author never heard about decorators in Python, which let you do the same thing if you want, just with much less boilerplate. The article reads like it was written by somebody with experience in Java and Scala, but not much more.
MatthewPhillips 14y ago
AbstractFactoryFactory seems like an inevitability of object orientation. I have to wonder why we don't see it as often in other OOP languages. I'm not versed in Ruby or Python so I can't comment on those. In JavaScript there isn't the concise class or extends/implements keywords and people tend to hide how a library is implemented behind a closure that prevents you from extending it. So I wonder if Java just gets the blame because it is the most pure object oriented language. It doesn't put up walls preventing you from doing what OOP really wants you to do. C# is the same way, by the way, you see IThisOnlyExistsToBeGeneric<T> all of the time; AbstractControllerBase is a real class in C# MVC if I remember correctly. What walls does Ruby and Python have that prevents this? Because I see no reason why people aren't doing it.
- lars 14y ago
  There reason you don't see interfaces or abstract classes in Ruby or Python is because they are dynamically typed. Interfaces and abstract classes are byproducts that are required for Java and C#'s type systems to work. What use would you have for them in Ruby?
  - zimbatm 14y ago
    I still reason in terms on interfaces when passing arguments to a function though (eg: argument X needs to behave like a string). It will later be verified in runtime and when running the tests but it's how I reason when structuring the code.
  - viraptor 14y ago
    Actually Zope.interfaces for Python are more popular than I expected. Not sure how I feel about it really. They're both annoying and useful.
- willismichael 14y ago
  Could you clarify what you mean by "most pure object oriented language"? This seems disingenuous to me, since if you ask the users of a dozen different OO languages what "OO" means, you'll get a dozen different answers. http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html
r00k 14y ago
So we set about to re-write Querulous using my favorite modularity techniques: Dependency Injection, Factories, and Decorators. In other words, everything you hate about Java. Hey there Mr. Strawman. I write mostly Ruby, and I use dependency injection, factories, and decorators liberally. There's nothing in Ruby that makes these any harder than they are in Java (in fact, I'd argue they're easier.) Two years ago, when this piece was written, the author had more of a point: some people rejected anything that reminded them of Java out of hand, including design patterns. These days, I'd argue that interest in classic OO design ideas is experiencing a massive resurgence in the Ruby world.
- chris_wot 14y ago
  It's still happening. I'm constantly seeing ignorant comments about AbstractSingletonProxyFactoryBean!
  - tlianza 14y ago
    Here's a perspective that is not from ignorance: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
- tptacek 14y ago
  Why would you ever use a "factory" in Ruby? I'm less certain that DI is "wrong" in Ruby, although it's definitely unidiomatic.
  - ryeguy 14y ago
    I really don't understand why people think DI is wrong in Ruby. Decoupling is universally considered a good thing in every programming language. DI is a way to achieve decoupling. What about Ruby makes this unidiomatic?
    - lars 14y ago
      You can redefine any class in Ruby, so you never need to do dependency injection. If you want to test class A independent of class B, you redefine class B in your test. In that sense , dependency injection is a feature built in to Ruby, which is why no Ruby programmer talks about it. It's been said that every programming pattern is a programming language design flaw. This is evidence in favor of that.
sbochins 14y ago
Not sure how Java is better than all the "hipster" languages as you say. It doesn't seem like you're just using some design patterns that are present in basically every language. Clojure has futures too, but the syntax isn't as clunky as Scala or especially Java. All these synchronization primitives are in basically every other language. Maybe I'm missing something but I don't really see what is special about Java here. Has the OP ever tried any "hipster" languages, he might be pleasantly surprised if he did.
josteink 14y ago
Just before I saw this post on HN, I realized that the first editor I was presented to when I was being taught Java at university was emacs. Emacs felt slow, clunky, last-century and everything which could be light, nimble and cool Emacs made feel boring and hard. I did not get to like Emacs back then. In fact I've gone years and years and years actually never fully liking emacs, beyond it being simpler to use than vim (which I still consider insane) while readily available on most shells. It was a safe haven, although a unpleasant one. Recently though, I've dabbled in clojure. Eclipse is really not good for clojure development. Especially not so for learning how things works under the hood. So emacs is seemingly the lingo-franco in clojure circles, and I was forced to return to my old Java-related enemy. Or at least so I thought. Out of the box, almost nothing is optimal for clojure development. So you have to add packages (emacs supports packages? nice!), you may have to tweak init.el to do so (emacs is configurable and programmable through its own lisp-dialect? nice!), oh and you may want to add some repos and map package-install over this collection of useful pacakages (no way!). Once you're there and getting productive, you might encounter things you don't like. Google it and find ready-made lisp-code to import into your init.el, and your problem is solved. I guess that's not really directly related to this article, but before heading to HN now, I had the realization that emacs, despite it being the horrible tool which Java made me hate, is actually pretty awesome. You need the right perspective to fully appreciate something. This is crucial and something Java taught me this, although in the wrong way. And just as I realize this, then I see an article about Java and perspective. I like cute litle coincidences like that :)
- chris_wot 14y ago
  Have you considered adding your configurations to a GitHub repo?
  - josteink 14y ago
    I'd say it's not warranted and it's not needed. After meddling about for a bit, I did a reset and I did it using "emacs starter kit" by technomancy (of leiningen fame): https://github.com/technomancy/emacs-starter-kit https://github.com/technomancy/emacs-starter-kit On top of this I've added some tweaked versions of yank-indent and indent.el from the emacs-wiki: http://emacswiki.org/emacs/AutoIndentation http://emacswiki.org/emacs/AutoIndentation On top of that, I've just added whatever tweaks and hacks necessary to get screen & emacs behaving properly in a FreeBSD shell, since currently my best and most powerful internet-facing host is a FreeBSD machine. So as you can see, most of it is repo'd already :)
marizmelo 14y ago
Java is an excellent language, it has a elegant syntax, but... it's not made for web development. JSP/Servlets development is a joke.
- parasubvert 14y ago
  Those are 1997 technologies, though. Have you looked at - Play Framework http://www.playframework.org http://www.playframework.org - Jersey http://codahale.com/what-makes-jersey-interesting-parameter-classes/ http://codahale.com/what-makes-jersey-interesting-parameter-... - GWT https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/ or - Grails http://grails.org/products/ggts http://grails.org/products/ggts for example? Not saying any of these are perfect, but it's been 5+ years since anyone had to use JSP/Servlets/Struts. edit: formatting
  - smoyer 14y ago
    So true ... and on the server side you have JEE6 with CDI. You can even extend DI to a GWT client in the browser by using Errai. Life is way easier than it was even 3 years ago.
  - pjscott 14y ago
    Here's an article that covers some of that stuff: http://arantaday.com/the-modern-java-ecosystem http://arantaday.com/the-modern-java-ecosystem And a bunch of comments here: http://news.ycombinator.com/item?id=3304538 http://news.ycombinator.com/item?id=3304538
  - mbell 14y ago
    Mentioning Servlets seems pretty out of place here. The Servlet spec isn't a web framework its an HTTP middleware. Its more similar to Rack than Rails. Both GWT and Jersey are commonly deployed on top of Servlets.
    - vsync 14y ago
      Because in the past you had to use servlets directly, or JSPs that you had to do a lot of work manually to separate business logic from the presentation layer. Source: I worked at a Web startup circa 2000 where we did exactly that. I think people sometimes forget how far we've come.
Cacti 14y ago
I write in all kinds of languages professionally and have been doing this sort of thing for a long time (since I was 9 and I'm now 31), so, I'm mostly over the language war thing. Yes, I prefer some languages over others. Or certain languages in certain situations. But I try not to let my opinions get out of hand. Everything is pretty much the same anyway. Java? I can see the appeal. It's really come a long way. The only thing I can't get over about Java is the goddamned verbosity of it. It's _excruciating_ to write anything in Java. Yes, I know. Use a modern IDE. The namespaces are designed that way for a reason. Just deal with it. It's not a product of Java itself but of the libraries. Blah blah. It's still a painful environment to deal with and, with developer time several factors more important that just about anything else, I value my time highly and I'm not going to waste it on AbstractSingletonProxyFactoryBean bullshit. Now, yeah. If you're a huge corporation that is bumping up against the law of large numbers, where most of your developers are mediocre and yet still have to work together, then I guess Java is OK.
- vsync 14y ago
  I've found things like Lombok and LambdaJ to be super helpful as far as verbosity. One thing that does frustrate me is that the compiler enforces a target bytecode level at least as high as your source version. Meaning that even the simpler syntax for initializing generics isn't allowed even though it's pure syntactic sugar and has no impact on the generated bytecode.
- gurkendoktor 14y ago
  > where most of your developers are mediocre Does anyone have evidence (including anecdotes) that Java 7 is simple enough for mediocre developers? Every new feature in Java that I have seen, starting from and including generics, seem like the non-orthogonal hacks that make C++ so frustrating to learn.
nviennot 14y ago
In Ruby, we often use the middleware pattern (the rack stack, sidekiq or faraday to name a few). In the article, replace "Factory" with "Middleware" and "apply" with "call" and it's just like what we do in the ruby community.
viraptor 14y ago
This is a gem to remember in the future (from the comments): "Design Patterns are for when you run out of language".
- kbd 14y ago
  Thanks for this. Great quote. FWIW the original, by Rich Hickey, seems to have been "Patterns mean 'I have run out of language'". Cited here - https://google-styleguide.googlecode.com/svn/trunk/lispguide.xml https://google-styleguide.googlecode.com/svn/trunk/lispguide... - but I can't find an original source.
- jlgreco 14y ago
  I thought Rob Pike had a good point that, if "design patterns" had been a part of our language 40 or 50 years ago then things like calling convention would have been called "design patterns". Of course we don't talk about calling convention like that these days because languages handle it for us.
shasta 14y ago
No hire
dustingetz 14y ago
dependency injection : currying factories : type constructor decorators : higher order functions there's nothing wrong with DI and the like. what's wrong is the way it's done in idiomatic java. when you do DI in idiomatic scala, there isn't much of a problem.
- lurker14 14y ago
  Huh? How do any of your analogies work?
  - nandemo 14y ago
    One example of the first one: http://mikehadlow.blogspot.jp/2010/03/functional-dependency-injection.html http://mikehadlow.blogspot.jp/2010/03/functional-dependency-...
grogs 14y ago
I no longer care. Java is overly verbose, but therefore explicit. I'm happier to do concise Scala with more stuff implicit stuff going on, or more explicit stuff in Java with lots of Spring config. Opinionated frameworks which hide stuff from me are bad. They're good for initial productively, but you pay the price later - you have to understand it to weak it, and may find the architecture doesn't fit your problem. On the other hand, writing a Spring config file from scratch is a horrific process, especially without the Spring eclipse plug-in. But now that I understand web.xml's and application-context.xml/*-servlet.xml, and have written plenty of Spring config, my productivity is pretty damn good. So why should I care.
devin 14y ago
FWIW I don’t think the Clojure or Scala communities have any kind of “hate” for Java. Clojure views Java as an ally for many of the reasons you discuss. I think you’d be hard-pressed to find people in the Clojure or Scala camps that refuse to acknowledge there’s a right time to descend into Java. Likewise, I think any Ruby programmer worth his/her salt would tell you: if you’re trying to process 20,000 messages per second, don’t rely on Ruby. Moreover, JRuby, Clojure, and Scala are all quite fond of Java interop, so I’m not sure I agree with your opening statement that people who use said languages are “hipsters” who blatantly ignore the benefits of changing the level of abstraction when the situation warrants it.
confluence 14y ago
Language wars bore me. I've got pretty decent proficiency in C, C++, Java, Python and Javascript and I honestly like them all. I use C to really get what happens on the metal. I use C++ to leverage C and C++ libraries for perf critical applications quickly. I use Java like C++ where it makes more sense - Android, or availability of libraries etc. I use Python to prototype and quickly express complex ideas and determine their perf characteristics. I use Javascript for frontend web dev which communicates with json back-end APIs that are language/platform independent services that scale out horizontalty. I have 2 main rules. If the question is to learn one important thing or another - I learn both. Then when I come across a new problem I solve it with a combination of the tools at my disposal. Hence this is why I am currently learning Emacs, lisp, clojure, Scala and Haskell to round out my languages with maybe a little Ruby thrown in. This will take me a few years. In the end programming is just about getting things to screen quickly and correctly. Seen from that viewpoint most languages are very similar at heart.
- jackpirate 14y ago
  >Language wars bore me The Haskell vs. everything else language war really is important though. All the languages you mention are basically the same thing with slightly different syntax or a slightly different runtime environment. Haskell, on the other hand, revolutionizes the way you approach code. Or at least it did for me.
  - confluence 14y ago
    Yeah I'm not so sure. If Haskell is so great why isn't it dominating? Where are the Haskell phones, apps, services etc? Don't get me wrong - I enjoy it. But I've learned a few things throughout my life. First, the one true crowd is always wrong. Two, if it's so good - use it, and prove it. A lot of functional stuff is a ton of gushing talk - but no product walk. When Haskell runs on billions of devices or serves trillions of pages or produces trillions in revenue call me. Otherwise, I'll just keep shipping with my lame proven product producing languages. Functional languages have so far been all talk and no walk.
    - 14y ago
realrocker 14y ago
I refuse to get drawn in this.again.for the last time.
irisshoor 14y ago
I think people get too caught up on the verbosity side of code. Most devs spend considerable amounts of time debugging, and that's probably the suckiest part of the job. The amount of time spent writing the code (especially for someone who types quickly, as most devs do) is immaterial compared to the pain of trying to debug a nasty bug or perf problem (especially in a complex systems). That's where verbosity helps a lot as you don't have to dig into the library code to understand what's going behind the scenes, because most of the relevant configs and choices made in regards to how to use the framework are laid out in front of you.
pootch 14y ago
I reject the idea, that because I want to scale, I should have to write thread pools, executors, concurrent queues, and task completion APIs. This is 2012, any idiom, functional or not that doesnt support this as a built in capability is less than worthless. How many times do I have to write, rewrite and debug the obvious just to make a living? And as for the factory pattern, yes you can use it to hide a whole bomb load of configuration and code evil, that you probably should never even have to worry about, if you werent working in such a crap tool
- vsync 14y ago
  Which is why I love working in a Java EE application server like Geronimo where very smart people have gotten paid lots of money to do that boring grunt-work for me, and I can just spend my time building features and deploy a nice scalable system when I'm done.
yxhuvud 14y ago
I think the author of this article has too much exposure to Rails 2.x and not enough core knowledge of Ruby. If he had actually known the language well, then he wouldn't have made any references to the deprecated rails hack alias_method_chain. Instead, he would have used modules to examplify. The problem is though, when doing it with modules instead then the points he is trying to make totally disappears.
dscrd 14y ago
" Our life is frittered away by detail. Simplify, simplify, simplify! I say, let your affairs be as two or three, and not a hundred or a thousand; instead of a million count half a dozen, and keep your accounts on your thumb-nail. " -- Thoreau This is pretty much why I find Java (and others at similar levels of complexity) distasteful and try to steer clear of anything related to it. It is also why Go appears to me as attractive: it has simplicity everywhere.
setheron 14y ago
My experience at amazon has been that people.drink the config kool aid. They make everything configurable but never end of changing in the lifetime of the app anything from the sensible defaults. At that point you've just added unnecessary bloat. There is something nice to be said about code that works right off the bat with sensible defaults.
Peaker 14y ago
This guy must really love his null pointer exceptions.

114 points by of 14y ago

The article explains why closures are a poor man's objects. Be sure to read the comments to see why objects are a poor man's closures.

w0utert 14y ago
The comments do in fact contain more interesting insights than the article itself. Good discussion.
zanny 14y ago
Both are a poor mans structs with name mangling!
- anonymous 14y ago
  But really, those are all just fancy names for 'void*' for people who can't remember two things at once.
  - cpeterso 14y ago
    A pointer itself is not a composite data type. It can't remember two things at once.
    - jerf 14y ago
      void* is the zombo.com of pointers. It can do anything. The fact that it can do absolutely, utterly anything is precisely why it is useless.
      - lurker14 14y ago
        Useless? The software running the computer you are typing on is full of void*.
        jerf 14y ago
        All the pointers are void *; and yet, none of them are.

ekyo777 14y ago

This article doesn't say much about Java, it is mostly about OOP patterns

codewright 14y ago
>it is mostly about OOP patterns It's mostly about why I love Clojure's partial / Haskell's currying.
- josteink 14y ago
  As someone who has spent a little time into F# and other languages where currying are the default behaviour for any function, this is the one thing I find myself missing the most in clojure. Yes, I see why wee need partials and can't have currying by default. It would seriously mess up destructuring. Yes, I get that. I still miss it though.
  - codewright 14y ago
    I'd rather have destructuring.

kevingessner 14y ago

tl;dr: "different languages are appropriate for different uses"

danabramov 14y ago
or different habits, for that matter.

oconnor0 14y ago

I find it odd that while the article is titled about Java, all of the code examples are in Scala. The statement "function composition is a degenerate case of the Decorator pattern" in the blog is bizarre to me. OO languages like Java have to resort to the Decorator pattern to handle their lack of composibility; that seems far more degenerate than a language that supports this kind of composition without hacks. Also this article is 2.5 years old.

mercurial 14y ago
Agreed. Most design patterns are workarounds around missing features in a language. You can go around and pretend the reverse is true all you want, but it doesn't make it so. Also, looks the author never heard about decorators in Python, which let you do the same thing if you want, just with much less boilerplate. The article reads like it was written by somebody with experience in Java and Scala, but not much more.

MatthewPhillips 14y ago

AbstractFactoryFactory seems like an inevitability of object orientation. I have to wonder why we don't see it as often in other OOP languages. I'm not versed in Ruby or Python so I can't comment on those. In JavaScript there isn't the concise class or extends/implements keywords and people tend to hide how a library is implemented behind a closure that prevents you from extending it. So I wonder if Java just gets the blame because it is the most pure object oriented language. It doesn't put up walls preventing you from doing what OOP really wants you to do. C# is the same way, by the way, you see IThisOnlyExistsToBeGeneric<T> all of the time; AbstractControllerBase is a real class in C# MVC if I remember correctly. What walls does Ruby and Python have that prevents this? Because I see no reason why people aren't doing it.

lars 14y ago
There reason you don't see interfaces or abstract classes in Ruby or Python is because they are dynamically typed. Interfaces and abstract classes are byproducts that are required for Java and C#'s type systems to work. What use would you have for them in Ruby?
- zimbatm 14y ago
  I still reason in terms on interfaces when passing arguments to a function though (eg: argument X needs to behave like a string). It will later be verified in runtime and when running the tests but it's how I reason when structuring the code.
- viraptor 14y ago
  Actually Zope.interfaces for Python are more popular than I expected. Not sure how I feel about it really. They're both annoying and useful.
willismichael 14y ago
Could you clarify what you mean by "most pure object oriented language"? This seems disingenuous to me, since if you ask the users of a dozen different OO languages what "OO" means, you'll get a dozen different answers. http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html

r00k 14y ago

So we set about to re-write Querulous using my favorite modularity techniques: Dependency Injection, Factories, and Decorators. In other words, everything you hate about Java. Hey there Mr. Strawman. I write mostly Ruby, and I use dependency injection, factories, and decorators liberally. There's nothing in Ruby that makes these any harder than they are in Java (in fact, I'd argue they're easier.) Two years ago, when this piece was written, the author had more of a point: some people rejected anything that reminded them of Java out of hand, including design patterns. These days, I'd argue that interest in classic OO design ideas is experiencing a massive resurgence in the Ruby world.

chris_wot 14y ago
It's still happening. I'm constantly seeing ignorant comments about AbstractSingletonProxyFactoryBean!
- tlianza 14y ago
  Here's a perspective that is not from ignorance: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
tptacek 14y ago
Why would you ever use a "factory" in Ruby? I'm less certain that DI is "wrong" in Ruby, although it's definitely unidiomatic.
- ryeguy 14y ago
  I really don't understand why people think DI is wrong in Ruby. Decoupling is universally considered a good thing in every programming language. DI is a way to achieve decoupling. What about Ruby makes this unidiomatic?
  - lars 14y ago
    You can redefine any class in Ruby, so you never need to do dependency injection. If you want to test class A independent of class B, you redefine class B in your test. In that sense , dependency injection is a feature built in to Ruby, which is why no Ruby programmer talks about it. It's been said that every programming pattern is a programming language design flaw. This is evidence in favor of that.

sbochins 14y ago

Not sure how Java is better than all the "hipster" languages as you say. It doesn't seem like you're just using some design patterns that are present in basically every language. Clojure has futures too, but the syntax isn't as clunky as Scala or especially Java. All these synchronization primitives are in basically every other language. Maybe I'm missing something but I don't really see what is special about Java here. Has the OP ever tried any "hipster" languages, he might be pleasantly surprised if he did.

josteink 14y ago

Just before I saw this post on HN, I realized that the first editor I was presented to when I was being taught Java at university was emacs. Emacs felt slow, clunky, last-century and everything which could be light, nimble and cool Emacs made feel boring and hard. I did not get to like Emacs back then. In fact I've gone years and years and years actually never fully liking emacs, beyond it being simpler to use than vim (which I still consider insane) while readily available on most shells. It was a safe haven, although a unpleasant one. Recently though, I've dabbled in clojure. Eclipse is really not good for clojure development. Especially not so for learning how things works under the hood. So emacs is seemingly the lingo-franco in clojure circles, and I was forced to return to my old Java-related enemy. Or at least so I thought. Out of the box, almost nothing is optimal for clojure development. So you have to add packages (emacs supports packages? nice!), you may have to tweak init.el to do so (emacs is configurable and programmable through its own lisp-dialect? nice!), oh and you may want to add some repos and map package-install over this collection of useful pacakages (no way!). Once you're there and getting productive, you might encounter things you don't like. Google it and find ready-made lisp-code to import into your init.el, and your problem is solved. I guess that's not really directly related to this article, but before heading to HN now, I had the realization that emacs, despite it being the horrible tool which Java made me hate, is actually pretty awesome. You need the right perspective to fully appreciate something. This is crucial and something Java taught me this, although in the wrong way. And just as I realize this, then I see an article about Java and perspective. I like cute litle coincidences like that :)

chris_wot 14y ago
Have you considered adding your configurations to a GitHub repo?
- josteink 14y ago
  I'd say it's not warranted and it's not needed. After meddling about for a bit, I did a reset and I did it using "emacs starter kit" by technomancy (of leiningen fame): https://github.com/technomancy/emacs-starter-kit https://github.com/technomancy/emacs-starter-kit On top of this I've added some tweaked versions of yank-indent and indent.el from the emacs-wiki: http://emacswiki.org/emacs/AutoIndentation http://emacswiki.org/emacs/AutoIndentation On top of that, I've just added whatever tweaks and hacks necessary to get screen & emacs behaving properly in a FreeBSD shell, since currently my best and most powerful internet-facing host is a FreeBSD machine. So as you can see, most of it is repo'd already :)

marizmelo 14y ago

Java is an excellent language, it has a elegant syntax, but... it's not made for web development. JSP/Servlets development is a joke.

parasubvert 14y ago
Those are 1997 technologies, though. Have you looked at - Play Framework http://www.playframework.org http://www.playframework.org - Jersey http://codahale.com/what-makes-jersey-interesting-parameter-classes/ http://codahale.com/what-makes-jersey-interesting-parameter-... - GWT https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/ or - Grails http://grails.org/products/ggts http://grails.org/products/ggts for example? Not saying any of these are perfect, but it's been 5+ years since anyone had to use JSP/Servlets/Struts. edit: formatting
- smoyer 14y ago
  So true ... and on the server side you have JEE6 with CDI. You can even extend DI to a GWT client in the browser by using Errai. Life is way easier than it was even 3 years ago.
- pjscott 14y ago
  Here's an article that covers some of that stuff: http://arantaday.com/the-modern-java-ecosystem http://arantaday.com/the-modern-java-ecosystem And a bunch of comments here: http://news.ycombinator.com/item?id=3304538 http://news.ycombinator.com/item?id=3304538
- mbell 14y ago
  Mentioning Servlets seems pretty out of place here. The Servlet spec isn't a web framework its an HTTP middleware. Its more similar to Rack than Rails. Both GWT and Jersey are commonly deployed on top of Servlets.
  - vsync 14y ago
    Because in the past you had to use servlets directly, or JSPs that you had to do a lot of work manually to separate business logic from the presentation layer. Source: I worked at a Web startup circa 2000 where we did exactly that. I think people sometimes forget how far we've come.

Cacti 14y ago

I write in all kinds of languages professionally and have been doing this sort of thing for a long time (since I was 9 and I'm now 31), so, I'm mostly over the language war thing. Yes, I prefer some languages over others. Or certain languages in certain situations. But I try not to let my opinions get out of hand. Everything is pretty much the same anyway. Java? I can see the appeal. It's really come a long way. The only thing I can't get over about Java is the goddamned verbosity of it. It's _excruciating_ to write anything in Java. Yes, I know. Use a modern IDE. The namespaces are designed that way for a reason. Just deal with it. It's not a product of Java itself but of the libraries. Blah blah. It's still a painful environment to deal with and, with developer time several factors more important that just about anything else, I value my time highly and I'm not going to waste it on AbstractSingletonProxyFactoryBean bullshit. Now, yeah. If you're a huge corporation that is bumping up against the law of large numbers, where most of your developers are mediocre and yet still have to work together, then I guess Java is OK.

vsync 14y ago
I've found things like Lombok and LambdaJ to be super helpful as far as verbosity. One thing that does frustrate me is that the compiler enforces a target bytecode level at least as high as your source version. Meaning that even the simpler syntax for initializing generics isn't allowed even though it's pure syntactic sugar and has no impact on the generated bytecode.
gurkendoktor 14y ago
> where most of your developers are mediocre Does anyone have evidence (including anecdotes) that Java 7 is simple enough for mediocre developers? Every new feature in Java that I have seen, starting from and including generics, seem like the non-orthogonal hacks that make C++ so frustrating to learn.

nviennot 14y ago

In Ruby, we often use the middleware pattern (the rack stack, sidekiq or faraday to name a few). In the article, replace "Factory" with "Middleware" and "apply" with "call" and it's just like what we do in the ruby community.

viraptor 14y ago

This is a gem to remember in the future (from the comments): "Design Patterns are for when you run out of language".

kbd 14y ago
Thanks for this. Great quote. FWIW the original, by Rich Hickey, seems to have been "Patterns mean 'I have run out of language'". Cited here - https://google-styleguide.googlecode.com/svn/trunk/lispguide.xml https://google-styleguide.googlecode.com/svn/trunk/lispguide... - but I can't find an original source.
jlgreco 14y ago
I thought Rob Pike had a good point that, if "design patterns" had been a part of our language 40 or 50 years ago then things like calling convention would have been called "design patterns". Of course we don't talk about calling convention like that these days because languages handle it for us.

shasta 14y ago

No hire

dustingetz 14y ago

dependency injection : currying factories : type constructor decorators : higher order functions there's nothing wrong with DI and the like. what's wrong is the way it's done in idiomatic java. when you do DI in idiomatic scala, there isn't much of a problem.

lurker14 14y ago
Huh? How do any of your analogies work?
- nandemo 14y ago
  One example of the first one: http://mikehadlow.blogspot.jp/2010/03/functional-dependency-injection.html http://mikehadlow.blogspot.jp/2010/03/functional-dependency-...

grogs 14y ago

I no longer care. Java is overly verbose, but therefore explicit. I'm happier to do concise Scala with more stuff implicit stuff going on, or more explicit stuff in Java with lots of Spring config. Opinionated frameworks which hide stuff from me are bad. They're good for initial productively, but you pay the price later - you have to understand it to weak it, and may find the architecture doesn't fit your problem. On the other hand, writing a Spring config file from scratch is a horrific process, especially without the Spring eclipse plug-in. But now that I understand web.xml's and application-context.xml/*-servlet.xml, and have written plenty of Spring config, my productivity is pretty damn good. So why should I care.

devin 14y ago

FWIW I don’t think the Clojure or Scala communities have any kind of “hate” for Java. Clojure views Java as an ally for many of the reasons you discuss. I think you’d be hard-pressed to find people in the Clojure or Scala camps that refuse to acknowledge there’s a right time to descend into Java. Likewise, I think any Ruby programmer worth his/her salt would tell you: if you’re trying to process 20,000 messages per second, don’t rely on Ruby. Moreover, JRuby, Clojure, and Scala are all quite fond of Java interop, so I’m not sure I agree with your opening statement that people who use said languages are “hipsters” who blatantly ignore the benefits of changing the level of abstraction when the situation warrants it.

confluence 14y ago

Language wars bore me. I've got pretty decent proficiency in C, C++, Java, Python and Javascript and I honestly like them all. I use C to really get what happens on the metal. I use C++ to leverage C and C++ libraries for perf critical applications quickly. I use Java like C++ where it makes more sense - Android, or availability of libraries etc. I use Python to prototype and quickly express complex ideas and determine their perf characteristics. I use Javascript for frontend web dev which communicates with json back-end APIs that are language/platform independent services that scale out horizontalty. I have 2 main rules. If the question is to learn one important thing or another - I learn both. Then when I come across a new problem I solve it with a combination of the tools at my disposal. Hence this is why I am currently learning Emacs, lisp, clojure, Scala and Haskell to round out my languages with maybe a little Ruby thrown in. This will take me a few years. In the end programming is just about getting things to screen quickly and correctly. Seen from that viewpoint most languages are very similar at heart.

jackpirate 14y ago
>Language wars bore me The Haskell vs. everything else language war really is important though. All the languages you mention are basically the same thing with slightly different syntax or a slightly different runtime environment. Haskell, on the other hand, revolutionizes the way you approach code. Or at least it did for me.
- confluence 14y ago
  Yeah I'm not so sure. If Haskell is so great why isn't it dominating? Where are the Haskell phones, apps, services etc? Don't get me wrong - I enjoy it. But I've learned a few things throughout my life. First, the one true crowd is always wrong. Two, if it's so good - use it, and prove it. A lot of functional stuff is a ton of gushing talk - but no product walk. When Haskell runs on billions of devices or serves trillions of pages or produces trillions in revenue call me. Otherwise, I'll just keep shipping with my lame proven product producing languages. Functional languages have so far been all talk and no walk.
  - 14y ago

realrocker 14y ago

I refuse to get drawn in this.again.for the last time.

irisshoor 14y ago

I think people get too caught up on the verbosity side of code. Most devs spend considerable amounts of time debugging, and that's probably the suckiest part of the job. The amount of time spent writing the code (especially for someone who types quickly, as most devs do) is immaterial compared to the pain of trying to debug a nasty bug or perf problem (especially in a complex systems). That's where verbosity helps a lot as you don't have to dig into the library code to understand what's going behind the scenes, because most of the relevant configs and choices made in regards to how to use the framework are laid out in front of you.

pootch 14y ago

I reject the idea, that because I want to scale, I should have to write thread pools, executors, concurrent queues, and task completion APIs. This is 2012, any idiom, functional or not that doesnt support this as a built in capability is less than worthless. How many times do I have to write, rewrite and debug the obvious just to make a living? And as for the factory pattern, yes you can use it to hide a whole bomb load of configuration and code evil, that you probably should never even have to worry about, if you werent working in such a crap tool

vsync 14y ago
Which is why I love working in a Java EE application server like Geronimo where very smart people have gotten paid lots of money to do that boring grunt-work for me, and I can just spend my time building features and deploy a nice scalable system when I'm done.

yxhuvud 14y ago

I think the author of this article has too much exposure to Rails 2.x and not enough core knowledge of Ruby. If he had actually known the language well, then he wouldn't have made any references to the deprecated rails hack alias_method_chain. Instead, he would have used modules to examplify. The problem is though, when doing it with modules instead then the points he is trying to make totally disappears.

dscrd 14y ago

" Our life is frittered away by detail. Simplify, simplify, simplify! I say, let your affairs be as two or three, and not a hundred or a thousand; instead of a million count half a dozen, and keep your accounts on your thumb-nail. " -- Thoreau This is pretty much why I find Java (and others at similar levels of complexity) distasteful and try to steer clear of anything related to it. It is also why Go appears to me as attractive: it has simplicity everywhere.

setheron 14y ago

My experience at amazon has been that people.drink the config kool aid. They make everything configurable but never end of changing in the lifetime of the app anything from the sensible defaults. At that point you've just added unnecessary bloat. There is something nice to be said about code that works right off the bat with sensible defaults.

Peaker 14y ago

This guy must really love his null pointer exceptions.