
Hate Java? You’re fighting the wrong battle. - trucious
http://www.javacodegeeks.com/2011/06/hate-java-fight-wrong-battle.html
======
rb2k_
I always had the impression that people that say they 'hate Java', usually
don't hate "Java: the language". Most people that dislike programming in Java
have a negative sentiment because of:

\- the usage of XML (or now: annotations) to configure all of the tiny
parameters that nobody really cares about

\- a class hierarchy in which you have to jump to 20 levels of inheritance to
get to where you want to go

\- that a lot of Java developers aren't able to compile their application
outside of Eclipse

\- that people build in "flexibility" in form of factory methods but at the
same time only have the factory only build the same thing over and over again

\- that setting up java projects is usually an unpleasant experience with way
to much work if you only want the basic functionality because there are no
sane defaults

\- that there is no proper package management for libraries (similar to
something like 'gems' in Ruby)

\- that all of the concepts that the language is missing was 'patched' in
using reflection, injection and annotations

\- that the language just seems stuck (for how long did the Java community
talk about Lambdas by now?)

\- that most Java libraries don't seem to be able to provide a simple example
(compare to ruby, examples on the front page: nokogiri.org, sinatrarb.com)

~~~
spullara
Java is so popular, easy to learn and use that there are tons of terrible
frameworks and bad programmers in the community. Rebel against it all you want
but in the hands of great developer you can get pretty amazing software
written in Java like Hadoop, HBase, Lucene, Cassandra, etc. Java is the
assembly language of the JVM and since most of the cooler new languages are on
the JVM (and written in Java often) it will likely remain as the way to eek
the best performance out of your applications and likely has the library you
need to get your job done.

As for your points in here. Most of them I can respond with "don't do that".

~~~
jshen
I don't think those are examples of great software. They are very useful, and
many fill a niche that needed filled, but they aren't great software IMO.
Hadoop is a very leaky abstraction to give one example. I've seen it crash
frequently because people used wild cards for their input and the job tracker
would run out of heap and crash.

~~~
currywurst
Hadoop is a leaky abstraction because it crashes ? Does not compute!

I'm not very familiar with the others, but Lucene is really an example of
_great_ software. In a few lines, it makes you feel as if you can build a
Google by yourself !

~~~
jshen
"Hadoop is a leaky abstraction because it crashes ? Does not compute!"

Hadoop is an abstraction over a distributed file system, that allows
programmers to crunch large amounts of data using map reduce.

It leaks in the sense that you have to think about implementation details of
the job tracker or you will crash it. That's a leak, right?

------
knowtheory
Oddly missing the point for an article about missing the point.

Either you care about the future and prestige of your platform, or you don't
(COBOL).

If you do care about the prestige of the JVM, the future is still definitely
awesome. Scala, Clojure, JRuby and all of the other wonderful languages
provide a common base for interoperability. That's pretty sweet.

Java the language, as a secure place to get a job is entirely separate from
that. Making bank (ha) off of other people's past poor technology choices
isn't a future for your tools. It may be an economic opportunity, but it's not
a future.

And if all you care about is having a job and writing lines of code, sure,
legacy code base work is fine. But some of us care about more.

~~~
rch
I certainly identify with your point, but I actually had the opposite reaction
to this article; particularly the second half.

I started my career working on 'serious' software, then switched to web
applications for a few years, and have recently settled into building multi-
faceted, research-oriented systems -- and throughout the entire experience, I
have consistently found myself having to apologize for the hype and hyperbole
surrounding the many of the more modern technologies that I've wanted to work
with.

Have a look at the HDF5 libraries... notice the Fortran support? That is a
Huge positive for me, even though I hope to never write another line of
Fortran in my life. Sometimes there is no 'selling' new tech to a CIO; it just
needs to both appear and actually be absolutely solid (for lack of a better
word).

Incidentally, I don't think this is a poorly titled article at all -- the
author was being ironic, and will probably be rewarded with a 10x spike in
traffic from people looking for talking points to take to their next Rails
meetup... that's actually pretty funny.

~~~
knowtheory
Right but there's a difference between hype and experimentation with new tools
and methodologies.

Cargo-culting is never a good idea. But to say that new and better techniques
have not come out of (or been popularized by) new movements in software and
business is simply false.

The stodginess and perhaps arrogance of academic and deeper research posts are
just as obnoxious and hobbling as novelty-chasing unprincipled startup
entrepreneur.

We should pick technologies because they're the right choice for the tasks
we're trying to accomplish. Sometimes that requires reaching for tried and
true technologies (POSIX ftw after all), but sometimes new technologies really
do change the world, and we should do our best to encourage that.

Lastly, it's really just not true that all press is good press. You can gloss
over occasional bad press with a much larger weight of good press, or
converting a lot of bad press into good press with a small group of people
(Palin's "Lamestream Media"), but bad press is just bad press.

Being known for starting flamewars w/o additional contributions to the
community pretty quickly marks you as a troll.

~~~
rch
My concern, one that I believe I share with the author, is that the zero-sum
tenor of tech-community discourse is overshadowing the more fundamental
advances (and setbacks) that we could be focused on. And the attitudes of what
seems to be a generation of edit-line/update-browser developers is only making
it that much more difficult to drag those advances into established
industries.

I am genuinely disappointed with the present state of affairs, and therefore
more willing to wade through an ocean of arrogance to find some intellectual
merit.

There's so much to do...

~~~
knowtheory
This sounds like redirection to me.

I've just said that i believe that we should be using technology based on its
merits. I think that is a separate issue from either whether new technology is
always good/better than existing technologies, or whether we need to continue
to support and encourage the development of new technologies (meh to the
former, a definite yes to the latter).

Established industries on the other hand, need to get over themselves and
actually track how new technologies can change and improve their businesses or
fields, and I think that, yes, there's a danger of them getting snookered by
glad-handing shysters just looking to sell them the hot new thing, but again,
this is why it's so critical to have a solid understanding of technological
change.

you don't have to wade through an ocean of crap technologies, if you have more
finely honed crap detection skills. For example, Coffeescript is a solid and
well thought out technology built on top of existing javascript semantics. I
can tell almost immediately that it's a sensible and minimalist technology,
developed with solid principles, and robust community support. Technologies
like Objective-J/Cappuccino on the other hand, do not give me that sense.
Sproutcore, up until recently, also seemed like a bloated technology, with a
good core idea, but which had become overgrown and lost in it's subsequent
iterations.

I am not a long-time Javascript developer, but, i have tastes and aesthetics
about what i think is important in a development platform, and the sorts of
qualities good ones should have. And the further I develop my javascript
chops, the more confident i feel in my assessment.

~~~
rch
It's more of an antecedent-consequent relationship than redirection, in my
opinion.

Anyway, while your examples are instructive (I hadn't even heard of the latter
three), they get right to the heart of my complaint: I simply don't worry
about how to write individual web applications (though I wish some people
would think about it a bit more... cough - quora - cough).

My immediate response to something like coffeescript, though, is to wonder
what about how the grammar is defined. Could they do the same thing with antlr
or xtext? are they already? how about python-lepl? and, finally, what are the
core heuristics that all developers can take from a discussion of the above?
I'm not at all interested in thinking about their 'square' function example -
I'm sure it's plenty useful in some context.

Worry about what cognitively-tiny (that's not a pejorative - mk is powerful
because it's tiny) framework to adopt, and reinforcement of one's choice
through pervasive 'messaging' within the developer community, seem to go hand-
in-hand. Conversely, since I don't worry about the former, I don't generally
take part in the latter.

...

By the way - all this has started to sound overly stern to me - I'm really
just sitting on my porch, doing a little good natured ranting about things I
can't control.

Cheers :)

~~~
knowtheory
Actually, yeah, Coffeescript is actually bootstrapped using Jison (a
javascript implementation of Bison), and implemented in Coffeescript! :)

