Comment by nick_riviera | Hacker News Reader

Comment by nick_riviera | Hacker News Reader

I disagree with this, as a part time Java developer (I do C# most of the time). The points I disagree with:

1. OO is bad. Every paradigm is bad if you misuse it. If you build deep abstractions then you will hang yourself regardless. Some very elegant and simple designs can emerge from OO code, but only if you think about the problems first. The majority of pain consists of forgetting to do that step. There is no magic bullet - FP has its own pitfalls as well as does simple procedural programming.

2. Everything looks like it's written by an architect. Well that's a broad generalisation and I'm sure some people titled architect would be sick at the association (considering they usually reduce complexity) but the problem here is that people aren't using the frameworks properly. Not joking but the last two or three Java web applications I've put together have virtually no code in them. It's just the domain model, the views and query encapsulations. Nothing else. The abstract factory factory factory factory crap isn't your problem. If you make it your problem, then you're just doing it wrong or not using the tools provided efficiently.

3. Android. Android is abysmal (I've written a couple of things for it so far), but that's not because of Java but the fact that the Android API and versioning mess is a pile of unstable crap. It'd be nice if there were't so many exceptions.

If you're going to pick on Java, at least jump on: Idiotic code on the web, Glassfish being a right pile, view technology being foul, servlet container reloading, Swing/JavaFX or Eclipse...

Some of the complaints about the over-formal language is a matter of taste, perhaps, but it does grate and is not a new complaint (see also: the Kingdom of Nouns rant). However Java developers are learning (or migrating to Scala/Groovy/Clojure). And there is hope -- the Play framework, for example, is an example of Java done right (imho). Spring 4 is moving in the right direction.

I don't think it's a matter of taste. TBH I write very little of the code that is checked in to the source control. The IDE does all the boilerplate. I literally design the method signatures, define the access policy for the methods and fill in a few gaps here and there.

Play is not Java done right by any means. It's tightly coupled, has really poor documentation, breaking changes galore between major releases, deployment is trouble (compared to tomcat) and rather tied to Scala's API.

Java done right is picking some lego bricks that you stick together to get what you want and telling it how to wire them up.

YYMV but 99.9% of all problems are already solved off the shelf.

Ninja Framework is rather nice, I've found. I looked around for Java web frameworks lately and it seemed to be the one that balanced good documentation, features, simple configuration and so on to my liking.

Thanks - I will investigate this one.

Deployment of Play is as simple as copying a JAR file onto a server and starting it.

I agree a bit with the Play framework comments. It has some interesting things borrowed from Rails but it borrowed to much of the magic for my tasted. I'm using Wicket right now. which is very nice and flexible and well documented. The source code is easy to understand it is not lasagna.

The Java variety of the Play Framework is indeed pretty decent. Last time I worked with it however, it had to some really hacky stuff to work around deficiencies in Java (7).

> Java developers are learning (or migrating to Scala/Groovy/Clojure)

Scala can be used instead of Java to build systems, though when a Java developer uses it for the first time to build a system, that system will need heavy refactoring to make use of Scala's functional facilities. Groovy's really intended for use with Java, not instead of it, such as gluing Java apps together, testing Java objects, scripting Grails, and 20-liners for Gradle builds. I don't know how much Clojure's used to build systems in industry, though it's certainly my language for scripting.

What's your beef with JavaFX? I've been using it recently and it's a surprisingly well designed and nice UI framework. Parts of it are kind of immature and there are occasional surprising holes in its functionality, but that's because the current generation (after dropping the scripting language) is only a couple of versions old.

Mainly FXML (I hate XAML as well) but it's better than Swing.

How would you prefer to define UI layouts? Some other DSL? A binary format?

Another DSL. Structural DSL like this:

   form {
      input {
         name = "bob"
         label = "Bob"
      }
      button {
          action = #{bean.submit}
      }
   }

I've actually wrote a C code generator DSL over the top of Win32 many years ago that did this so the financial app I was working on so we didn't have to write millions of dialogs in win32 loops.

KotlinFX defines something a bit like this.

That said, I found FXML + IntelliJ to be quite painless. The closing tags are verbose when you have small toy examples but in big files they help orient you by reminding you what the end of a block is. And I mostly use Scene Builder anyway.

You might already be familiar with it, but this looks a lot like QML.

I wasn't actually - never used Qt (been stuck in win32 and Wx). Thanks for pointing it out :)

Reply on news.ycombinator.com