People seem to hate Java.

[Kevin Burton]

This is interesting:

https://i.imgur.com/toGKy21.jpg

I can definitely understand the pain.  If you're NEW to java the verbosity and idiosyncrasies probably seem insanely stupid.  Then factor into account things like generics, type erasure, etc.

But ... the good news here is look at clojure and scala... thats pretty sweet.

[Michael Barker]

"There are only two kinds of languages: the ones people complain about and the ones nobody uses."

 - Bjarne Stroustrup, The C++ Programming Language

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Daniel Janzon]

It's just that C, Python and C# are indeed used by quite a lot of people. And they like it (according to the graph).

[Martin Thompson]

Java: terrible language, great tools.

[Darach Ennis]

+1000

--

[Andrew Bissell]

This kind of thing led me to joke at work that we should add ".js" to any Java libraries we open source so they can hit the top page on Hacker News.

On Thursday, October 10, 2013 3:13:45 PM UTC-7, Darach Ennis wrote:

+1000

On 10 Oct 2013, at 23:01, Martin Thompson <mjp...@gmail.com> wrote:

Java: terrible language, great tools.

On Thursday, 10 October 2013 22:19:00 UTC+1, Kevin Burton wrote:

This is interesting:

https://i.imgur.com/toGKy21.jpg

I can definitely understand the pain.  If you're NEW to java the verbosity and idiosyncrasies probably seem insanely stupid.  Then factor into account things like generics, type erasure, etc.

But ... the good news here is look at clojure and scala... thats pretty sweet.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Darach Ennis]

Why is this a joke? The V8 engine is improving continuously. Node has the equivalent of ByteBuffer and for some benchmarks is on a par with java and C. For computational workloads it's 5x slower on average but mechanical sympathy is increasing here too...

Its fast enough for many domains and proficient developers are cheap and enthusiastic.

Specifically with node, a lot of the core work is in native code, not only JavaScript.

I'm not a fan of JavaScript (it's a terrible language!) but Node is enjoyable, the community is diverse and the ecosystem is iterating quickly...

For example, node.js has first class dtrace support (although the debugging, tracing and profiling tools available on the JVM are more mature in general) which I'd love to see in erlang, for example.

The JVM and tools around it are far more interesting than the java language itself.

Cheers,

Darach.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Rajiv Kurian]

Yeah Java is not the greatest language. The VM and the tool on the other hand are very mature. A lot of interesting software has been built using the hated languages (Java and C++). 

[Andrew Bissell]

The target of my joke was not meant to be JS or any specific frameworks like Node, but rather the HN community's skewed preference in favor of languages like Javascript and against Java, which seems outsized given the relative number of foibles found in each language. Maybe I've just been having too much fun following the Nashorn team's stories about trying to make sense of the hall of mirrors that is the Javascript spec. :-)

The criticism of Java-as-a-language also seems a bit overdone to me these days (insert obligatory aside about the type system here), particularly the criticism about its verbosity.  I'm inclined to withhold judgment until JDK8 hits and we see how well it gets used in the wild. Lambdas and internal iteration might improve the LOC and readability situation in Java code a lot.

--

You received this message because you are subscribed to a topic in the Google Groups "mechanical-sympathy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mechanical-sympathy/TDSanIzccLE/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to mechanical-symp...@googlegroups.com.

[Rüdiger Möller]

Skewed poll. Languages which are rarely used in commercial systems such as Python, Smalltalk or Closure of cause only have users out of love (because they program for fun).
Java on the otherhand has a huge Job market, so there are tons of developers who use Java just because they have to on their jobs ..

[Paul Houle]

I think Java is a good language,  but I think the net complexity of the ecosystem and systems built on top of is what drives developers up the wall.

The first time I saw maven,  for instance,  was a project with 25 developers and probably 45 modules,  mainly written by people who were learning lots of other things when they were writing it,  so the POM files were written by copy and paste and Googling specific questions and tweaking things until they "work".  Each and every module they were developing on was a snapshot release.

Builds sorta worked if you were in the office but I never could get the product to build when I was at home for reasons that were mysterious to me at the time.  Now I'm pretty sure that the lack of transaction semantics meant I could never get a completely consistent set of snapshots over the 30 minutes that it took to download everything -- people were changing things so fast I'd inevitably get a set of snapshots that weren't mutually compatible.