I should note that i think what's being done with Sproutcore now is pretty
awesome. People like Yehuda Katz have done a good job of turning Sproutcore
into a tech that has a solid conceptual foundation, and is aiming for ease of
use for developing non-trivial javascript apps.

So, what _do_ you worry about (and i mean that in a non-stern, genuinely
curious way)? Web applications really are going to be the solid basis upon
which a lot of future technology is built. A lot of pretty complex technology
is going to be written in javascript (or things that compile to javascript).
It really is a necessary step to see how to make javascript development more
efficient and principled, so that there is a common basis for getting stuff
done.

~~~
rch
Yeah- You've definitely convinced me that I need to take a closer look at
coffeescript. But I'd only be really interested if it could take something
approaching OWLlink Functional syntax and generate code in any popular
language, with my main concern being the ease of controlling exactly what is
generated. Not because I think OWL Functional is 'better' than JS; I just
think flexibility is an important criteria for judging the quality of tools
along these lines.

I suppose I do worry about a few detail-ish things: the future of the
disco/ddfs project now that Nokia is on the ropes... how to more closely
integrate CLIPS rules with redis... if it is ok to let webmachine sit between
nginx and an osgi process, or if I need to back-burner erlang for a while...

Don't get me wrong, I've written plenty of JS and expect to write plenty more,
with or without node. But I'm also curious if I could ship a native component
for chrome that dynamically loads a Xen vm that contains a 'heavy'
application, with the UI written in whatever, that renders through an HTML5
canvas (check out the gnome3 html5 demo). I don't worry about it happening
though: that's going to take care of itself. I just hope there are no patents
or licenses to buy that would prevent me from shipping apps that way.

------
kragen
Maybe it's not surprising that a mainframe programmer completely fails to
understand the debate.

His list of four reasons people hate Java completely misses the point. The
real reasons people hate Java are something like this:

1\. It's verbose, providing lots of unnecessary opportunities to add bugs, and
because it's verbose, reading code written in it is slow, so modifying it is
slow. These are constant-factor problems, though, not order-of-growth
problems.

2\. It's early-bound in some important ways, so you're faced with a constant
dilemma between adding even more verbosity, making the code harder to modify,
and losing flexibility, making the code harder to modify.

3\. Although it's quite CPU-efficient, it's very wasteful of memory. (You'd
think a COBOL programmer would appreciate this.)

4\. The tooling around the language imposes enormous overhead. The JVM takes a
second-plus to _start_ ; Eclipse uses hundreds of megabytes of memory, if you
can get it to work at all; you usually want to run your servlet container
behind a reverse proxy; building and deploying a .war file is just orders of
magnitude more pain than hitting "reload" after you update your PHP script.

There's another missing-the-point viewpoint shift here, too. This guy seems to
think that the point of programming is to enable big businesses to continue to
function, like bookkeeping, factory machinery maintenance, and executive team
retreats at fancy hotels. Well, programming does do that. But it's also a
medium of expression, and a competitive advantage for companies doing _new_
things.

Bookkeeping relies on arithmetic, and factory machinery maintenance relies on
paint, but that doesn't mean that Erdos and Picasso were "fighting the wrong
battle" because they failed to apply their talents to helping out poor GM.

------
sqrt17
So, which battle are Java haters fighting?

Java is mostly-ubiquitous and is "good enough" for a number of common tasks,
and has good enough structure for mediocre programmers working on important-
but-uninteresting problems. As a result (and the blog author says this), there
is enough hate-worthy Java code there, just as there used to be enough hate-
worthy C and C++ code around, and there probably is enough hate-worthy COBOL
and Ada code around, if you know where to look.

It's worth noting that the relationship between C++ and Java switched around
in the last 12 years or so - before, C++ was the method of choice to write
segfaulting bug-ridden Windows applications (MFC anyone?), whereas Java was a
rather slow (as in, non-JIT-ted) language that was up and coming and was
interesting because it combined familiar C-like syntax with garbage
collection.

Fast forward, and we have not only smart pointers (which ease many headaches
of non-garbage-collected C++) but also template metaprogramming which really
took off and makes C++ much more palatable to the one-man-army approach (i.e.,
one smart guy who does work that would take several mediocre programmers
otherwise). Java has also evolved - Java 1.2's List/Map/Set are much nicer
than the old collections, and Java 1.5's generics help avoid much of the old
ugliness - but it carefully avoids any constructs that would make it more
useful for one-man-army stuff - where Rubyists and Pythonistas are monkey-
patching metaclass decorators, the Java world has one or two libraries that do
bytecode generation to do something useful, but nothing more magic.

People who hate Java are really out against the programmer-as-a-fungible-
resource way of living where programming is treated like shoveling dirt
instead of a creative activity. Programming is both - perspiration and
inspiration - and some people will be allowed to chose their tools (Java or
not) whereas other people are not or have to fight for it.

