
"Should I still learn Java?" Answered: Yes. - Garbage
http://beginwithjava.blogspot.com/2011/01/should-i-still-learn-java.html
======
smanek
As someone who rather dislikes Java, I'd still tell others to learn it (but
certainly not as their first or even second language - it teaches too many bad
habits).

The main reason would simply be that a lot of interesting problems require
tools/libs written in Java (Hadoop and family, Lucene, etc) if you want to get
off the ground quickly and efficiently. Eventually, you're going to need to
tweak your tools - so learn Java.

Furthermore, a lot of far better languages run on the JVM and have Java
interop (Clojure, Scala, etc). Strictly speaking you don't have to know Java
to use Clojure. But in practice, it's going to make your life miserable if you
don't know the Java libs reasonably well.

~~~
axod
As someone who programs Java a fair bit, what bad habits do you believe it
teaches?

~~~
smanek
Most of my work these days is Java too, fwiw. But only because I need Lucene
and Hadoop ;-)

The main bad habit is a gross overuse of patterns to compensate for language
stupidity (see: <http://norvig.com/design-patterns/>).

A few particular examples include:

\- Too much global state. You call it a Singleton. I call it a global variable
with a fancy name and a lot more code.

\- You lose the ability to think functionally and dynamically. You can see the
core of the architecture much more clearly if your default thought is 'I want
to pass a function' or 'I want to call a fn based on rutime types.' And then
you should convert that to what's implementable in language X (strategy
pattern and visitor pattern, respectively for Java). Thay way you don't lose
sight of the forest for the trees (and can implement what you're trying to do
without cruft in a good language).

\- Verbosity. It's bad enough that passing a small fn (1 line of code in a
decent language), requires a separate class and 20 lines of code in Java. On
top of that the type system is too weak to actually stop most interesting
errors but just strong enough to be annoying. And for some idiotic reason,
they won't even implement compile time type inference which would save lots of
verbosity and maintain code/bytecode compatibility.

~~~
kbd
I'm personally mad at Doug Cutting for perpetuating Java.

Java is a virus. If Lucene and Hadoop were written in C/C++ you'd be able to
easily use them from basically any language. Because they're written in Java,
it forces the rest of your code to live in Java land as well.

~~~
nickolai
there is a C++ port of Lucene (named CLucene iirc) Not sure if there is such
thing for Hadoop though.

~~~
timr
Yeah, but because it's not the main project, the CLucene port is perpetually
the red-headed stepchild. It runs several versions behind the Lucene trunk,
and therefore, you have to _choose_ to ignore its disadvantages.

...which is a shame, because I agree with the OP that the choice of Java was a
mistake for a large, high-performance system.

------
rb2k_
My main problem with Java isn't the language itself. I think it's a pretty ok
language as far as statically typed ones go.

My problem with Java is the way it's currently being used. E.g. using
annotations to fix things that the language won't let you do elegantly.

There's a lot of horrible overengineering for relatively simple problems (you
don't HAVE to use GOF patterns, they're just a suggestion for a solution. If
you don't have the problem, don't use the solution!).

