
Why Java? Tales from a Python Convert - soofaloofa
http://sookocheff.com/post/java/why-java/
======
mattdlondon
Just a spin on this: as a java developer that recently started doing a lot of
python, what has really annoyed me (apart from the utterly woeful IDE
functionality compared to typed languages) is the extra "boiler plate"
thinking you need to do with python because of the dynamicness meaning you
have to keep the types and classes you're using for your codebase in your
head, rather than letting the computer deal with that.

e.g. you have a function with a "database" parameter ... it could be a string,
it could be a dict, another class, or even a number. There is no way to know
apart from back-tracking through the code (or run it and wait for it to fail
with a TypeError when that code gets hit). With java you just read the type
off the screen and you can get on with solving the problem at hand without
extra thinking, and even if you do screw up your IDE tells you right away with
a nice squiggly red underline, or if you're not using an IDE during compile
time. With Python you might not find out about that TypeError until that 3am
pager call.

People have suggested that the answer to this is forcing strict naming
conventions and/or strict docstring conventions ... but if you are going to go
with that level of extra work of typing "database_string" or """Lots of long
docstrings explaining exactly what type the database parameter is.""" (and
maintaining it!!!),you're not saving any boilerplate (biggest complaint I've
seen levelled at java) so why not just use a statically typed language ?

tl;dr - for me, python adds cognitive load of keeping the minutiae of the code
in my head on top of solving the actual task at hand.

That said, I like the "pick up and go" prototyping feel of Python for quick
jobs - java sucks for that.

~~~
cantastoria
Bingo! Coming from C# and C++, I had exactly the same realization using Python
(before I switched back). I always ask Python programmers "but are you just
keeping track of the types in your head?" because it's impossible to keep
myself from doing that. If Python (and dynamic languages in general) are just
pushing the type checking into the programmer's lap, I'm not sure what the
advantage is other than less verbose (looking) code.

~~~
gozur88
That's the problem I had with perl. Sometimes one plus one is two, sometimes
it's eleven, and the interpreter doesn't always do what you expect.

~~~
kanatohodets
Perl has distinct operators for string concatenation and numeric addition (as
well as string comparison/numeric comparison):

    
    
      $ perl -E 'say "plus: ", 1 + "1"'
      plus: 2
      $ perl -E 'say "concat: ", 1 . "1"'
      concat: 11
    

There is some type funkiness: a Perl variable can have both string and numeric
components. However, which one is in use is only a problem in serializers
(JSON, etc.) -- in normal usage you can rely on choosing the right operator
for the type at hand.

------
pka
> Java’s type system, while verbose at times, allows you to write code that
> largely “just works”.

NullPointerException would like to have a word with you about that.

In all seriousness, it feels unreal that people can be _that_ impressed by
Java's safety or lambdas. Makes you shudder to think about what they've used
_before_ that.

~~~
throwavay_java
AttributeError: 'NoneType' object has no attribute

isn't much better.

Java might not be perfect, but it does let you catch a lot of problems at
compile time rather than run time, which is a step in the right direction. The
alternative (run it and see) gets old fast.

~~~
dragonwriter
Java provides less of the benefits of static typing than many other
statically-typed languages (even than others available on the JVM), at a much
higher cost in required ritual invocations made to the type system.

Yes, there is a value in static typing, but that value is minimized when you
have a type system that isn't particularly expressive and/or have to make add
a lot of redundant code to satisfy a comparatively unsophisticated type
checker.

Java may have gotten slightly better since its poor performance in
cost:benefit terms when it came to static typing helped _launch_ the surge in
popularity of dynamic languages, but its still not a great poster child for
the benefits of static typing.

~~~
codingbinary
And don't forget Java's type erasure. Still wondering how they could actually
call that a FEATURE.

~~~
potatosareok2
Was erasure necessary to maintain backwards compatibility?

Also what are you doing that you need type information at runtime?

~~~
dmm
No it wasn't necessary to maintain backwards compatibility. Type erasure was
implemented to allow libraries to upgrade to generics without breaking
compatibility with existing applications.

