Coming from a Perl and C++ background, Java was great because the designers dared to remove so many features from the language. In that sense, it made the efforts of the coders stand out more than the features of the language. This is an important message to an up-and-coming hacker.
That said, Java is far from an ideal language. It lacks many features and is somewhat clunky.
It does do a few things right, though. It hits a sweet spot being both simplistic and fast. By choosing a single packaging, developers could use all features everywhere, and start to rely on them. I think it certainly gave a boost to concurrent programming. IMO, Java also drove the acceptance of GC:ed languages.
Now that Java has stagnated, I think that it is time for many old Javaites to abandon ship and transition to new languages. Perhaps it's best to let Java be. Leave it as a historical language that had its glory days. Perhaps someone will admire it for what it's designers dared to do. Perhaps for what it did for the community. Or perhaps new up-and-coming coders can look in those old code-bases and see some retro-style simplistic beauty.
Thanks to Android I've been writing a ton of Java code lately and, with a good IDE, it's not really that bad.
It should steal a few tricks from C# though. If it adopted the var keyword and real lambdas, and something like LINQ, it would actually be a fairly pleasant language to work with.
I think you captured the essence very nicely there: Java is the not-really-that-bad language.
It's not very powerful and it lacks many useful features.
On the other hand, you can do almost anything with it eventually and it's simple enough that stupid syntax mistakes are relatively rare in Java code.
It's a solid tool for a journeyman, and a crude instrument for a master. But most people are never going to be masters, and most of those who will be one day aren't masters yet.
It's hard to love, I agree, but if you were designing something like Android from scratch now what language would you choose? I'm having a hard time thinking of reasonable alternatives. In the long run I'd like to see something like Go or Kotlin become options but really they're too left field right now.
Javascript would be an obvious choice for anything centered around creating UIs. Palm-now-HP's nice WebOS platform is essentially a recent direct competitor to Android and did that.
I really don't think a dynamically typed language is desirable as the primary development language for a mobile platform. Static typing is just too useful and makes it a lot easier to optimize too. Java is still quite a bit faster than JS.
Something like Kotlin seems like a good choice to me, if it takes off.
Java can do pretty much anything that any other language can do.
Sure. That's part of my point. But just because languages are computationally equivalent (cf. Turing), that doesn't mean one is as powerful/expressive as another. I can get things done a lot faster in Python than in Whitespace.
The boilerplate in Java is a huge drag on everyday coding, and Java has weak support for (among many other things) working with functions, text manipulation, and in some cases even basic arithemetic. You can make things work eventually, but sometimes the effort required and volume of resulting junk code is prohibitive for otherwise useful programming techniques. That's an asset if and only if the people on your team aren't up to using those techniques anyway (and can't easily become so).
From what I've seen the last I tried Java, there's another thing as well.
Java APIs are way more clunky than C#
In C# they're usually done in a natural way, in Java you have all this Rube Goldberg machinery to do something simple.
And if you try to tell me "they are much more flexible" I'll call BS because I never seen something that could be done in Java (except trivial limitations) that couldn't be done in C# or Python or something else, probably in an easier way
> In C# they're usually done in a natural way, in Java you have all this Rube Goldberg machinery to do something simple.
I've done my share of C# and Java, and while it looks like true at first, you then notice some dark corners, and before you know it you're looking at System.Configuration or something in Reflector because of some oddball. The next minute you notice you're actually surrounded by dark corners, and the more light you pour on it, the more the maze reveals its complexity.
Those may be fine languages for some people, but for me both feel like some terribly grinding noise in my head, similar to Pyramid Head's blade[0]. Not being dismissive, this is just my "radar" lighting up in some (painful) way.
I have to say, yes, sometimes there are such issues. I remember some localization function having these problems.
But then again, difficulty should be staged, the most common cases should be the easiest, and yes, even if you're doing something off-beat you should avoid going into dark corners.
There's the utterly retarded getter/setter convention, which while it's the most trivial thing must have wasted billions of programmer-hours by now. More generally I think the existence of a bunch of autogenerated java code (WSDL etc.) has lead many java programmers to write APIs that look like they were autogenerated, for consistency, rather than writing APIs that are actually nice to use.
That's a little unfair. The "Type getX(); setX(Type t);" convention to define a "property" dates from 1997, long before anyone was autogenerating Java code. And frankly at the time it was a revelation. People who were used to writing junk like CORBA IDL suddenly saw this "beans" API using "reflection" to detect this stuff automatically, with no assistance from the programmer except adhering to a simple convention. Really, this looked amazing at the time.
But obviously it's been improved. Managed runtimes (and especially more dynamic ones like Python or Ruby or Javascript) have become the norm. The idea of inspecting the metadata of an objectat runtime is no longer so strange. So when C# or Ruby decided to implement the same kind of property interface they felt comfortable taking a few more risks.
Also, the zeitgeist has moved and values different things than it did in the 90's. At the time, clarity seemed like a valuable goal (especially in comparison to C++), so Java preferred a write-it-out-longhand style where types lived in com.domain.subdomain.module.submodule.MyClass namespaces and all the APIs were multiWordCamelCase() things. And this was intentional, and believe it or not people liked it this way. The advent of Rails and DRY (re-)popularized the idea of a "terse" API, so Java's more verbose stuff looks clunky and "bad" to modern eyes in a way that it didn't.
Basically, don't hate on Java. It was good in its day. And it sits in a more important place in history than I think you give it credit for.
Yeah that's the other thing I forgot to mention that Java should steal from C#. In my own code I often just use public members but even with auto-generation in the IDE the getter/setter thing is gross.
That said, Java is far from an ideal language. It lacks many features and is somewhat clunky.
It does do a few things right, though. It hits a sweet spot being both simplistic and fast. By choosing a single packaging, developers could use all features everywhere, and start to rely on them. I think it certainly gave a boost to concurrent programming. IMO, Java also drove the acceptance of GC:ed languages.
Now that Java has stagnated, I think that it is time for many old Javaites to abandon ship and transition to new languages. Perhaps it's best to let Java be. Leave it as a historical language that had its glory days. Perhaps someone will admire it for what it's designers dared to do. Perhaps for what it did for the community. Or perhaps new up-and-coming coders can look in those old code-bases and see some retro-style simplistic beauty.