Once I got to programming on my own account,  I read the maven book cover to cover and got my build process down to the point where it's as fast as my car can drive the quarter mile.  It looks like gradle is a bit better then maven,  but the problem isn't maven per se,  it's that maven makes it possible to build really huge systems with 100s of dependencies, and the desire to "get things done" vs "sharpening the saw" leads to the thing being a big tangle that everybody is afraid to mess with because if you sneeze it might blow up the production system.

The same can be said for Spring.  Today,  I love Spring.  My first experience of it though,  was a system where the Spring files went through multiple transformations,  including one at the deployment time that unpacked a JAR,  tweaked an XML file,  and repacked the JAR.  The only 100% reliable way to integration test the product was to go through a 20 minute build process and multiple copies of the same files were distributed throughout the project so you might find out you edited the wrong file half an hour after you started...  In a context like that,  Spring seems like a bunch of "spooky actions at a distance" that are part of the problem rather than part of the solution.

Then there's the issues of IDEs.  The ability of Eclipse to do automated refactoring,  run tests in the debugger and do so many things quickly and accurate is a huge win.  Yet,  Eclipse never seems to work 100% right.  I run Windows on top (where Eclipse's UI is pretty good) but more often I run it in virtualized Linux.  I'd like to run it as a standalone X Window on the Windows desktop,  but a bug in GTK makes that impractical.  The GTK people hate Windows with a passion so that one is going to get fixed real soon.  If I run it on Linux the font colors aren't right so often I can't read the class name that the autocorrector wants to add as an import.  I turned on debug tracing because it was FUBARed two months ago,  and now I don't know how to turn it off and I'm afraid that slows the thing down.  It seems they have a wonderful algorithm for selecting which tabs are shown which always manages to hide the next tab you're going to use in the hardest place to find,  etc.

If you want to be a 1x,  never mind a 10x developer on a project like the ones above it can be pretty challenging and if you don't correctly attribute the source of your problems to team dynamics,  you could wind up blaming the language.

If you can get past the B.S. and really understand Java you find it is a great language.  I am not such a fan of Scala.  The "scala" language that most people program in is really a DSL built on top of a more primitive language,  and like any DSL written in Scala there's a definite structural instability as you move away from the beautiful code samples you see in the textbooks to real ones.

[Andrew Bissell]

It's funny, having just started in Maven and Spring after 4 years of programming Java without them, they're now the first thing that comes to my mind when I try to explain Java hate. The gobs of XML, the dead ends in tracing through code because some method call is defined in a config file somewhere, the 30 layer deep call stacks, the annoying naming of everything as a "bean" ... *these* are the kinds of things that frustrate programmers and make them dream of greener pastures -- even if there really aren't much better alternatives to these tools for their common use cases (big enterprisey projects with lots of developers).

And don't get me started on Spring's inherent hostility to immutability and final fields ....

--

[Darach Ennis]

+1. Sans, Maven + Spring + JEE java is fairly pleasant.

--

You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Rüdiger Möller]

Java bloat frameworks should be seen separate of the language. For me, I am a 20 years+ software developer and architect, and always tried to avoid these frameworks as they mostly perform poor, solve minor problems (not the ones which make up the real development costs) and often times create a lot of unnecessary complexity.

I always try to use "low tec", favour libraries instead of frameworks and keep the system as simple as possible. This resulted in clean, fast and cost-efficient systems.

Maybe I am sturdy, but what real world problem does Spring actually solve ? I never understood the motivation for this framework, but maybe (or probably) its me :-). EJB's looks even more strange to me, I can't imagine it actually helps development ;-)

Am Donnerstag, 10. Oktober 2013 23:19:00 UTC+2 schrieb Kevin Burton:

[Peter Lawrey]

IMHO migrating to Spring encourages you to use dependency injection. But I see it being mostly "stone soup" in this regard as you can do DI in plain Java without a framework. You just need the methodology.

--

[Martin Thompson]

+1 

Code can often be so much more clear with DI if a simple top level composition class is used, never mind the improvement to startup time.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Rüdiger Möller]

Agree, Google Guice is also nice for DI. However i haven't got the feeling we had groundbreaking benefits from DI, but helps keeping things clearer and more organized, sure. I can't say this for Spring (at least the XML'ish variant I've seen, they switched to Annotations in in newer releases afaik)

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Paul de Verdière]

