This is one of my first posts, and English is not my native language, so comments not just on the content but also on the language are more than welcome.
Speaking for myself in the U.S., the need to learn a new language other than English has become such an edge case that I always marvel when non-native English speakers put their work out for us to judge. Your writing is clear...more importantly, you have a great grasp of how to visually partition your essay, a skill that many writers, native English or not, could improve on. Great submission, even if I'd like Java to be less prominent :)
In that case, "Why it saves you time?" should be "How does it save you time?" That was the only line in the piece that screamed "non-native English speaker" to me.
I was impressed by your clear writing. Some minor suggestions since you asked for feedback: <:)
* "mandatory requirement" is redundant. If something's not mandatory, then it's not a requirement! :)
* "Many admit that as much as Java is not much fun to write code with, the JVM is a different story.": This sentence is awkward. Perhaps something like: "Many admit Java code is not much fun to write, but the JVM doesn't limit your choice of language."
* "Scala shares the Java Technology Stack, and knowing Java is a big plus when learning Scala, especially due to the common library ecosystem, and the insights into the JVM workings.": This sentence is awkward. It could be simplified into something like: "Knowing Java is a big plus when learning Scala because the languages share a common library ecosystem."
If you are interested in more resources about English writing, I recommend Joseph M. Williams' Style: Toward Clarity and Grace. Strunk & White's Elements of Style is a classic (and short), but some people dislike it.
Java runs the world and runs on several devices from Raspberry Pi, embedded robots (java me) to Mobile Devices (Android) to Enterprise Software (Java EE) to Data Servers crunching Big Data (Hadoop).
As expected, the article was that, a "Java is fast" that can only be said if you don't compare it with anything made to be fast, and "Android uses Java". All the other reasons are excuses for drawbacks of the language.
The one thing that made Java relevant - that one can create a ruleset that constrain bad coders and avoid them destroying all your codebase - didn't go away. And the context where companies just don't know how to hire developers didn't change either, thus still only projects that protect themselves against bad developers are ever successful within them. But it seems that the more productive languages are so much more advanced than Java nowadays that it become better to protect a project by hiring less developers than by making them less powerfull... Or, at least, I can think of no other reason for people to care to anounce that Java is not dead yet.
Actually, Oracle have proved a LOT more committed than Sun to improving the language. They put one of the smartest guys in charge of Java 8, charged him with turning the ship around and have given him a lot of resources to work on it. Even Java 7, while including few language features, did include a lot of JVM improvements.
The timezone-update tool, on the other hand, really is a minor issue. So some people will have to use IBM's tool instead. Yeah, it's lame, but I don't think it's going to change anyone's mind.
Why learn Java? Sure, there's lots of jobs out there for it, but there's also lots of Rails jobs too. Rails is more fun than Java, so if you're looking to expand your career opportunities, you're probably better off learning a tech stack that won't bore you to death.
Things are boring when you already know them. Things are interesting when you're learning something new. Most of the excitement over other languages comes down to the fact that you are starting from scratch and everything is fresh.
As someone who coded both Java and Javascript today, I attest that boring is also when every little darn thing takes 10x the amount of time and code as it rightfully ought to.
Boring is also spending a few hours tracking down a typo in a large Javascript app. Or trying to refactor something and grepping through a bunch of files trying to find the ways in which it's being used. There are downsides and upsides to both kinds of development.
I think Java does suffer from a little too much boilerplate, but that is solved by becoming proficient in an IDE which doesn't actually take too long. Even for this old hacker who only picked up an IDE 2 years ago after nearly 20 years of emacs.
Java is very verbose, but also very strict and explicit. Besides all the obvious benefits to that, it means you can utilize auto-complete/intellisense/refactoring tools that let you pound out code at a rate on par with dynamic languages, even if you are producing 10x the amount of code. Fully learning these tools, e.g. in Eclipse, is a meta-skill that can take some time to get good at, but if you're working with Java for anything over a few weeks, it's definitely worth it.
This is very true. It's why I seem to keep looking at Clojure articles and tutorials lately. I keep saying I should master language "X" then I jump to something new...Thankfully I'm just a hobbyist.
My point was that if you know ruby, and think about adding something to your arsenal, don't write off java automatically. I meant it's still relevant for hackers to learn it, even though many of us agree writing in ruby is more enjoyable.
>Why learn Java? Sure, there's lots of jobs out there for it, but there's also lots of Rails jobs too.
Far far less than Java jobs.
>Rails is more fun than Java, so if you're looking to expand your career opportunities, you're probably better off learning a tech stack that won't bore you to death.
Rails and CRUD web apps bore most hackers to tears.
At least with Java you can work from web apps, to Android, to web services, create powerful servers like Cassandra or powerful stuff like Solr and Lucene, use embedded Java, and a lot more.
And far far far far less than .NET jobs. Which is still more fun than Java.
> Rails and CRUD web apps bore most hackers to tears.
They don't bore me to tears. Between the brand new Javascript frameworks like Angular and CSS frameworks like Bootstrap, it's possible to develop great looking, simple apps that have a great deal of functionality in extremely short amounts of time.
Depends where you are. Outside Silicon Valley and a handful of tech hubs in the world, Rails pretty much doesn't exist. Java, on the other hand, is used everywhere.
Also a lot of the de-facto Big Data/NoSQL/Distributed Computing stack is Java(/Scala). Hadoop, HBase, Cassandra, Neo4j, Storm, its actually pretty interesting to note that most of the popular nosql solutions are in Java. On top of that its the number 3 language on Github.
I'm not a huge fan of Java but I'd be pretty surprised if someone was saying Java wasn't relevant. Don't quote me on this, but its also the fastest language you are going to get without pulling out C/C++. When the author made the claim that Java was as fast as Go, I was a bit surprised. I wasn't aware Go had caught up to Java.
JVM crypto (i.e. using encryption libraries) can be faster than native because of function inlining (whereas in C/C++ you don't inline across libraries at link time because an update to the crypto library would require a recompile).
Programmers today do not have to handle memory management because of JVM. Programmers yesterday could not handle memory management that's why jvm came into existence.
> When the author made the claim that Java was as fast as Go, I was a bit surprised. I wasn't aware Go had caught up to Java.
As a Go "fan": it hasn't. It's close in some things, faster in a few, but the JVM has years (and years) of performance tuning in it, and Go won't unequivocally beat Java for some time (if ever).
(This WiFi connection is failing me right now, but there's a good number of Go vs. Java benchmarks out there, for whatever benchmarks are worth)
I was only referring to the Web framework benchmark, where Go (1.1 I think) is taking the lead over Servlets on many of the benchmarks. Still impressive.
That was my reaction as well. We are using Go in production here and I'm very much a Go fan, but I'd be surprised if Go caught up to Java in so little time.
That benchmark makes it clear Go has not caught up to Java in performance.
Out of the 10 tests that have both Java and Go results, Java is faster than Go in 9 tests while Go is faster than Java in 1 test (by 0.2%, so not significant).
Only 1 of those 3 tests (the very 1st one) also contains Java results. The other 2 are Windows tests that don't contain any Java results.
Hence I said that out of the 10 tests that contain both Go and Java results Go only beats Java (by a statistically insignificant 0.2%) in 1 test while Java beats Go in the other 9 tests.
Java and the JVM seem like fantastic foundations to have for a language like Clojure. You can develop in a fun language and still use the immense amount of libraries that have been created over the years by the community. You can interop with pretty much anything, and you didn't have to make it yourself or wait for your language to catch up to it, because it's been there all along thanks to Java.
Don't look at Java like the starting point, look at it as the big furnace for what's leveraging it.
I have always found it rather unfortunate that the JVM is the best platform for Clojure, and unfortunate that interop with Java is so important. All of the blemishes on the language seem to be a consequence of those two things.
I think the idea is to have Clojure support as many runtimes as possible, or whichever runtime is best for the task. The JVM was the start and at this point has the biggest momentum, but there's not much stopping people from porting the language to a different runtime.
I really truly love Clojure the language. To me the vector, map, etc syntax is a perfect amount of syntactic sugar--it institutionalizes idiomatic use of these structures.
But... sometimes the JVM feels awfully heavy-weight and far from the metal. I have to wonder what a Clojure on SBCL or Racket would look like. Ignoring for a moment the benefits of the epic number of JVM libraries, I can't help but think that the foundations of those languages would be a pretty low impedance mismatch for Clojure The Language. Hey, Clojure-on-CL or Clojure-on-Racket could even support real tail recursion.
Every time articles about a language "still being relevant" pop up, my first thought is "oh, it's down to that stage already". Not sure what this article is trying to accomplish.
I like Java, really. Learning it might be a good idea as the article suggests, you might find you like it too. It's solid, fast, tons of libraries, it's efficient for programming IMO.
>> Stream.of(1, 2, 3, 4, 5, 6, 7)
.map(x -> x * x).filter(x -> x % 2 == 0)
.reduce(0, (sum, x) -> sum + x);
If I catch anyone writing Java code that I will have to work on writing Lambda expression crap like the above I will hit the ceiling. How can you debug junk like that?
Is there actually a way to properly debug LINQ expressions? I haven't figured out how to get Visual Studio to step through lambdas or break halfway through the chain (eg break after the filter call has completed and before reduce runs in the above example).
But I'm not sure if I'm missing some blindingly obvious.
Thing is though, now you've changed the recipe from what you intend to run in PROD. You linearized it to gain a debugging advantage that you lose when you re-lambdaize it.
this probably isn't the place to start a chain on how to do this, but if you wrap the statement in the lambda in a {} block and explicitly return the expected value, you can insert line breaks and set breakpoints.
i'm not familiar enough with the vocabulary to explain it perfectly, but i do it all the time.
example:
list.Find(o=> {
if (o.prop == "foo")
{ return true;} // visual studio will allow a breakpoint here
else
{ return false;}
});
I find that perfectly readable. I would be more likely to catch an error in that line than in the equivalent in imperative style. It's a matter of habit. It all depends on what you are used to write, whether you are used to functional style or not.
This exact response right here is why a perfectly good language like java is ranked just under php in the hated languages list.
The language is fine but the insistence by the vast majority of the developers using it to do things in a way that can only be described as "Enterprisey" gives it a bad name. And it really is a shame.
I can see my view is already unpopular but you asked a fair question. It's several key pieces of logic jammed together on one line. That's not the part that bugs me though, it's wondering how this is going to play out. I can imagine multiple threads servicing the Lambda stuff and it reminds me of trying to debug Camel code hopping around debug screens trying to stay up with all the async stuff going on just to find a simple bug. Maybe ... maybe I'm wrong ... I could be, I don't think I am but it's going to have to be more deterministic than what I'm afraid it will turn out to be.
I guess I can understand if java doesn't allow for debugging code similar to this. Being fond of lisp/scheme languages such as racket though, I find this very clear and is of course easy to debug in those languages.
I like java as a language. It's consistent, has less warts than many languages and the jvm is pretty darn awesome.
What I don't like is the java ecosystem. Guice? I've nothing but bad experiences with it. Just about every framework out there that I've used in java has gotten in my way more frequently than it's been helpful. Java Api's (excluding much of the stdlib) almost all seem to be made to annoy me.
A great irony about the use of Java as a language for interactive systems is that it only took off when deeply enmeshing a Java-ish runtime with Android freed Java from the constraints of "write once run anywhere."
It turns out that OSs have diverse interactive frameworks with different capabilities, and OSs compete on the basis of those differences. In Android, this divergence from other OSs includes the ability to install aftermarket middleware in Android's userland.
I've given up any hope of Java ever being considered a sexy language. Its philosophy has been the polar opposite of 'move fast and break things' at least in terms of how the language has evolved. That's been mostly a good thing, though frustrating. The language features are catching up now with the 'sexy' languages and it's pretty exciting.
Still one of the biggest problems with Java I think is the plethora of options you have when building a web stack. And integrating everything is a huge pain. There are options like dropwizard or play, but those bake in too much of their own assumptions for my taste. If anyone is interested in seeing what a modern Java web stack looks like, check out my attempt at it here: https://github.com/depsypher/flapjack
Java is the new COBOL. Everyone is going to be wondering when Java will die for the next thirty years. Java will still be running the enterprise decades after RoR is gone.
The more interesting question is which will die first: Java or COBOL?
81 comments
[ 2.3 ms ] story [ 191 ms ] thread* "mandatory requirement" is redundant. If something's not mandatory, then it's not a requirement! :)
* "Many admit that as much as Java is not much fun to write code with, the JVM is a different story.": This sentence is awkward. Perhaps something like: "Many admit Java code is not much fun to write, but the JVM doesn't limit your choice of language."
* "Scala shares the Java Technology Stack, and knowing Java is a big plus when learning Scala, especially due to the common library ecosystem, and the insights into the JVM workings.": This sentence is awkward. It could be simplified into something like: "Knowing Java is a big plus when learning Scala because the languages share a common library ecosystem."
If you are interested in more resources about English writing, I recommend Joseph M. Williams' Style: Toward Clarity and Grace. Strunk & White's Elements of Style is a classic (and short), but some people dislike it.
https://courses.washington.edu/b572/public/StrunkWhite.pdf
http://chronicle.com/article/50-Years-of-Stupid-Grammar/2549...
As expected, the article was that, a "Java is fast" that can only be said if you don't compare it with anything made to be fast, and "Android uses Java". All the other reasons are excuses for drawbacks of the language.
The one thing that made Java relevant - that one can create a ruleset that constrain bad coders and avoid them destroying all your codebase - didn't go away. And the context where companies just don't know how to hire developers didn't change either, thus still only projects that protect themselves against bad developers are ever successful within them. But it seems that the more productive languages are so much more advanced than Java nowadays that it become better to protect a project by hiring less developers than by making them less powerfull... Or, at least, I can think of no other reason for people to care to anounce that Java is not dead yet.
The timezone-update tool, on the other hand, really is a minor issue. So some people will have to use IBM's tool instead. Yeah, it's lame, but I don't think it's going to change anyone's mind.
TZ updates aren't going to have much of an impact on Java relevance. If they start charging for JRE updates themselves, let's talk.
Java / Python / C# / Go... All the same.. I spend more time solving a problem than actually coding.
Once I have a solution rewriting in an another language is a piece of cake.
I think Java does suffer from a little too much boilerplate, but that is solved by becoming proficient in an IDE which doesn't actually take too long. Even for this old hacker who only picked up an IDE 2 years ago after nearly 20 years of emacs.
Far far less than Java jobs.
>Rails is more fun than Java, so if you're looking to expand your career opportunities, you're probably better off learning a tech stack that won't bore you to death.
Rails and CRUD web apps bore most hackers to tears.
At least with Java you can work from web apps, to Android, to web services, create powerful servers like Cassandra or powerful stuff like Solr and Lucene, use embedded Java, and a lot more.
Especially in middle America, or corporate America.
And far far far far less than .NET jobs. Which is still more fun than Java.
> Rails and CRUD web apps bore most hackers to tears.
They don't bore me to tears. Between the brand new Javascript frameworks like Angular and CSS frameworks like Bootstrap, it's possible to develop great looking, simple apps that have a great deal of functionality in extremely short amounts of time.
Depends where you are. Outside Silicon Valley and a handful of tech hubs in the world, Rails pretty much doesn't exist. Java, on the other hand, is used everywhere.
I'm not a huge fan of Java but I'd be pretty surprised if someone was saying Java wasn't relevant. Don't quote me on this, but its also the fastest language you are going to get without pulling out C/C++. When the author made the claim that Java was as fast as Go, I was a bit surprised. I wasn't aware Go had caught up to Java.
It's because of integrated circuits and the fact that programmers today can't handle voltage management.
As a Go "fan": it hasn't. It's close in some things, faster in a few, but the JVM has years (and years) of performance tuning in it, and Go won't unequivocally beat Java for some time (if ever).
(This WiFi connection is failing me right now, but there's a good number of Go vs. Java benchmarks out there, for whatever benchmarks are worth)
Out of the 10 tests that have both Java and Go results, Java is faster than Go in 9 tests while Go is faster than Java in 1 test (by 0.2%, so not significant).
Hence I said that out of the 10 tests that contain both Go and Java results Go only beats Java (by a statistically insignificant 0.2%) in 1 test while Java beats Go in the other 9 tests.
Don't look at Java like the starting point, look at it as the big furnace for what's leveraging it.
But... sometimes the JVM feels awfully heavy-weight and far from the metal. I have to wonder what a Clojure on SBCL or Racket would look like. Ignoring for a moment the benefits of the epic number of JVM libraries, I can't help but think that the foundations of those languages would be a pretty low impedance mismatch for Clojure The Language. Hey, Clojure-on-CL or Clojure-on-Racket could even support real tail recursion.
I know it is cliche to complain about that, but it really does annoy me.
A Clojure targeting LLVM could be pretty interesting too...
If I catch anyone writing Java code that I will have to work on writing Lambda expression crap like the above I will hit the ceiling. How can you debug junk like that?
But I'm not sure if I'm missing some blindingly obvious.
i'm not familiar enough with the vocabulary to explain it perfectly, but i do it all the time.
example: list.Find(o=> { if (o.prop == "foo") { return true;} // visual studio will allow a breakpoint here else { return false;} });
The language is fine but the insistence by the vast majority of the developers using it to do things in a way that can only be described as "Enterprisey" gives it a bad name. And it really is a shame.
int sum = 0; for (Integer x: Arrays.asList(1, 2, 3, 4, 5, 6, 7)) { int x2 = x * x; if (x2 % 2 == 0) sum += x2; }
No threads, no weirdness. It's just a different syntax for a loop, really.
I'm a bit tired of people just dismissing Java based on its hipness factor.
What I don't like is the java ecosystem. Guice? I've nothing but bad experiences with it. Just about every framework out there that I've used in java has gotten in my way more frequently than it's been helpful. Java Api's (excluding much of the stdlib) almost all seem to be made to annoy me.
Java's great. If only it's ecosystem matched.
Mind you, this may just be because there are other things in the application that are so much worse.
Anyway, thanks for sharing your opinion. Still think learning GO could be a better idea, at least for me.
It turns out that OSs have diverse interactive frameworks with different capabilities, and OSs compete on the basis of those differences. In Android, this divergence from other OSs includes the ability to install aftermarket middleware in Android's userland.
Still one of the biggest problems with Java I think is the plethora of options you have when building a web stack. And integrating everything is a huge pain. There are options like dropwizard or play, but those bake in too much of their own assumptions for my taste. If anyone is interested in seeing what a modern Java web stack looks like, check out my attempt at it here: https://github.com/depsypher/flapjack
The more interesting question is which will die first: Java or COBOL?