~~~
wtetzner
How is that not backwards compatibility?

~~~
codingbinary
The one is on a language level, the other on an application/framework level.

------
sytelus
OP is glossing way too many things.

1\. Desktop users are tricked in to installing Ask toolbar crapware. Which
other language tricks users in to doing that?

2\. Java development actually have languished for very long time and it is
very recent that it started to catch up with C# and other modern languages.
Java forums are filled with cries and screams for adding these improvements
for years on.

3\. Java is built on language concepts that are now 20 years old. Back than
people wanted every language look like C++. The millennials think outside the
braces. They expect language to infer types instead of repeatedly being
specified all over. They expect REPL. They don't want everything modeled as
object and so on. Mature language does not equal modern language.

3\. Java is not truely "open source" or "free". Ask Google and Apache Harmony
for the legal battles they had to fight with Oracle.

4\. If Microsoft had done what it's doing with C# and .Net back in 2000, I
highly doubt Java would be as popular as it is now. In other words, things can
be popular even while being technically legging behind. This is not to say C#
was initially just a Java copy cat but it did grew up fast while Java folks
set on their laurels.

5\. Java is owned by Oracle. Enough said.

I think modern languages should not have obligation to look like C/C++ and it
should use advances in automatic type inference, functional paradigms etc.
Anything 20 years old would have great libraries and VMs, but then mainframes
and Cobol were also very safe, "reliable" and had great libraries and
infrastructure at some point. It's ok to use mature tools to get shit done
_now_ but proposing them as new frontier doesn't make sense.

~~~
chrisseaton
> Java is built on language concepts that are now 20 years old.

Name me at least one language, even remotely mainstream, that is built on
language concepts which aren't at least 20 years old.

~~~
sytelus
Well, you know Archimedes and Aristotle had thought through all concepts in
everything so nothing is new really :). Or more recently, all languages are
just little flavors on Turin machine or Lambda calculus. But practically,
Python had been one of the language that sets aside itself dramatically. It's
still surprising to me that language designers - including folks on Go team -
still have hard time thinking outside of braces. It's almost disguesting how
C# requires braces and uses == vs =. When you look at Python, it's apparent
that Guido van Rossum had no inclination to do things as it was popular at the
time and he put a lot of thought in removing redundancy, putting _else_ clause
in _for_ and so many other cool things that are now so obvious.

~~~
chrisseaton
So does that waffle mean you can't think of any languages not built on 20 year
old constructs then?

------
ubercow
The one thing keeping me away from Java still is the awful experience around
modeling data.

Compared to something like a case class in Scala or even autoproperties in C#,
writing classes with a bunch of getter and setter methods just to keep state
is really tedious.

~~~
LoneWolf
I'm seriously tired of this argument against getters and setters, just
generate them with the IDE some also support collapsible regions with a start
and end comment, and forget about them.

So considering you can just generate and forget why is it tedious?

~~~
cballard
If it _can_ be generated, why doesn't the compiler do it for you? This
shouldn't be done at the IDE level.

~~~
zo1
Because it's not about tooling, it's about being explicit vs implicit. Though,
there is something to be said about having a nice default that you can easily
invoke at the code-level.

~~~
raphaelj
Yeah, and loops are just (less powerful) syntactic sugars over jump
instructions, too.

Let's remove them and go back to IDE generated goto's !