Saying "I like Java" sounds a bit like "I like Cobol" these days but I do :)

You can write Java code and know what the bytecode will look like, how many allocations will take place etc. It's like the C language of the JVM "OS". I also like the idea of languages like Scala allowing to write concise code but I fear losing control of what the JVM will do under the covers.

I also like Java because of the powerful IDEs that help you do all the heavy-lifting. I used to code in Java in Emacs back in the day where PCs had barely enough RAM to run an IDE (eg. JBuilder), refactoring with handmade shell scripts etc. Sounds like prehistory now, definitely not an option anymore.

Maybe some of the hate for Java comes from the fact that you can't work efficiently on a non-trivial Java project with a simple editor, whereas you can do it with a Python/Javascript/HTML project.

And then, there is Maven...

I developed a severe allergy many years ago and managed to stay away from it all this time, banning it from our corporate tools. Unfortunately, it has became the norm in many open source projects, so much that knowing Maven seems to be as important as knowing Java if you want to contribute to, or even use the software. For example, http://openjdk.java.net/projects/code-tools/jmh/ : I thought the tool was interesting but the learning curve included getting proficient in Maven before being able to actually use it! I can totally imagine people having to learn both Java and Maven at the same time becoming accomplished Java haters :)

[Rüdiger Möller]

Haha, same here. however the library dependency resolvement/jar repository part of maven is awesome. I still prefer gradle or ant if possible, but maven is the de-facto standard. I'd say maven makes complex things easy and easy things complex ;-)

[Jamie Allen]

If you can get past the B.S. and really understand Java you find it is a great language.  I am not such a fan of Scala.  The "scala" language that most people program in is really a DSL built on top of a more primitive language,  and like any DSL written in Scala there's a definite structural instability as you move away from the beautiful code samples you see in the textbooks to real ones.

This is a ridiculous assertion, Paul.  I agree, Java is a great language.  Scala is far from a DSL, with immutable collections, purely asynchronous futures (since Java 6 with a specialized implementation of JSR166y cooked up by Doug Lea for us), pattern matching, for comprehensions and more.  If anything, Java's feature list for Java 8 (lambdas, defender methods, CompletableFuture, parallel collections, Optional) reflect the impact Scala has had on the ecosystem.  Where Java will continue to struggle, as it has to date, is composability - with Scala, language constructs are designed to compose into sequenced operations with clean syntax.  Java provides powerful primitives, but composing them is not its strong point.

I will warn Java developers, having played extensively with Java 8, that many are not prepared for the type system errors you are about to see with lambdas.  There is no free lunch here.  Anyone give it a whirl yet?  I also highly recommend you see my presentation about "What You Need to Know About Lambdas" - there is an older version here, but I'm giving an update as a keynote at JAXLondon in two weeks.  I have no idea about this "definite structural instability" business of which you speak - oddly, plenty of people are finding ways to use it effectively.

Just as there is a time for pipelining and imperative code, there is a time for asynchrony and paying the price of context switches.  There is also a time for immutability and pure functional styles.  Unlike Java, Scala gives you the flexibility to apply both at the appropriate time.  Java is moving in this direction as well, albeit more deliberately, so be prepared.  Learning Scala has made me a better Java developer.

[Ben Cotton]

It saddens me that we have come to a time when there may be a consensus that "People seem to hate Java"..

Despite its many (and  very real) user frustrations and its  lackings wrt accommodating specific capabilities soundly and completely, Java should be given credit for having  the ambition for at least  trying to empower (and empower safely) the programming masses.  

More than just a language that arrived at the 'right place, right time', Java was a good idea.  More data processing problems got solved (and by a lot more people) because of Java's arrival.

Remember in the very earliest Java community forums, when the original Sun engineers always signed their support respones with the closing "Have fun!" ?   

For me, Java is (and always has been) fun.  Pervesely (but admit it, you may feel this too) Java can even be fun when it is frustrating.  There is at least a comaraderie of specific frustration(s) with Java (hence oneof my attractions to this 'mechanical sympathy' discussion) .  That comaraderie (though frustrating)  is fun.  

Could Java possibly even be fun  when you seem to hate it?  :-)

> Jamie Allen wrote:

> [...] Java is a great language

+1

