Live data from Hacker News

Java for Everything

teamten.com

81–90 of 344 posts

Re: Java for Everything

#81
A significant amount of the article is arguing that Java for everything is better because the author and his coworkers already knows it. I can make the same argument for Python _for me_. And for my company too; we have a ton of Python developers already, so it makes sense to write things in Python if possible in case someone needs to change or improve anything.

The author also talks about how Java's verbosity is a trivial issue, and in terms of "stuff you have to type", I agree. The point isn't to save a few characters to type. To me, the problem with Java's verbosity is that it _impedes understanding_. The excessive notation required by type declarations and generics and so on are visual noise that distract from what the code is doing.

There are some valid points raised too, such as concerns about Python's scalability, but that's an argument for _choosing the right tool for the right job_, which, while mocked at the beginning of the post as a way to avoid an interview question, is still good advice. For a lot of projects, Python is fast enough to handle the expected processing, has an ecosystem with libraries that handle all of the things the project might need to do, and is portable enough to run on the platforms necessary. For some projects, it fails one of these, and another language may be a better choice. That's okay!

I think the best takeaway here is that it is sometimes useful to see if you can leverage your existing knowledge in one programming language by applying it to a task you don't normally use it for. By all means, write shell scripts in Java, maybe that's really useful! Or maybe write a GUI in Haskell! Transpile BASIC to frontend code!

(For context, I use Python for web development (both small and large sites), scripting, and a few personal projects like a music player or emulator. I did a bunch of Java in college and some internships.)

Re: Java for Everything

#82
post #24
post #15

Earlier quoted context omitted.

Why not just use Groovy for everything instead of java ?

Speaking of - how is Groovy doing these days? I looked at the Groovy webpage and I saw ads splattered here and there - never a good sign, I also see that the mailing lists are pretty quiet. Is Groovy dying?

I'd say not too good.

Of course there are those two projects everyone mentions, Grails and Gradle, but I would say it's more correct to describe them as the only two niches where Groovy is actually used a bit, it's not like Gradle and Grails are just "flagship products" of a greater ecosystem.

For both, there are already better replacemens available, so I don't think they will grow much in the future.

Re: Java for Everything

#83
There's the language and there's the ecosystem. A lot of negative feelings that still linger are, IMHO, directed more at some of the painful historical aspects of the ecosystem: J2EE XML configuration hell, EJBs, bloated application servers, XML for everything, JAX-WS, SOAP, ant, classloader problems, maven dependency hell, 10 different logging libraries, etc... A lot of this stuff truly sucked.

But I feel things have improved over time. Dropwizard, gradle, embedded jetty, jersey, guava, Spring boot, etc... The trend is towards minimizing configuration and overall, the ecosystem has become somewhat more manageable. I wouldn't necessarily call it pleasant, but it's better.

An as for the language itself, Java8's lambdas + streams provide significant improvements.