~~~
Hisoka
I definitely agree with your sentiment. If you're working on your own personal
projects/startup, most of the time you aren't gonna choose Java, but another
language whether it be Python, Ruby, etc. But if you're in a corporation, you
don't have the flexibility and freedom to choose what you want to work for.
This association of corporate life with Java contributes to people's hatred of
using Java. I bet if corporations started using Python, more and more people
would hate Python as well if they had to use it on a daily basis for boring,
business processes

When I actually used Java in one of my first personal projects, i found it
very fun to use. But when I had to use it in my first job, my interest and
enthusiasm waned.

~~~
rbanffy
> This association of corporate life with Java contributes to people's hatred
> of using Java.

This association happens because the wrong people are defining which
technologies will be used. When a manager makes manager-ish decisions, Java is
what you get. Or Windows and .NET.

> I bet if corporations started using Python, more and more people would hate
> Python

Won't happen because

a) Python is actually good b) The same people who make manager-ish decisions
won't pick Python.

> When I actually used Java in one of my first personal projects,

I too had a more optimistic opinion of Java when I started playing with it.
But then I remembered how it felt to program with Smalltalk (I learned OOP
with it, later played with Actor on Windows). Then I met Python, and Zope and
realized web development doesn't need to suck.

The company I work for maintains several Java applications and a couple PHP
and Django ones. The difference of productivity from the Java projects and the
Django ones is absolutely shocking.

~~~
andrewflnr
You really don't think Python is reaching the point where a manager type would
be comfortable with it? It's mature, it has tons of libraries, it's used in
all kinds of successful projects. I really don't know. It just doesn't seem
anything like a high-risk choice to me.

~~~
rbanffy
No Python vendor will wine-and-dine the pointy-haired-manager, nor pay a trip
to a conference.

Oracle will.

~~~
andrewflnr
Good point.

------
grimlck
I like to compare hating java to hating SUVs - they may be used
inappropriately most of the time, but there are scenarios where they are the
best tool.

In the enterprise, you need a language that can support \- multi-million line
code bases \- a development team of dozens or even hundreds of programmers \-
a software project that lasts years \- a team that changes over time \- a team
that isn't just rockstar programmers (try hiring dozens of rockstar
programmers at once if you are not google, facebook, and you aren't doing
something perceived to be 'sexy')

I think java and C# are the best languages that meet those criteria today (and
if you don't want to be married to MS, then you are left with Java).

I think dynamically typed languages are not appropriateness for such a
scenario.

However, HN is a startup-oriented site, and those certainly are not the
criteria you need to meet in a startup.

------
badmash69
I never thought I would defend Cobol but I have found that Greenscreen
terminal based programs written in Cobol and Powerhouse are amazingly fast
compared to equivalent web based applications. (I speak from my experience in
Financial industry. your experience may vary). Scalability is a mater of
throwing more IBM hardware at it and its not very expensive to operate. The
IBM Iseries is something unlike anything I had ever seen in terms of
scalability. Just saying that your new fancy language of choice is not
necessarily better than Cobol.

~~~
Peaker
The performance of the resulting program is one of many variables. You can
almost always get better performance by losing out on other variables.

Measuring just one variable in just a few anecdotes is unlikely to give you a
representative measure of a language.

COBOL is a language designed in an era where _syntax_ was thought to be the
difficult part of programming.

~~~
wickedchicken
> COBOL is a language designed in an era where _syntax_ was thought to be the
> difficult part of programming.

This is a very striking comment and one that reshapes my criticism of
languages in general. Often one says that COBOL "feels old" but it's difficult
to pinpoint _why_ ; I think your comment gets to the heart of the matter and
explains why languages such as lisp or smalltalk retain influence today. The
problem they attempt to tackle is still difficult in modern programming
environments, but the problem COBOL was designed to remedy has paled in
comparison. Thus, it's similar to how AOL used to be the main method people
used to access the internet -- e-mail, IRC, and the general web was difficult
enough for a novice to master that a service like AOL _was_ needed. Now the
web has matured enough that the problem AOL was trying to solve has
disappeared -- leaving it outdated by substance rather than outdated by style.

------
equalarrow
I don't hate Java, per se. I did a lot of Java coding from '96-'06. I went
with it as it became the king of the 'enterprise'. What I realized later
though is that you can't use Java very efficiently in a small shop (one or two
guys).

Nowadays there are other languages and toolkits out there that bring me better
joy on a daily basis. C-based languages are not the issue here (I love
Objective-C), it's the frameworks and patterns that soured my interest in
Java. IoC, dependency injection, xml config this, facade that - for today's
speed of 'innovation' and time to market, the Java universe for development
can be too big and slow.