On Saturday, October 12, 2013 11:43:59 AM UTC-4, Jamie Allen wrote:

If you can get past the B.S. and really understand Java you find it is a great language.  I am not such a fan of Scala.  The "scala" language that most people program in is really a DSL built on top of a more primitive language,  and like any DSL written in Scala there's a definite structural instability as you move away from the beautiful code samples you see in the textbooks to real ones.

[kedar mhaswade]

Is it possible that those who hate a language actually hate its (and its ecosystem's) bad parts and those who love it love its good parts (and there's a reasonable consensus on what is good and what's bad)?

Alan Perlis once said (to have said) that there's no point in learning a (programming) language if it does not change the way you think. I seem to understand what he meant by that. Maybe the same is not happening with a lot of people who pick up Java with/without prejudice from a previous language, perhaps they are expecting to find their previous language's "comfort" in Java's look and feel?

I was told by a master programmer to learn as many languages as I can. I believe that to be a sensible advice. Being able to program in the spirit of a language (even when it's trying to change just like our "self" changes) is perhaps very hard. But I guess it's safe to say that for any language one can always find programmers who get its spirit much better than oneself.

--

You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Rüdiger Möller]

After ignoring Scala for a while your promotion at least got me into reading the spec :-) . First impression is, its a beautiful language, however i doubt it will suit the masses. Mid to low end programmers like verbosity. I doubt they'll master the pure (math-agebra-alike) syntax of this language. Another issue is imo the absence of fully-controllable primitives (didn't figure out exactly how Scala deals with that). If it comes to mechanical sympathy and you go down to the nanos, nothing beats primitives. Checked some benchmarks, however frequently the Java comparision implementation turned out to be a from Scala-to-Java port, but if you go for max performance (which ofc is necessary in <1% of the code base) you absolutely won't use high level collections and autoboxing stuff but mostly rely on plain primitive arrays and values.

I'd predict it will gain traction in the academic space and create a stable but not-too-big community. I would not expect it to get main stream, which will limit the amount of commercial projects built with Scala (in turn limiting the number of attracted programmers). Akka might be a big plus if the number of cores increases and the promise of effective paralellization hold true (I am sceptic about that).

-Rüdiger

Am Samstag, 12. Oktober 2013 17:43:59 UTC+2 schrieb Jamie Allen:

If you can get past the B.S. and really understand Java you find it is a great language.  I am not such a fan of Scala.  The "scala" language that most people program in is really a DSL built on top of a more primitive language,  and like any DSL written in Scala there's a definite structural instability as you move away from the beautiful code samples you see in the textbooks to real ones.

[Jamie Allen]

Rüdiger - I agree, there is a time for primitives and a time for abstractions.  I would never say people should not use Java, or any tool which might be better suited to their problem.  The power of the polyglot JVM is that we can choose whether Java/Scala/Clojure/JRuby/etc best fits your issue, and hopefully have interoperability that is not too painful between them.  Storm, a Clojure-based library for handling streaming data, became 3x faster by leveraging the Disruptor in v0.7.  We all benefit by leveraging Martin's mechanical sympathy concepts.

Scala's adoption in the non-academic world has been reasonably strong, actually.  I think it's highly unlikely that Scala will displace Java, but I'm happy to see the progress in language evolution taking place in Java because Scala and other such languages are pushing the envelope.

Akka has a Java API, as does Play Framework.  I also agree about your skepticism of parallelization - it will be interesting to watch how much parallelism and fork/join will change with the advent of "many-core."  Doug Lea says in their benchmarks they saw throughput level off when recursive tasks were forked beyond 20 cores.  I'm hopeful that the work of Martin, Gil and the like will lead to us having the hardware affinity on the JVM to "cluster" the cores we leverage by a thread pool to not be wasteful in how we expand parallel execution of a task.

[pron]

On Monday, October 14, 2013 8:06:05 AM UTC+3, Jamie Allen wrote:

 Doug Lea says in their benchmarks they saw throughput level off when recursive tasks were forked beyond 20 cores. 

Can you please provide a reference? 

[Jamie Allen]

Future of the JVM talk I moderated at PhillyETE in April, 2013.  He says it at the 7 minute mark, but it's actually specific to object references, not primitives.

[pron]