Compare this (Java 7):

  public static List sortDescending(List ints) {

      ints.sort(new Comparator() {
          @Override
          public int compare(Integer o1, Integer o2) {
              return o1.equals(o2) ? 0 : o1 
to this (Java 8):

  public static List sortDescending2(List ints) {

      ints.sort((o1, o2) ->  o1.equals(o2) ? 0 : o1 
(Example is contrived, since you could use the built in Collections.reverse() to achieve the same result. My main point is that we have eliminated ~4 lines (counting braces) of ceremony.)

All that said, I'd rather be using Clojure.

Re: Java for Everything

#85

There's the language and there's the ecosystem. A lot of negative feelings that still linger are, IMHO, directed more at some of the painful historical aspects of the ecosystem: J2EE XML configuration hell, EJBs, bloated application servers, XML for everything, JAX-WS, SOAP, ant, classloader problems, maven dependency hell, 10 different logging libraries, etc... A lot of this stuff truly sucked. But I feel things hav…

I suspect readability isn't a big priority for you.

Here's how I'd write this, lambdas or not:

public static List sortDescending(List ints) {

      ints.sort(new Comparator() {
          @Override
          public int compare(Integer o1, Integer o2) {
              if (o1.equals(o2)) {
                return 0;
              } else if (o1 
My personal perspective is that your use is a typical abuse which turns simple code into something unreadable and overly complex. This makes code hard to maintain and buggy. Not to mention, it's nigh impossible to step through in a debugger..

Re: Java for Everything

#86

The problem with verbosity and repetition is not that it takes longer to type the code, at all. The problem is that it creates dependencies which you have to manage by hand. Changing `Foo a = new Foo()` to `Bar a = new Bar()` doesn't seem that bad... except when you have to propagate that change through the code base. Half of Java's tooling is dedicated to solving a problem that doesn't exist in good duck-typed langu…

If you are prone to having the "if (cmd == 'run') run();" pattern in multiple places, no language is going to fix your copy pasta and the maintenance issues it has. Java absolutely has mechanisms to fix that and factor it out, it just bs to say otherwise.

Re: Java for Everything

#87
post #67
post #47

Earlier quoted context omitted.

Refactoring goes a lot further than just renaming types. A refactor script _WILL_ rename both sides of 'Foo x = new Foo();' to 'Bar x = new Bar();', so given the right utilities (and if you use java for everything, it's _MUCH_ easier to become an expert at the tools!) this is not any more effort at all. Ctrl-Shift-R B A R No, not much effort at all. Just twice as many keystrokes. I wouldn't even mind the verbosity if…

It will give you faster compilation speed, though.

Think about it, does it really?

To parse Foo x = new Foo();, javac has to perform type inference on the right hand side to figure out its type, and then check whether that type is a subtype of the left hand side. Telling the compiler: "hey, trust me, variable x is of type Foo" doesn't make the compiler's job any easier at all.

Re: Java for Everything

#88
post #75
post #56

I've mostly embraced the JVM (as opposing to hating it), but I find myself reaching for Clojure a lot more than Java (although I have an Android app that I'm tinkering with). I find that an IDE helps (I use NetBeans for pure Java), but whereas I can hack just about anything in Clojure, Python or Go without much hassle, Java slows me down for some reason - I suspect it's the humungous class hierarchies and the time re…

Once you get used to working in Java (and have a relatively stable toolchain you can depend on), it's realistic to develop applications in Java almost as quickly as Clojure, though complex aggregations that Clojure makes one-liners will often be vastly slower to develop. IntelliJ makes a lot of things easier as well. When it comes to Java, you just need to really get familiar with your tools before you can be as prod…

In Java 8, those one liner aggregations are now possible and part of the standard library.

Re: Java for Everything

#89
Verbosity matters for reading and maintenance far more than it does for writing. IDEs can make the writing faster, but they can't make the code as easy to comprehend as it would be in a more expressive language. And remember that lines of code is the only proven risk factor for bugs.

Most sites are not Twitter. They're not Stack Overflow. They're not even Nanowrimo. I've watched a company spend two years, dozens of developers, and over a million in ESB license fees failing to write a site that was expected to have, at peak, 100 users/day. Their competitor had four guys writing Ruby, and was profitable after the first month. Nor are the performance advantages "permanent"; even if you use Java, you will probably have to rewrite if you reach Twitter scale, because your initial app won't be clusterable (or if it is, it's massively overengineered and your business will fail). So do it the way twitter succeeded - write the first version in Ruby, and then worry about performance when you need to.

The advantage of using the same language on both sides of a boundary are real but overstated. If you have a system with multiple components, you probably need to evolve the interfaces between them, and you need to be able to upgrade without downtime. Which means you need well-defined interfaces for which you understand the compatibility implications - in other words, you need something like Thrift. I've used Thrift even for Java-Java interfaces, but once you're using something like that it doesn't matter which language is on the other side.

Still, the library point is valid, as is the point about spending time with a language. Better to have one language that you know very well than ten in which you dabble. But by the same token it's worth taking the time to make sure that language is the very best available. I use Scala for everything, and there's plenty to learn - maybe even twice as much as a "normal" language. But if I'm focusing on that one language, I can afford to take the time to learn it really well. And Scala combines the expressiveness, clarity and scripting-suitability of Python (yes, it can be unclear if you use silly method names or libraries that use silly method names - don't do that then) with the strong type-safety and performance of Java. It's a great language in any case, but especially if you want a single language for everything, I don't think anything else comes close.

Re: Java for Everything

#90
post #65
post #49

Earlier quoted context omitted.

Because type safety is actually really valuable? /uses Scala for everything, from scripts to backend. Groovy usually translates 1:1 into Scala, but without sacrificing type safety.

In current version of Groovy you can mix static and dynamic typing in different sections of code by telling the compiler what are your preference.

Up to a point - I found the static support was quite buggy and I got the impression not many people were actually using it. Has it improved in the last few years?
Post reply on HN