Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java for Everything

teamten.com

Post reply on HN
Print view View original

71–80 of 344 posts

Re: Java for Everything

#71

Post by larrys »

Having literally deciding to learn java last week for no particular purpose other than having enough understanding to be able to comprehend our software (which is written primarily in java) and prevent brain deterioration, I'm encouraged by the fact that the comments in this thread (so far) don't appear to be very negative (like when reading about php).

While I did buy a book, I wonder if anyone has any suggestions on a good java beginner's book assuming someone has "prosumer" programming knowledge (shell programming, some perl, some php, sysadmin skills and so on). Suggestions?

Re: Java for Everything

#72

Post by iolsantr »

lkesteloot wrote: post #40

It's not so much that Java is great at everything. It's more like it doesn't suck at anything. Every other language has, somewhere, a deal-breaker for some particular use. I've not found one for Java. And Java's biggest downside, frankly, is that it hasn't attracted fresh young talent in a while, so it doesn't have really hot frameworks and libraries.

Java's start up time makes it pretty crappy for command line utilities.

Re: Java for Everything

#73

Post by frowaway001 »

pjmlp wrote: post #57
frowaway001 wrote: post #44

Earlier quoted context omitted.

How is this related to the topic?

That even though Scala is better designed than Java, without Java's cruft earned through evolution, most companies will keep on searching for Java developer skills.

We were discussing quality, not popularity.

Re: Java for Everything

#74

Post by zwetan »

I completely buy the idea "write everything in one language", even if I do it with a different language for completely different reasons.

In general I think "use the best tool/language for the job" and anyway any tool/language will have pros and cons, nothing is perfect.

My context is I was a big ECMAScript fan, then I moved to use something called ActionScript 3.0 and there I just found the "right balance" between verbosity, correctness, speed, etc.

That's the work part, I use AS3 and AIR to build mobile app for iOS/Android.

Then there is the hobby part, in 2006 Adobe open sourced their ActionScript Virtual Machine (AVM2), I started to work on it (OSS project RedTamarin) in 2008 because I had this silly idea "it would be fun to run AS3 on the command line".

So, few months ago, with a not too bad release of this RedTamarin project, in the spirit of "use your own dog food" and trying to push the limit of what can be done with this open source project, I kind of decided to use only AS3 for all development, either work or home.

I don't do that because I think it is better or faster, but mainly to see how much I can reuse in code and logic, and if ultimately it make things easier for me (as any dev I'm lazy).

The result is quite interesting, so far I can run AS3 in shell scripts, as server side CGI, as command line tool, and tons of different use case I would have not necessarily explored if I didn't forced myself to use the same language for everything.

My point here is the same way you can learn a different programming language every few months/years to learn new stuff, there is also a value of forcing yourself to use only one programming language for everything.

In my case it forced me to explore some context deeper instead of taking them for granted, sure some ppl could say you waste your time because you're reinventing the wheel, but I would argue you learn a lot more when you try to know all the little details that make a wheel works :).

Re: Java for Everything

#75

Post by Xorlev »

rcarmo wrote: 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 productive, but once you are you can move quickly. Using Java 8 doesn't hurt either, streams are pretty decent.

Re: Java for Everything

#76

Post by frowaway001 »

minthd wrote: post #65
lmm wrote: 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.

Why would you ever _not_ want typechecking?

Re: Java for Everything

#77

Post by bluedevil2k »

CSDude wrote: post #10

I cannot keep my sanity when I use dynamic languages in fairly big projects. I just cannot organize my code and all the functionality good. So, I looked at the options at Java and most of them looked either very complicated(Spring) or insufficient. I am developing a very simple framework, insipred from Sparkjava and Play Framework: https://github.com/mustafaakin/WebOM It basically maps either HTTP requests or Websock…

I'm starting to put together my own Java web framework to make things easier to get started quickly and borrowing ( heavily) from other language frameworks. https://github.com/bluedevil2k/Jiffy

Re: Java for Everything

#78

Post by KajMagnus »

one-more-minute wrote: post #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 langu…

In the strongly typed language Scala you get the same benefits as in the duck type languages, and even better :-) You can do:

  val usersById = HashMap[UserId, User]()
if elsewhere you have defined: `type UserId = String`. This is very readable I think :-) And changing the type of UserId is done in one place only.

Re: Java for Everything

#79

Post by pimlottc »

one-more-minute wrote: post #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 langu…

> 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.

A sweeping change like that is hard in Java, but it's nearly impossible in Python. That is, unless you're willing throw up your hands and assume your new duck looks enough like the old one, and cross your fingers that you don't find out in production one day. With a modern IDE like Eclipse, it's a fairly trivial matter to find all references to the class, navigate call hierarchies and make the necessary changes to adapt to the change in type. In a sizable Python program, good luck. You're pretty much forced to rely on string searches - hope you picked a distinctive function name - or interactive debugging. Ease of refactoring is a huge win for static types IMHO.

Re: Java for Everything

#80

Post by SixSigma »

one-more-minute wrote: post #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 langu…

That's why I like Limbo and later Go's implicit typing:

     a := Foo():
a now has whatever type Foo() returns. If you change the definition of Foo then you don't have to cascade your type change through all of your source code.
Post reply on HN