Most of the people I've run into post-'06 don't use Java anymore. These are
usually small startups (as I don't do enterprise anymore) and the names that
always come out are Python, Php, Ruby/Rails, Obj-C, JS, and even Scala. In my
mind this is telling of where things are going, just like the early days of
Java when people still used Perl and C++ for web. I think Java's continual
evolution (or at least usage of the JVM) into things like Scala and Clojure
are good things. But it's glory days being at the forefront of web development
are behind it.

Ultimately I think this as fine as every dog has its day. Someone will come up
with the next greatest thing that everyone will flock to. But like all the
other names I've mentioned, Java will be around in many shapes and forms
because, like Cobol, some businesses and users will still need it.

------
zdw
TL;DR (as I see it): Complaining about Java as a language is pointless, as all
of the "new hotness" languages out there don't slay the old dragons of ancient
business system languages like COBOL, which is where the author thinks people
should be spending their time.

------
lordlarm
So if I understand this article correctly I should not hate Java, because
there are languages out there which are worse?

I'm sorry that just don't cut it for me, and I'm capable to dislike both COBOL
and Java.

------
aerique
I don't specifically hate Java the language, although I'm not enamoured with
it either. I do hate the whole culture / attitude and baggage that comes with
the language if you have to use it in an enterprise environment. That same
culture that warped XML from something moderately useful into a horrible joke.
Same goes for SOAP, UML and basically all things 'enterprise'.

 _edit:_ I gave up on the whole thing when I had to use comments to configure
part of a build process. (xdoclet & jboss? ... I can't quite remember)

~~~
Corrado
Yes, we were talking about this specific thing at work the other day. How come
all non-trivial Java programs end up a mass of Factory and Implementation
classes?! Several of the systems I support even weave in Spring, which while
helping in some ways, completely obliterates readability. :(

~~~
mattgreenrocks
My theory is that the language's _lack_ of complexity bothers 'high-end' Java
devs at a subconscious level, so they think they have to invent it in order to
seem relevant to the larger community. Another idea is they may believe
elegance is a function of using powerful language constructs, rather than a
function of minimalism.

I see the same problems in Ruby sometimes: metaprogramming used without a
compelling need. Luckily it isn't as much of a PITA because nobody thinks its
OK to program via XML files anymore.

~~~
uriel
Java is way more complex than it should be, specially after badly botched
features like generics were added.

------
Jeema3000
I wonder... how many programmers have been exposed to enough different problem
domains and languages to really make an accurate judgement on what is "the
best programming language", if any such thing even exists (which I doubt).

Maybe the reason you hate some feature of a language because you've never been
exposed to a problem domain where that feature would be required.

I mean how many of us can honestly say that we are experts in more than one or
maybe two domains: i.e. web development, desktop/native apps, embedded
systems, systems programming, 3d programming, mainframe programming, massive
enterprise team projects, small one-person projects, in-between projects,
etc...?

I say he who is versed in all of these cast the first stone... :)

~~~
anonymoushn
I don't hate the features that are there, I hate the features that are
missing. Most languages I know let you express vector<int> without an external
library, but the libraries that ship with this language only let you express
vector<"oh wait let me call that function/allocate a new object for you">,
which is significantly different. It doesn't provide coroutines or
continuations, while even C++ does.

------
wallflower
Some of us do Java for a day job and feeling a lack of creative expression at
work - explore our creative side with other frameworks. Or even pottery
classes.

The world doesn't have to be black and white. Why do we geeks try to make
everything 0 and 1? The world is not binary. You can "sell out" yourself -
work doesn't necessarily make you happy but it may give you means to do
something that makes you happy.

I've been working with Java since 1999 and I'm amazed - it won. From applets
to EJB hype to Struts and to now Spring and Scala and Android. Game over -
they've become a Lingua Franca. There is always room for other players but
Java is so firmly entrenched in Fortune 500 code bases it will never ever go
away..

------
wickedchicken
Since there are many languages that now target the JVM, I guess my main
distrust should be targeted towards that instead of the language itself. Can
someone explain to me what the advantage of running on the JVM is compared to
something else (including native code generation)? From what I understand it
provides: native tuned GC, stable and tuned JIT, and a class/module mechanism
revolving around reusable code libraries (e.g., you could drop in a library
written 6 years ago and have it 'just work,' when with C everything needs
constantly shifting header files). I haven't used the JVM seriously in years,
but I always got the feeling that around these core strengths were layers and
layers of bureaucracy -- XML 'makefiles,' a stack-based VM that must
inefficiently be translated to a register machine, and the feeling that
everything is overengineered to the point that a simple "hello world" takes up
gargantuan amounts of time and resources compares to things like Chicken
Scheme or Go which have roughly the same features. Would anyone who uses JVM-
based languages care to address these fears, I'm honestly curious if my
hesitation is well-founded.

~~~
justincormack
The JVM allows commercial software to be usefully cross platform. If you are
working with open source or scripting/jitted/non compiled languages this
doesnt matter. Compiled C or C++ code was hard to get for the right
architecture and work with.

But it makes no difference for open source, hence the Linux coders disdain for
VM languages, and it makes no sense with Python or Ruby where you interpret
the source. And native JIT makes more sense now, the JVM being a bad language
to write a JIT compiler for, as it loses a lot of important information.

~~~
MrMan
You have packed a lot of misinformation into one post. Cross platform does not
matter for open source? People who use Linux also have a disdain for VMs like
those that run Erlang, Python, Java, Scala, Clojure, etc? The JVM is probably
the foremost example of a VM that uses JIT-ing really really well to achieve
near-native speeds for a VM language.

~~~
uriel
Of all the VMs you mention, the JVM is by far the least portable of all.

------
wvh
Large corporations have the money to run huge applications on serious systems,
and might get a slight performance benefit from running Java. Try running it
on virtual servers for small web applications though... It's painful. Compared
to Python, Ruby, Perl and PHP it eats resources like crazy. Developing and
deploying Java apps feels slow and like being stuck in the stone age, unless
of course one starts building a large automated infrastructure with continuous
integration servers and repository managers... leading back to my first point:
complex, heavy and hence expensive infrastructure. Debugging large web
applications is worse than any other common programming language for the web.
In all honesty, I've never written any serious software in that language – I
know more about administration of systems running Java – so I'm not getting
into a discussion about the language in se, but it seems very hard to get a
clean transparent architecture in larger applications without drowning in
hundreds of small little classes littered throughout. While there is a lot of
badly written software out there in any language, it's always the Java
programmers around me that complain most about trying to decipher how a
complex Java application actually works and which code and classes hook into
others.

Then, there's the Sun/Oracle thing... While Sun was still pretty respected,
being associated with Oracle feels like a wolf trying to befriend a chicken.
Especially coming from the open-source perspective, I'd rather not deal with
them. If design-by-committee wasn't bad enough, the control of a company like
Oracle should set off some alarms...

------
przemelek
I don't get this whole "Java sucks movement". You don't like Java? Cool, use
something else. Your boss not let you do it? Convince him or her. Create
prototype of what they want from you using your language and use it as a proof
that your language of choice is a proper tool. If you cannot, and your bosses
decided to use Java it isn't problem with Java, but with you, or your company,
so you need to work on you, or change a job.

I like Java and JavaScript, I don't like too much C# and Delphi (maybe because
of this that I used those in my worst job ever? ;-)). But I don't think that
C# and Delphi are bad programming languages used by idiots.... I don't think
so, because I know some super programmers using those languages, and I know
also some very bad programmers using for example Ruby. In short good
programmer will use any language and will create cool software, bad programmer
may use the best language ever and will create something what sucks ;-)

And this that companies decide to stay with Java or even COBOL have sense, to
rewrite code from one language to other you need people who knows both
languages, and are in those two languages really good.

------
anand21
#Using Java for serious jobs is like trying to take the skin off a rice
pudding wearing boxing gloves. -- Tel Hudson

#Of all the great programmers I can think of, I know of only one who would
voluntarily program in Java. And of all the great programmers I can think of
who don't work for Sun, on Java, I know of zero. -- Paul Graham

#Java is the most distressing thing to happen to computing since MS-DOS. --
Alan Kay

#Java is, in many ways, C++--. -- Michael Feldman

#C++ is history repeated as tragedy. Java is history repeated as farce. --
Scott McKay

#Arguing that Java is better than C++ is like arguing that grasshoppers taste
better than tree bark. -- Thant Tessman