------
benedictp
Take a look at Kotlin [https://kotlinlang.org/](https://kotlinlang.org/) I
know there is also Scala and other JVM languages. But I'm also an Android
developer and Kotlin works really fine with Android-Studio (both from
JetBrains).

~~~
zem
kotlin definitely looks like a drop-in replacement for java. fairly
conservative set of extensions, seamless interop, and fixes a bunch of
annoyances.

------
nikdaheratik
I think the author has set an impossible task for the article: trying to sell
Java without giving any specific use cases. Generalities don't cut it,
especially if you've already invested time learning how to do something in
Python, which isn't perfect, but can match the JVM in the areas that it does
excel at (e.g. problems that need NumPy or Django).

Java is irritatingly pedantic about sticking to its idea of how OOP should
work. It has that design by committee feel to it that enforces some idioms
that please no one (like pushing object Factories). If you need to get a
prototype out or want something that can let you automate a task quickly with
little BS, you don't want Java.

Java is good for enterprise developers as it tends to reign alot of the cowboy
tendencies of some programmers and helps to force everyone on the project to
use the same clearly defined, well planned (and less elegant) APIs and other
systems. And the JVM keeps you from being tied into some specific hardware
that may go away in the future.

It's the difference between a toolkit to design and build a cool building,
like the Space needle, or you need to coordinate a huge number of contractors
because you're building the Big Dig or Chunnel.

------
golergka
These examples look like C# 2.5 with a little bit of LINQ.

~~~
tracker1
IMHO, C#'s tooling and is definitely ahead. Java is starting to get there, and
I can see why the JVM is still popular. But given the actions of Oracle and MS
as of late, I think I'd take MS. VS starter projects are easy to setup and
run... Every Java application I've worked on has been an exercise in
frustration just getting the environment setup.

~~~
soofaloofa
I'm also a fan of C# but deploying .NET has been a sticking point. I'm hopeful
that Microsoft's open source efforts fix this.

~~~
mstromb
It's not completely free, and not completely open source, but we've been very
happy with Octopus Deploy [https://octopus.com/](https://octopus.com/)

That and Topshelf
[https://github.com/Topshelf/Topshelf](https://github.com/Topshelf/Topshelf)
have made deploying Windows services very easy. Topshelf is slowly adding some
Linux/mono support, and OctopusDeploy supports SSH as a deployment option, but
unsurprisingly things aren't as nice if Windows isn't your target.

------
thothamon
To me, the article doesn't really sell Java the language. The big benefits are
in the JVM and libraries, which support many languages far superior to Java.
The only virtue of Java the language might be the programmers who know it, and
even there, many programmers are not familiar with the new features of Java 8.

------
bsder
java.util.concurrent is so much better than anything else mainstream that it's
ridiculous.

------
thinkersilver
I love the jvm, I love the tooling and the ecosystem, but Java I do not love.
The author presents many of Java 7/8 features as a reason for Java's
greatness. The language features of Java 7/8 are really not that compelling.
Let's consider that C# has had much a more progressive approach to language
design for a while now.

Most places I've worked at recently have moved to Java 8 because 7 has been
EOLed. It feels like we were pushed onto 8 rather than enticed by its
shininess.

What makes Java great isn't java it's the jvm. It's such a brilliant piece of
engineering. What makes the jvm 'meh' is it's association with java. The
arguments the author makes about Java being great are in my eyes really about
the JVM, its tooling and its languages.

------
csense
Maven's one of the most disgustingly over-engineered, obtuse, verbose, tightly
coupled pieces of s...oftware I've ever seen. From _the project 's own
5-minute introduction_ [1]:

If you have just installed Maven, it may take a while on the first run. This
is because Maven is downloading the most recent artifacts (plugin jars and
other files) into your local repository. You may also need to execute the
command a couple of times before it succeeds...The POM is huge and can be
daunting in its complexity...You executed the Maven goal archetype:generate,
and passed in various parameters to that goal. The prefix "archetype" is the
plugin that contains the goal... the second [command] is simply a single word
- package. Rather than a goal, this is a phase. A phase is a step in the build
lifecycle, which is an ordered sequence of phases. When a phase is given,
Maven will execute every phase in the sequence up to and including the one
defined. For example, if we execute the compile phase, the phases that
actually get executed are [list of 6 items]...Although hardly a comprehensive
list, these are the most common default lifecycle phases executed [list of 10
items]...

So in order to use this, I have to understand its own specialized non-standard
vocabulary, like artifact, repository, archetype, plugin, goal, package,
phase, lifecycle...the build configuration is in XML...it does a lot of stuff
automagically, like executing five extra phases or downloading dozens or
hundreds of executable files from the Internet.

People love Maven for some reason, but I'll use shell scripts or Ant for my
Java builds, because _when_ the build breaks [2], I want to be able to
understand what's going on without having to read a few hundred pages of the
build system manual.

[1] [https://maven.apache.org/guides/getting-started/maven-in-
fiv...](https://maven.apache.org/guides/getting-started/maven-in-five-
minutes.html)

[2] Anyone who's ever worked with any build system knows the build _will_
break.

------
je42
I don't see any valid arguments that make Java 8 strictly better than any of
the alternatives. These languages are all in the same rough ballpark. Your
particular use case/environment will determine mostly which Language you
should be pick.

------
js8
"the JVM has excellent support for production logging and production
monitoring, allowing you to easily monitor performance metrics down to an
individual thread"

Is it "excellent" compared to z/OS and mainframe (SMF and RMF, specifically)?
I sincerely doubt it, but I would like to know if there is someone who can
compare. I don't think any platform can match z/OS in the visibility into the
system, but I am not enough expert in Java to really compare.

~~~
chris_overseas
You're comparing an OS independent language to an entire operating system? I
think you're probably right, I don't think there is a sane comparison. But I
don't think that's what the parent was referring to.

I'm not sure there are too many languages that provide (eg via slf4j or JMX)
extremely customisable, universal logging and monitoring across multiple
libraries that are used together in a single application. That's not a
function of the language itself though, just the maturity of the libraries and
ecosystem around it. Combine that with the tooling (eg IntelliJ IDEA) and no
matter how much you might think Java as a language is verbose/clunky/crappy
(which I tend to agree with), it's pretty hard to beat for large, complex,
maintainable systems.

~~~
js8
"You're comparing an OS independent language to an entire operating system?"

No, I am not comparing Java, but JVM. JVM is a platform, so it should have
insight what's happening on it, don't you think? Whether this insight comes
from the platform (JVM or z/OS) or the underlying system (native host OS or
mainframe) is irrelevant - you probably want both (and in z/OS you get both).

Whether Java (the language) is clunky is irrelevant - z/OS has lot clunkier
languages on it (application development is huge pain on z/OS compared to
JVM), and I still think z/OS beats JVM for large/complex/maintainable systems.
;-) (Basically for the same reason - more mature.) z/OS has many logging and
tracing functions, at different granularity, some of them are assisted with
mainframe hardware. I don't see how JVM could beat it, but I may be wrong.

------
boultonmark
I can't imagine you were ever really a Python programmer if you enjoy
progamming in Java. It's almost the anti-python

~~~
svisser
No true Python programmer would switch to Java?

~~~
boultonmark

             }
          }
       }
    }

------
draw_down
Every time you see "it just works", run.

------
erokar
Stockholm syndrome.

------
thefastlane
i don't care what lipstick you put on that pig: when something as simple as
writing to stdout requires that i first create a new class, i'm not
interested.

Edit: i do consider this a legitimate issue with how Java 'does' OO. i'd be
curious to understand downvoters' thoughts.

One more edit: wow, tough crowd. for those not familiar, i'd suggest reading
Steve Yegge's essay "Execution in the Kingdom of Nouns"

~~~
umanwizard
You're probably getting downvoted because it's factually not true.

System.out.println("Hello, world!");

No new classes there.

~~~
thefastlane
how would you compile that? here's what i get:

    
    
      test.java:1: error: class, interface, or enum expected
      System.out.println("foobar");
      ^
      1 error

~~~
umanwizard
Oh -- you're talking about the fact that you need to create a new class for
your program's main method?

Yes, this is true, but it has nothing to do with printing to stdout.

Edit: I don't like Java and I've read the essay you're referring to. Please
don't assume bad faith in other commenters. Your original post was factually
wrong. There's enough wrong with Java that you don't need to make stuff up to
criticize it.