Thank you. The reason I asked is because I do a lot of fork/join work, and I found this surprising, especially if Doug Lea said it. Actually, Doug Lea discusses boxing in that segment. He says that we can sort a billion ints and scale perfectly in the number of cores, but if we try to do it with Integers, we we hit scaling limitations at 20 cores: "Why? locality; traffic; cache". To the best of my knowledge, there aren't any known scaling limitations to fork/join, other than the time it takes to start up a computation and get all the cores humming, which doesn't quite scale linearly.

On Monday, October 14, 2013 11:18:44 PM UTC+3, Jamie Allen wrote:

Future of the JVM talk I moderated at PhillyETE in April, 2013.  He says it at the 7 minute mark, but it's actually specific to object references, not primitives.

On Monday, October 14, 2013 7:19:43 AM UTC-7, pron wrote:

[Jamie Allen]

That's a fair clarification.  I don't want to put words in Doug's mouth, but I did not take his explanation to mean that they were performing the boxing at the time of the sort.  My interpretation was that the sorting of an array of primitive ints (since they couldn't be in a Java collection) would scale linearly with the number of cores.  The boxed Integers would not beyond 20 cores, but he doesn't specify if those are in an array or in a array-based (or non array-based) Java collection. I'd like to drum up some numbers or look at Doug's tests.

Tough to say.  I'll ask him for a clarification.

[pron]

I assume that in both cases he was talking about arrays, and that the boxing wasn't being done at the time of the sort, but, as you say, the problem was the pointer-chasing (locality), as he was talking about the need for packed struct arrays on the JVM. If you don't have locality, you'll get a lot of cache misses which will saturate the bus and inhibit scaling no matter how many cores you have.

On Tuesday, October 15, 2013 3:18:17 AM UTC+3, Jamie Allen wrote:

That's a fair clarification.  I don't want to put words in Doug's mouth, but I did not take his explanation to mean that they were performing the boxing at the time of the sort.  My interpretation was that the sorting of an array of primitive ints (since they couldn't be in a Java collection) would scale linearly with the number of cores.  The boxed Integers would not beyond 20 cores, but he doesn't specify if those are in an array or in a array-based (or non array-based) Java collection. I'd like to drum up some numbers or look at Doug's tests.

Tough to say.  I'll ask him for a clarification.

On Monday, October 14, 2013 2:54:29 PM UTC-7, pron wrote:

[Jamie Allen]

Heard back from Doug.  Here's what he had to say:

Some of the tests are in with our misc perf tests:
 http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/
See BoxedLongSort vs ScalarLongSort
The checked in versions haven't been updated for JDK8 yet though.

They test arrays of longs vs arrays of Longs.

The main difference vs sequential is that in seq, boxing adds
only indirection overhead, but in parallel, also locality:
the Long referenced from an array slot is likely elsewhere, and
getting it worsens cache pollution/thrashing among cores.
By a lot.

Were you seeing linear scaling in your usage of F/J with arrays complex objects as opposed to primitives?  It would be interesting to compare the tests.

Thanks!

[pron]

On Wednesday, October 16, 2013 6:59:17 AM UTC+3, Jamie Allen wrote:

Were you seeing linear scaling in your usage of F/J with arrays complex objects as opposed to primitives?  It would be interesting to compare the tests.

Complex objects (POJO refs)? That would be impossible. You will saturate the bus.

[Vladimir Rodionov]

Java is my bread and butter.  It feeds me and my whole family.

[Gil Tene]

As Jamie notes, this is exactly what we seek to address with StructuredArray.

[Remi Forax]

On 10/21/2013 05:03 PM, Gil Tene wrote:
> As Jamie notes, this is exactly what we seek to address with
> StructuredArray.

or array of value type ...

R�mi

[Martijn Verburg]

Speaking of which - please save the date for the inaugural Adopt OpenJDK 1.5 day mini-conference/workshop on the weekend before FOSDEM (last 2 days of Jan 2014).  We're going to gather folks together to discuss Java 9 features and want to include people from outside the core OpenjDK companies (Oracle, IBM, RedHat etc).

Cheers,
Martijn

On 21 October 2013 22:30, Remi Forax <fo...@univ-mlv.fr> wrote:

On 10/21/2013 05:03 PM, Gil Tene wrote:

As Jamie notes, this is exactly what we seek to address with StructuredArray.

or array of value type ...

Rémi

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.