#Like the creators of sitcoms or junk food or package tours, Java's designers
were consciously designing a product for people not as smart as them. -- Paul
Graham

#There are undoubtedly a lot of very intelligent people writing Java, better
programmers than I will ever be. I just wish I knew why. -- Steve Holden

#The more of an IT flavor the job descriptions had, the less dangerous was the
company. The safest kind were the ones that wanted Oracle experience. You
never had to worry about those. You were also safe if they said they wanted
C++ or Java developers. If they wanted Perl or Python programmers, that would
be a bit frightening. If I had ever seen a job posting looking for Lisp
hackers, I would have been really worried. -- Paul Graham

#In the best possible scenario Java will end up mostly like Eiffel but with
extra warts because of insufficiently thoughtful early design. -- Matthew B
Kennel

#The only thing going for java is that it's consuming trademark namespace. --
Boyd Roberts

#Java is the SUV of programming tools. A project done in Java will cost 5
times as much, take twice as long, and be harder to maintain than a project
done in a scripting language such as PHP or Perl. ... But the programmers and
managers using Java will feel good about themselves because they are using a
tool that, in theory, has a lot of power for handling problems of tremendous
complexity. Just like the suburbanite who drives his SUV to the 7-11 on a
paved road but feels good because in theory he could climb a 45-degree dirt
slope. -- Greenspun, Philip

#JAVA truly is the great equalizing software. It has reduced all computers to
mediocrity and buggyness. - NASA's J-Track web site

#C and Java are different in the non-excitability department, though. With C,
you don't get excited about it like you don't get excited about a good vintage
wine, but with Java, you don't get excited about it like you don't get excited
about taking out the garbage. -- Lamont Cranston (aka Jorden Mauro)

#Java is about as fun as an evening with 300 hornets in a 5m^2 room --
andguent

#If Java had true garbage collection, most programs would delete themselves
upon execution. -- Robert Sewell

Java: write once, run away! -- Cinap Lenrek

Java is a DSL to transform big XML documents into long exception stack traces.
-- Scott Bellware

#The definition of Hell is working with dates in Java, JDBC, and Oracle. Every
single one of them screw it up. – Dick Wall CommunityOne 2007: Lunch with the
Java Posse

#Java is like a variant of the game of Tetris in which none of the pieces can
fill gaps created by the other pieces, so all you can do is pile them up
endlessly. -- Steve Yegge (2007, Codes Worst Enemy)

#Whenever I write code in Java I feel like I'm filling out endless forms in
triplicate. -- Joe Marshall (aka jrm)

Source <http://harmful.cat-v.org/software/java>

~~~
kjetil
That's a lot of quotes, mostly by people I've never heard of (PG, Kay,
Greenspun and Yegge excepted). I'm not saying there's no truth to them, but
they're mostly fluff and little content.

Some notes: I don't know why PG can't, but I can certainly name a dozen great
programmers who mostly work in Java. Greenspun recommends that instead of
Java, you use (wait for it...) .NET.

The Dick Wall comment I have no issue with :-)

~~~
anand21
>mostly by people I've never heard of

well they make sense :)

------
BruceForth
Blub programmer telling why you should program in Blub.

~~~
Peaker
Almost everyone is a Blub programmer, including pg who coined the term:

The interesting thing about Blub programmers is that they do not know they are
Blub programmers.

~~~
stcredzero
_The interesting thing about Blub programmers is that they do not know they
are Blub programmers._

Even more interesting: Even those who know about the above phenomenon and make
meta-comments on it are Blub programmers and do not know that they don't know
this. </mega-irony>

~~~
Peaker
I am a Haskell programmer, and aware of the more powerful abstractions
available in Agda and similar languages. So I am aware of my Blubness :-)

But I try to keep up to date with regards to PL technologies, so I think I'm
closer to the top of the contemporary Blub ladder, but I guess any Blub
programmer might think that!

~~~
stcredzero
Darn iPad! That was meant to be </meta-irony>

My Blub is Smalltalk, and I'm proud to claim it as such.

------
jrockway
Spoken like a true code monkey.

Programming is about the joy of creating: thinking, expressing and sharing of
ideas. If your argument in favor of something is, "it's bad, but banks use
it", you've missed the point of programming.

~~~
hvs
I enjoy creating as much as the next guy, but I think the "point of
programming" is to solve problems. And if banks use Java to solve problems,
then that's what you use. If you get the "joy of creating" as you go along,
great, but your employer doesn't require it.

~~~
jrockway
_And if banks use Java to solve problems, then that's what you use._

No, it means you don't work for that bank.

------
onelson
The interesting point in this for me was the idea that Java, or any other
development platform with an "enterprise" sticker slapped on it, will be the
_obvious_ choice for a given problem space simply because it has the sticker.

I've been in the situation several times where technology decisions are made
based on brand. The Java solution is the only one evaluated "just because".

~~~
berntb
>>I've been in the situation several times where technology decisions are made
based on brand

I've personally seen a scripting language been thrown out and everything
rewritten in Java.

After a couple of years they had to go back to scripting languages for a big
part, for productivity. So they would ship sometime... (To minimize
embarrassment, they used a different scripting language. [Edit: Yes, the
second scripting language have almost as much hype as Java...])

~~~
prodigal_erik
We went PHP->Java a couple of years ago, because we'd need thousands of app
servers if we didn't. We recently agreed that when we replace the stuff that
isn't performance-critical, we don't need to take the productivity or morale
hits to do that in Java, but we'll be damned if it's staying in PHP.

~~~
pangram
Did you happen to write/blog anywhere about the scenario and the reasons for
the move from PHP to Java? It would be an interesting case study.

~~~
prodigal_erik
Sadly no, I've chosen not to identify myself so that I can fully speak my
mind. But in short, the PHP 5 interpreter (with APC) was a pig even for a
scripting language, and few builtin client stacks lent themselves to making
parallel requests to different backend services with timeouts in milliseconds.
The rewrite was also an opportunity to jettison technical debt like support
clutter for long-disused features (many forgotten after turnover in
engineering). We only had to tune the GC a little; the gotchas have been
minimizing exception volume (they're still _extremely_ expensive, especially
when stock Tomcat 6 handles certain bogus requests that way) and learning to
avoid certain J2SE features which impose unexpected synchronization (weird
stuff like creating fresh java.util.Calendar instances instead of cloning
one). Nowadays we're moving from servlets towards Netty and async everything
so our cores don't context switch so much.