While there are a few nice libraries (e.g. <http://jsoup.org/> ), even those
usually don't have examples. Especially when you don't know the library yet,
it's wonderful to get a few minimalist examples how to use it. Just compare:

Java: <http://jsoup.org/>

Ruby: <https://github.com/hpricot/hpricot/wiki/> or <http://nokogiri.org/>

While both Ruby HTML parsers have a simple example right on the starting page,
I have to make at least 6-7 targeted clicks for Jsoup.

The same even goes for the core libraries. Just look at Ruby's String class:

<http://www.ruby-doc.org/core/classes/String.html>

And then look at Java's String class:
[http://download.oracle.com/javase/6/docs/api/java/lang/Strin...](http://download.oracle.com/javase/6/docs/api/java/lang/String.html)

In Ruby, almost any method has a small example. The Java doc only has an
example for the constructor...

~~~
sigzero
"My problem with Java is the way it's currently being used"

That is a good point. However, comparing the way things are done in Java and
they way things are done in Ruby is a really bad comparison. Those languages
live in different problem domains and were grown to solve totally different
problems.

~~~
_m_h
What problem domains are you refering to? I can think of some quite similar
ones..

------
yason
Learning Java itself is simple. As a language it doesn't offer particularly
anything that isn't already found in other languages, given you know other
languages.

The biggest effort would be to learn the libraries and you basically can't do
that unless you're regularly writing code that interfaces them. But that you
can do from Clojure or Scala or whatever language that runs on JVM.

~~~
swah
For someone that didn't grew with Java, what is hard is finding your way on
the ecosystem.

If you're a newcomer, and you're going to do a website in Python, you soon
find out Django, which recommends you to use, lets say, Apache and PostgreSQL.
You feel good because you got a sense, immediately, of what you need to know
and install to run a website.

Compare that with Java...

I'm using Clojure with Jetty now, I haven't launched yet, and I'm afraid of
things like application servers and doing everything with enormous amounts of
XML.

------
wlievens
I think a great way to learn programming is to start with the simplest
languages.

Start with Scheme. It doesn't even have proper objects and classes, so you'll
be forced (guided, actually, if you go the SICP route) to implement them
yourselves. This teaches you in an elegant way about essential concepts in
programming, but manages to keep your head clear and unbiased about the many
different ways to do things, whereas a language with a strong fundamental
paradigm (i.e. Java) may bias you forever.

Then learn C. It couldn't be more different from Scheme, but that's a good
thing. It forces you to think about things you thought you didn't reaaly have
to think about - such as memory allocation.

With a solid basis in these two languages, you've covered just about every
paradigm or building block of programming languages you can imagine. Learning
another language then becomes trivial, and for bonus points, you'll be a lot
better programmer at those languages too.

------
rbanffy
Learning Java the language is not a big problem. Preventing a young Java
programmer from becoming an architecture astronaut is. Most Java frameworks I
have played with seem made by and for them (it's like they have been playing
design-pattern bingo) and exposing young programmers to architecture
astronautics may damage them irreversibly. By the time they start talking
about real-life stuff like they are method invocations, they are lost.

------
retube
It's nice to see a positive java posting on HN for a change!

~~~
sjs
Don't worry, we seem to be voting up all the negative comments to balance
things out. :p

------
jinushaun
I can't say I disagree with the author. Even with all its troubles, there's
simply too much legacy Java code to abandon. Much like Cobol and Perl, there
will always be a need for Java programmers to--at the very least--maintain
existing code.

If you're a complete newb, learning Java will also introduce you to the C-like
family of languages. (Although I say everyone should learn C first in order to
appreciate memory management)

~~~
Garbage
> _learning Java will also introduce you to the C-like family of languages_
> Aren't Java and C, different family of languages?

~~~
masklinn
Java is part of the C family of languages, you can draw a pretty straight line
between C++ and most of Java's features (or non-features, or lacks of
features).

~~~
uriel
Many C programmers would argue that C++ does not belong to the C family of
languages.

------
PaddyCorry
Nice article. Good to see a positive Java piece.

I'm formerly a COBOL developer, now working with Java. Did anyone else think
that his main argument for learning Java could also work for learning COBOL?
(substitute COBOL for Java in the quote below)

<quote> It's not going to go away any time soon. There's too much momentum.
There's no need to worry. Ever since the launch of Java I've heard that it's
going to be gone or unusable tomorrow. History shows that just doesn't happen
to popular programming languages.

If you learn Java now, you may still be using it 20 years from now. Or 30.
</quote>

~~~
rbanffy
Java _is_ the COBOL of the 21st century. It's every bit as elegant and
exciting.

------
axiak
Like others here have said, my main issue with Java is not the Java language
itself, but rather with the culture of overcomplexity. As an example, every
web framework has the issue of abstracting pieces of templates in a consistent
manner. Django solved this by writing their own (simple) template language
that supports template inheritance.

The java ecosystem seems to have solved this with Sitemesh, a library that
implicitly decorates xhtml for you, based on another XML configuration.

I see a few things wrong with this approach. For one, it presupposes all of
this nice template work is only ever going to be needed for xml/html. Need to
send a text email? Need to make a latex document? Second, it's entirely
implicit. This is a common theme with java libraries-- if the usual task is
too verbose, usually implicit is the solution. I don't think there's a good
reason Java can't be concise and explicit. It just isn't the thing to do.

~~~
regularfry
Your point is absolutely correct, but I think your example is a little unfair.
There are a ton of template libraries that handle inheritance or code sharing
in both Python and Java, some restricted to XML, others freeform. Saying that
any one on either side has "solved" it ignores the others that have approached
the problem from another direction.

For my money, a better example is the comparison between
<http://www.oracle.com/technetwork/java/index-jsp-135475.html> and
<http://www.python.org/dev/peps/pep-0333/>. Or
<http://rack.rubyforge.org/doc/SPEC.html>, for that matter.

------
kls
While I agree with the authors summation, Java will be here forever and a day,
the real question one has to ask one's self is will Java continue to receive
the developer mind-share in the future? this generally translates to all the
cool problems are being worked in the mind-share language.

The second question is will Oracle further drive away developer mind-share?

I think the answer to both of those are self-evident and when analyzed in that
light learning Java looks a lot like learning COBOL around the time Java hit
1.2. The cool stuff was happening over in Java which was now stable enough to
take off.

I would say the big difference at this juncture is there is no clearly evident
replacement at this point. As their was with Java and COBOL, but I do believe
the mind-share shift has happened and we are all looking for the next king
amount the court.

------
fierarul
I would say learn Java not because there is a lot of existing Java code (using
legacy code as the main argument is a bit presumptuous) but because the JVM is
a versatile and powerful foundation for your code: profiling, debugging, hot
class-swapping, monitoring are really well done.

Then there's the ton of libraries for everything and good tooling.

Of course, the language itself might be a bit too verbose for some people but
I'd rather take Java and the JVM then another language where I'm missing some
of this.

I guess most people don't differentiate Java the language from the Java
Virtual Machine and that's a shame. I could be doing JRuby on the JVM and be
happy then drop into Java for some optimized code. Thus, Java just happens to
be the "C" programming language of the JVM.

------
johnayres
Might be worth checking out Kenya (a subset of Java for beginners, comes with
a nice IDE)

<http://www.doc.ic.ac.uk/kenya/>

~~~
RodgerTheGreat
After a brief skim, it reminds me of Processing. (<http://www.processing.org>)

------
lelele
You should always understand the programming language your platform of choice
is built upon. That means Java if you are going to use the JVM in some way,
just like it means C if you are going to develop native applications on
Windows or Linux.

I have always been astonished at VB6 programmers which ignored what a Variant
was, when they were using such datatype all the time.

------
axod
Completely agree. I'll be teaching my kids Java first, if they want to learn
programming.

~~~
nailer
My kids, like their dad, won't have the patience to create a singleton main
object, with a print method, just to run "print 'hello world'".

~~~
axod

      public static void main(String[] a) { System.out.println("Hello world");}
    

Yeah you're right. That's an insane amount of typing which would take any kid
hours.

I had to muster up all of my patience just to type all that code out. You're
right! Java is so verbose!

Your "argument" if you can call it that, is like people saying lisp is crap
because it uses too many brackets.

~~~
jpr
You forgot the

    
    
        class foo { ... }
    

And that it has to be in a name called foo.java. And that you have to compile
it and run it with

    
    
        java foo 
    

instead of simply

    
    
        ./foo
    

And that startup time of JVM is orders of magnitude worse than pretty much
anything else.

~~~
St-Clock
"And that startup time of JVM is orders of magnitude worse than pretty much
anything else."

Sure, let's throw out of the window all the optimizations the VM can do at
runtime because it takes a whole second to start the VM.

And you need to actually compile the source file before executing it!

Those server applications should all be written in bash because it's
instantaneous!

Kidding aside, one prof at my university once told me that she wished students
should still have to compile and wait for a program to start. When there is
such a delay, it pays to read your code and try to understand it before
running it (as opposed to run-and-see-what-happens).

