Live data from Hacker News

Java for Everything

teamten.com

11–20 of 344 posts

Re: Java for Everything

#11
post #4

He learned something that most good Perl programmers learn fairly quickly: The interpreter/compiler is just the VM; the real language is the combination of all libraries available for it.

There's no shortage of good libraries for Python. He just chose to not learn about them.

Re: Java for Everything

#12
post #8

I would just add one more thing - I doubt there is another language where you write native apps for Android, iOS and Web sharing 70% of the code: http://arstechnica.com/information-technology/2014/11/how-go...

C#, with Xamarin.

Re: Java for Everything

#13
Java doesn't seem too popular here but used right it can work pretty well, imo.

For instance, I use Java for the backend of a name generator web app. It's astonishingly fast and displays results almost instantaneously despite running a good amount of backend calculations.

This speed became an issue because you'd push the go button and the names would update - but it seemed like nothing happened. So I ended up adding an artificial delay twice (the first time it wasn't enough of a delay).

On the other hand, its structure and methods can at times be frustratingly complex.

Re: Java for Everything

#14
You have to admit that for coders, the joy of writing helps a lot for job satisfaction. I write both Java and Python (for very different applications) and I just always feel like Java makes it hard to write anything elegant almost on purpose. The proliferation of huge frameworks and FactoryFactories clearly doesn't help.

I think you can underestimate the value in actually enjoying writing - I'm just more motivated every day I can write elegant python code. Conversely every day I spend fighting Java for an elegant solution and winding up inevitably with something a bit half-arsed because of some limitation in the language I just feel grumpy.

Re: Java for Everything

#15

> I’m even taking this to an extreme and using Java shell scripts. Having a strong Java background, it is a pleasure to write Groovy for shell scripts. I like the blog post. Whenever I looked into other languages/platforms, I found the "tradeoffs" of Java (as pointed out by the other languages/platforms) to be less important for me. Java/the JVM may be evolving slowly. But it evolves and does it in a reasonable way (…

Why not just use Groovy for everything instead of java ?

Re: Java for Everything

#16
post #3

This is exactly how I feel about Scala now. I really wanted to like Java because of the ecosystem and the JVM, but there ARE a few warts that you will face everywhere - verbosity is one, all the Spring stuff using annotations to wire up dependency injection and AOP and whatnot is another. Scala has the whole JVM ecosystem, static typing and forget about DI/AOP/OOP patterns. Feels like best of both worlds for me.

I find Java much more pleasant without Spring; I much prefer Jetty+Jersey+Guava+Guice. It sounds like that's pretty similar to how you're using Scala.

I think the difference is that stuff is less hastily cobbled together. People use additional libraries because they add value, not because they paper over ugliness and holes of existing libraries.

Scala feels "designed", while Java feels "evolved".

Re: Java for Everything

#17
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 languages or those with type inference.

Verbosity is also a warning sign for lack of expressive power. If you have a pattern like `if (cmd == "run") run();` in multiple places in your codebase, you want to make it so that changing one changes them all. Java won't let you factor this out easily, but worse, it won't catch you when you make a mistake (better languages will either do first-class functions or pattern matching and exhaustiveness checks).

Note that this has nothing to do with static vs. dynamic; verbosity is a problem that can be solved in many ways, but it is a problem. The author also spends a lot of time equating statically typed with fast; well, there are plenty of very fast dynamic languages.

There certainly are reasons to like Java, but these aren't them.

Re: Java for Everything

#19
The headline does not match his conclusion at all, in my opinion. What he's trying to say is that "dynamic scripting languages are slower and more error-prone than compiled, statically typed languages". And to determine whether or not a scripting language is ever a good idea from 3 or 4 examples does not seem like a good idea. E.g. Lua seems to be a pretty good fit for the WoW UI scripting stuff and EA used Python (apparently successfully) for their Sims 4 scripting (sorry for it both being examples of games, those were just the first that came to my mind :D)

Re: Java for Everything

#20
The JVM is not usable for short-living processes such as command-line tools.

Apart from the ecosystem and the language itself, it's often the reference (or only) implementation which makes it unsuitable for a particular job.

Post reply on HN