We don't _like_ Java, but the JVM has met our needs pretty well. I was tempted
to argue for Clojure, but I'm not sure we could have taken the performance or
maintainability hits for discouraging static typing.

------
stcredzero
_Tell me, what do the following have in common?

    
    
        - Paying with a credit card.
        - Going to the emergency room.
        - Adjusting your 401k.
        - Using your insurance card at the dentist.
        - Shopping around for the best car insurance.
        - A BNSF train pulling a Union Pacific coal car.
        - Transferring money between banks.
        - Filling a prescription.
    

All the above industries are billion dollar players in our economy. All of the
above industries write new COBOL and mainframe assembler programs. I’m not
making this up, I work in the last industry, and I’ve interviewed and interned
in the others._

The question to ask is: What are the economic and social forces keeping the
COBOL code base alive? Seeking to supplant a long-surviving language in a
particular niche without first asking this question is a fool's errand.

~~~
froydnj
> The question to ask is: What are the economic and social forces keeping the
> COBOL code base alive?

Do you want to be the person who volunteers to rewrite those codebases into
$HOT_NEW_LANGUAGE (or even $BORING_STABLE_LANGUAGE) and be on the hook for
ensuring that your rewrite _exactly_ replicates the behavior of the old
system? Introducing bugs--or even inadvertently fixing bugs--during the
rewrite is absolutely not allowed.

Let's say, for concreteness, that each one of those tasks above is a multi-
million line codebase. Think about what that would cost, both in person-years
and in monetary terms. (Sure, you can write 10x less code...but half a million
to a million lines of Python is still a _lot_ of Python.) Remember, you
probably have to have a fairly exhaustive specification of how the original
system worked before you embark on the rewrite; just getting that
specification together is likely to be tilting toward person-years of work.

Do you want to be the manager who goes around to talk to all the involved
stakeholders and explains to them why this is a worthwhile use of their
systems, time, and money? ("We'll have an easier time recruiting people to
work on the system," probably doesn't fly; neither does, "$LANGUAGE is
cleaner/faster/more readable.") What do you tell them when they ask about
possible issues during the transition? And so on and so forth.

------
jschrf
I'm working towards an MVP that uses Java (on Android), C#, and JavaScript.
It's interesting comparing and contrasting the languages while using them all
at once.

Java is a workhorse of a language. It's stable, gets the job done, and is
reasonably sane. It's also readable, which in my opinion is one of the most
(if not THE most) important traits of a software product. Readability.
Simplicity.

The problem I have with Java is that I feel like it never evolved to meet its
potential. It feels like C# 1.1 to me.

These days however I think the most interesting programming topic is not Java
vs C++ or Java vs C# or any of these tired old debates.

What's most interesting to me is the notion that dynamic languages are somehow
more productive or superior to strongly typed ones. It seems to be a commonly
held view in the startup scene especially. It just doesn't make sense to me.

------
perlgeek
I don't hate Java as long as I don't have to use it. I don't hate COBOL as
long as I don't have to use it. The same is true for a number of languages
that simply aren't fun to use.

The difference is just that it's more likely that I have to use Java at some
point, compared to COBOL.

------
agentultra
I like the COBOL red-herring. Java can't be that bad because there's still
COBOL! We must fight COBOL...

wait.. that's actually kind of a good idea. Raise your hand if you're a COBOL
developer. Any young COBOL developers trying to break into the field?

~~~
sukuriant
Do you want to make a ton of money writing banking applications?

------
MatthewPhillips
Java is the default language in the best selling phone platform, Android. For
that reason alone it will remain relevant for a long time. I know Android can
run other JVM languages, but until the platform becomes stabilized (meaning
most big security holes are filled, new non-trivial features are rare) there
won't be a push to make non-Java languages a first class citizen.

~~~
justincormack
I think Go will be released for Android next year. Maybe other languages too.
It is a huge legal risk for Android not to have a fallback from Java.

~~~
MatthewPhillips
I love Go, but it is a systems language (a C replacement), not a UI language.
That's not even my opinion, that's how they market it.

~~~
uriel
Actually, Go would be great for GUI programming, precisely because it has a
concurrency model that doesn't suck, and GUIs are almost always concurrent.
Remember that Go's concurrency model is a descendant of CSP which Rob Pike
first used in Squeak, a language designed exclusively for building GUIs:
<http://doc.cat-v.org/bell_labs/squeak/>

------
escanda
A lot of transactional systems are being written in Java already. So it's a
matter of not being worth rewriting the working systems on production why
Cobol is still alive.

Also a point concerning most language wars is that quite a few are initiated
by people with interests on the contender; that is, the language authors,
software vendors, etc.

------
nerd_in_rage
I don't hate the Java language or the JVM.

However, I hate many of the Java APIs, specifically most "JEE" crap, such as
EJB, JMS, most third party ORMs (Hibernate), most Java "web frameworks" (too
numerous to list).

Java IDEs are bloated, slow, and often unstable with extra plugins (Eclipse)

~~~
currywurst
Have you looked at JEE6 ? They've really pared down a lot of the boilerplate
you had to do, and the reference implementation Glassfish is a snappy
customer.

ORMs, i feel, are a misguided adventure, and Java on the desktop (eg IDEs) are
a really easy target. That said, a faster disk and gobs of memory make IDEs
really fly.

------
czDev
There a lot of powerful frameworks in Java that make application development
fun and easy (e.g. Camel, Spring, Hibernate). Java can replicate many of the
popular features of other languages - anonymous functions are duplicated by
single-method interfaces and anonymous inner classes. I say use the best tools
available, and Java has still got to be one of those.

------
norswap
My sentiments : Good : Java has lot of well-documented libraries. Yay. Bad :
Lots of boilerplate code, you can't add flexibility to the langage (not even
with "simple" C macros or closures).

------
northstar
The irony here is that right now the Cobol model is Java's last hope

------
rch
Did anyone see the link to the originally published article?
<http://thecodemechanic.wordpress.com/>

------
tybris
The best language for me is the one I know best.

------
michaelochurch
I'm going to cite Steve Pavlina here:
[http://www.stevepavlina.com/blog/2005/07/how-to-get-
from-a-7...](http://www.stevepavlina.com/blog/2005/07/how-to-get-
from-a-7-to-a-10/)

Some snippets:

 _A 7 seems very close to a 9 or 10, but often a 7 is a local maximum — you
can’t get any higher by continuing to follow the same path that got you to
that 7 in the first place._

 _A 7 is pretty good. At this level you feel generally content. It’s OK, fine,
acceptable, satisfactory._

 _What you’ll find when you leave the comfort of your 7 and go chasing after
that 10 is that your 7 was never a 7. It was only a 3._

Java is the epitome of "7"-ness. It's a decently powerful language that you
can do cool things in if you find a good rock and smash the right things in
the right places. As a language, it's mediocre but so much work has been
poured into it that nothing is _too_ hard to accomplish in it... then again,
very little is easy or fun in the way that Ocaml (once you get it) is easy and
fun.

Java appeals to business types because it seems like the low-risk choice. The
libraries are going to be there, and even if it's hard to be better than a 7.0
programmer in it, mediocrities can easily get up to 3-4, which is seen as
"good enough".

 _You might be able to go from a 6 to a 7 in a week or a month, perhaps even a
day with conscious effort. A few tweaks here and there, and you’ve got it. But
to go from a 7 to an 8 might take a year or two. 7 doesn’t always connect with
8. You might have to take a path like 7-6-4-2-3-4-5-6-5-4-6-7-8 to get there._

This is what switching out of the Java paradigm, into Ocaml or Haskell, is
like. You have to work hard and learn new things before you get to a level of
skill where you can be even a 5, much less an 8 or 9... but it's actually
possible in those languages.

~~~
nostrademons
"This is what switching out of the Java paradigm, into Ocaml or Haskell, is
like."

If you try to do real, production programs in Haskell or Ocaml, you find that
they have a lot of problems too.

I've written some reasonably cool stuff in Haskell (like one of the top
tutorials that people use to learn it). My teammate got his Ph.D under Simon
Peyton Jones and did his doctoral thesis in Haskell. We were talking one day
about what it'd be like to write real production systems in it. His strong
opinion (and my weak opinion) was that it'd be _hellish_ , because of certain
misfeatures like lazyness or the hacked-up record system. All the people that
complain about Java would merely find new things to complain about with
Haskell, other ways in which the language prevents them from getting useful
work done. Instead of whining about verbosity, they'd whine about space leaks.

I find that _people_ who are a 9 or 10 on the expertise scale usually _know_
Haskell, but they don't _program_ in Haskell. Because the causation works the
other way. If you're a good programmer, you'll seek out other languages and
learn them, because it'll make you a better programmer. But if you're a
_great_ programmer, you'll know when not to use stuff you've just learned,
because it'll just make your life harder. Learning Haskell doesn't make you a
great programmer, but great programmers have probably learned Haskell at some
point in their path to greatness.

~~~
neilk
I've been playing around with Haskell recently (actually have been for years,
off and on) and have been thinking about doing a real production system in it
in the near future.

What is going to be so hellish? Space leaks? That doesn't seem like the worst
thing in the world to me. Lots of scripting languages tend to bloat over time
and the usual answer is to kill and restart the process every now and then.
Even Apache does this to its children.

If I have to kill some daemons every now and then, but I get the robustness
that Haskell seems to offer, it sounds like a great tradeoff to me.

I don't think laziness by default is all that useful in practice, but neither
does it seem to be a fatal problem.

I'm not all that impressed with the web platforms for Haskell, but I'm
thinking of doing Haskell in the backend, and Python in the frontend.

So... go ahead, pop my bubble; tell me how I'm being stupid...

~~~
nostrademons
If you're comparing to Python (which is stable but hella slow) or Ruby (which
tends to be both unstable _and_ slow), GHC stacks up pretty well. By
"production systems", I was mostly referring to the sort of things that are
normally written in Java or C++ - Google-scale server farms, or financial
transaction systems.

You really want predictable execution behavior in those systems. You want to
be able to look at a graph of runtime parameters - memory usage, or server
load, or QPS, or 95th percentile latency - and see that it's stable, and not
have surprises like a massive spike that then shows up as user-visible
outages. Because getting paged really, really sucks, and losing money because
your customers can't access the system sucks even more. "Kill and restart the
process every now and then" is not robustness.

If your intention is to play around with some prototypes and see what you can
build, Haskell on the backend and Python on the frontend is a fine choice.
Your biggest issue (other than the learning curve of Haskell) will be finding
libraries that you can leverage, and Haskell has one of the nicest C FFIs out
there. Other than that, here're assorted other little annoyances I've run
into.

1\. Positional data structures (tuples, "naked" [non-record, no accessor]
ADTs, functions with long parameter lists) really suck. You _will_ eventually
want to stick another bit of data in there, and then you have to update all
the usage sites with new pattern bindings. As immature as the record system
is, take the time to use it from the beginning; it'll save you pain later on.

This is a very common pattern in C++ as well; many experienced API designers I
know will give all their methods the signature of "bool someMethod(const
MethodInput& input, MethodOutput* output)", where MethodInput and MethodOutput
are structs. At Google, we often use protobufs as the structs; that gives you
a bunch of other benefits, as you can instantly print them out for debugging,
and you can log them efficiently, and it becomes trivial to turn the API into
an RPC service if it outgrows a single process.

2\. Don't be afraid to use type inference; oftentimes, the compiler can infer
a more general type than you can write down. If you do write down the types,
be liberal with your use of type synonyms; you will probably end up changing
those types later, and it sucks to have to visit a few dozen functions with a
search & replace. "newtype" is very often worth it, if just for the added
typechecking.

3\. Point-free style is cool, but I've never been able to look at point-free
code I wrote a month ago and understand what it was doing. Don't do this
outside of very specific cases where the point-free version has some semantic
meaning (for example, you're treating a partially-applied function as an
object that does something. If you wouldn't define a closure for it in Python
or JavaScript, don't make it point-free in Haskell).

4\. Haskell module patterns are much more similar to C than C++ or Java. You
typically want a clear divide between "data" modules (that define fundamental
dataypes) and "code" modules (which define functions and algorithms acting on
those datatypes). Trying to use the OOP-style, "one class per file" approach
is very frustrating in Haskell.

5\. The "mathematician's naming convention" (all single-character variable
names, with "s" as a plural to indicate a list) is just as bad an idea in
Haskell as it is in C. Go give your variables some meaningful names and ignore
all the tutorials that have "xs" and "ps" and "qs".

6\. Very often, you'll want to define a monad for your code from the get-go
(you can even just typedef the IdentityMonad to start out with) and write your
code in a monadic style from the beginning. You _will_ want to add error-
handling and probably state and logging at some point in the future. If you
start out with a typedef'd monad type, you can just change the typedef to some
monad transformer stack as you need to.

~~~
neilk
I see -- that all makes perfect sense. Thank you!

However, you're still suggesting that Haskell is only good for prototyping,
not for "real apps", which understandably for you are Google-scale apps. There
is a very long distance between what Google does and what I need to do, today,
and premature scaling is the death of many projects. But let's be ambitious
and pretend that one day I will want to operate at that scale. Assuming C++ is
out of the running, is there really no alternative to Java?

I've been working on apps in PHP (Flickr, now Wikipedia) and while I admire
the language, in the same way I admire how weeds can colonize an area
efficiently, I am not going to choose that for a personal project. I agree
with your assessments of Python and Ruby, and I'm not sufficiently enamored of
any framework in those languages to make it worth the trouble. I can sling
Perl as well as anybody (even in a style approaching functional) and it can be
very efficient, but it's hard to find collaborators these days.

This seems to leave Erlang, Haskell, Scala, or maybe Node.js + JavaScript.

Scala seems like what an enterprise would choose for its foray into functional
programming, and indeed that seems to be the hopes of its creators. While it's
a "safe" choice, for Java shops maybe, I fear the massive shear forces between
Java's way of thinking and Scala's attempt to paper over all that with
functional thinking. Not to mention the complexity of that language. Still, it
seems to work for Twitter, FourSquare, et al.

There's nothing wrong with Erlang, and it has its adherents in industry, but
the syntax annoys me.

I'm already an expert in JS, and a codebase of a single language has its
benefits. The intense competition in the browser to make JS an application
language seems to have already vaulted JS performance over other scripting
languages and new libraries are being written every day. Still, it just feels
odd to write directly to a database or file in JavaScript. And I've gotten
myself tangled up in JS' asynchrony a bit too much recently. Maybe that's an
irrational prejudice.

I guess this is why I've been looking on Haskell; in part because it offers
some hope of really writing a lot less code and having that code be so well-
typed, automatically, that it practically writes its own tests (see
QuickCheck) or doesn't even need them. It seems like there ought to be _some_
way to get the best of that without needing to shoot yourself in the foot
because you suddenly want to log some action and you didn't define some code
twenty layers above it as monadic.

~~~
nostrademons
Assuming C++ is out of the running, the alternative to Java is basically
Scala. And that's it. Maybe Go will be an alternative in the eventual future,
but right now it lacks the library & tool support.

There's also nothing wrong with writing your v1 in one language and then
rewriting in a different one if you need to scale. You will probably need to
do this anyway, even if you start in C++ or Java, because the architecture
needed to scale by an order of magnitude is usually very different from the
architecture needed to iterate quickly.

------
recoiledsnake
> Java, with its faults, has completely conquered web application programming.
> On the sidelines, charging hard, new languages are being invented at a rate
> that is mind-blowing, to also conquer web application programming. The two
> are pitted together, and we’re left with what looks a bunch of preppy mall-
> kids battling for street territory by break dancing. And while everyone is
> bickering around whether PHP or Rails 3.1 runs faster and can serve more
> simultaneous requests, there lurks a silent elephant in the room, which is
> laughing quietly as we duke it out in childish arguments over syntax and
> runtimes.

Nice job writing a 1000 word article about Java and web application
programming without mentioning the elephant in the room C# with ASP.NET

I've seen small and medium shops move over to or adopt C# at a very high
rate(for internal web apps) in the past 5 years. .NET is big in the government
too and C# is adding nice feaures that Java has either no equivalent or a poor
implementation not to mentions technologies like ASP.NET MVC.

THAT is what is eating Java's lunch more than anything else. It boggles the
mind how someone could write a whole essay on this topic without mentioning
C#/ASP.NET. I think that's a symptom of reading popular blogs around the
internet which talk only about things like PHP/Ruby/Python etc. but comes
across as incredibly shortsighted.

~~~
bonch
The problem with C# is that it's tied to Microsoft, and we're already seeing
what can come of that with developers wondering if .NET is a first-class
Windows 8 development platform or has been relegated to legacy status and
supplanted by HTML5. Microsoft is remaining silent.

~~~
baha_man
"The problem with C# is that it's tied to Microsoft..."

What about Mono?

~~~
moondowner
Mono doesn't get close to .NET, even in versions and in implemented
functionality, there's always missing something. Writing a serious web
application in asp.net is not the same as writing a serious web application in
mono.

~~~
baha_man
"...always missing something"

Such as?

~~~
moondowner
You can see that here: <http://mono-project.com/Compatibility>

------
benihana
>So what is the real problem in the this industry? Java, with its faults, has
completely conquered web application programming

What? No. Not at all. Maybe, _maybe_ I'll concede that the JVM, when
configured properly, is well suited for the middle layer of a webstack, but to
say that Java has completely conquered web application programming is just
silly.

------
bxr
I'm currently writing some cobol for shits and giggles. Its terrible.

I don't really get this article though. The "friendly fire" is what fuels the
drive to make new hotness to be as good as it can be. I don't think its
damaging outside of the handful of people daft enough to take it too
personally.

The argument presented in the article is appealing enough, but ends before it
gets to the part where it explains how to make inroads towards the cobol
folks. Its been criticized up and down, left and right. The people still using
it have taken themselves outside realm of constructive criticism. Any time
spent there fighting a losing battle could also be spent improving on what we,
who are willing to use new tools, have.

------
bonch
Most of the Java hate I see comes from C# fans (which is ironic given C#'s
origins).

~~~
Johngibb
I don't think it's ironic. C# directly addresses many of my concerns with
Java.

C# does away with a lot of the boilerplate code necessary in Java (i.e. type
inferencing, concise lambdas with true closure instead of anonymous single
method classes, yield return for lazy enumerables). By baking this syntax
sugar into the language, it removes the need for all of the enterprisey
patterns needed in Java to accomplish the same things.

------
16s
Java the language is OK. The only downside to it (in my opinion) is forcing
OOP on everyone. Other than that, it's fine.

Java the virtual machine (JVM) is what I dislike more. It's a platform (like
Windows) and within its virtual world, things are just not real. It's all
pretend and I guess I should expect that from a "virtual machine".

Both the language and the JVM are mainstream and used heavily now... mostly in
big, corporate environments. Devs can make a good, safe living writing Java,
and there's nothing wrong with that.

If you hate Java or the JVM, do your hobby projects in a language you enjoy
more. If you have no hobby projects or strong feelings (one way or the other),
I'd argue that you're in the wrong business.

