Coda Hale on Scala

[Simon Ochsenreither]

Hi,

although I think many people are already tired of it, I just drop this link to a text written by Coda Hale:

https://gist.github.com/1406238

It is a great piece of criticism and insanely helpful to improve the language and the libraries in the short term, unlike some stuff seen before.

Thanks and bye,

Simon

[Moandji Ezana]

He put that email in context in a blog post: http://codahale.com/the-rest-of-the-story/

Moandji

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/pt4ZyVNOcO8J.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Simon Ochsenreither]

Ah ok. Thanks.

Didn't realize it was leaked, private mail. :-/

[Dianne Marsh]

Ouch on the leaked private email.

Dianne

On Nov 30, 10:38 am, Simon Ochsenreither

[Gabriel Claramunt]

See also the official Yammer position:

http://eng.yammer.com/blog/2011/11/30/scala-at-yammer.html

[Moandji Ezana]

Tempest in a teapot. I don't get these language debates that have the same tone as Android vs. iOS debates, each side trying to prove its superiority. Especially in a supposedly polyglot world, what's the point?

Moandji

On Thu, Dec 1, 2011 at 1:07 PM, Gabriel Claramunt <gabriel....@gmail.com> wrote:

See also the official Yammer position:

http://eng.yammer.com/blog/2011/11/30/scala-at-yammer.html

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

[Jan Goyvaerts]

Everybody enjoys a good fight ! :-P

It's especially stupid since this is all basically the same : Programming the JVM so other application can use your creations too. Regardless the language you and them are using. Sad really...

[Ricky Clarkson]

The problem is, I might end up maintaining the rubbish you write in language X and that language might not lend itself particularly well to maintenance.

So, it's reasonably important that the status quo be a good language, and of course everyone has a different opinion on what forms a good language.

I imagine that if programmers always had a free choice about what language to use, a lot of these discussions would disappear.

---

From: Moandji Ezana <mwa...@gmail.com>

Sender: java...@googlegroups.com

Date: Thu, 1 Dec 2011 13:25:42 +0200

To: <java...@googlegroups.com>

ReplyTo: java...@googlegroups.com

Subject: Re: [The Java Posse] Re: Coda Hale on Scala

[Jan Goyvaerts]

Do other people share the experience of "don't use class X because the Java equivalent is faster" ?

[Dick Wall]

Honestly, no. I use Scala pretty much exclusively now for all my various jobs, and I write idiomatic Scala using the collections classes very heavily, often for some pretty hairy number crunching. So far, performance has yet to be a problem on any code that couldn't be better fixed by reexamining the algorithms (for example, on a recent task, we got a 10x speed up by re-implementing the algorithm from a rather complex tree to a binary searchable flat datastructure (actually a vector - a gift from the gods in Scala), both used the standard Scala collections, one was just a better way to write it than the other). Falling back on Java collections has never been necessary for me, and we have had several real world benchmarks where idiomatic Scala ran 20-30% faster than some C++ prototype code (that was written to be optimal as far as possible). 

I don't doubt that Yammer has some good points, but they have not all been consistent with my experience to date. They do mention tail recursion instead of for loops as a way of optimising, and I won't say that I consciously use that, but I am rather fond of recursion and tend to use it, not always because I want or need the performance, but because it makes a nice solution. Stick an @tailrec in front of the function, and you mark your clear intent to people reading the code, and also ensure that it will indeed be tail call optimized. Incidentally, in my example above, the binary search did use recursion and was tail call optimized. It was also very readable and a natural way to do it.

Another way to look at it is this. We (locus development) deal with very large data. Any data access, particularly to a relational DB, is so much slower than just about any calculation we do (apart from some of the really hairy linear algebra or monte carlo stuff) that it is pretty meaningless to worry about optimizing it. Likewise for web or web service stuff. All this, and we are a pretty calculation intensive problem domain. I guess I don't know what Yammer is doing calculation wise, but based on our experience I am amazed that web/IO/database is not dwarfing their other performance concerns.

Dick

[Dick Wall]

Doh - I hit the wrong reply button again. The above was in response to the question:

[Dick Wall]

In fact, I would go a step further on this. Really knowing the performance characteristics of the very rich selection of collections in Scala is one of the best ways I can think of to improve your Scala proficiency and the efficiency of your applications. I would find it hard to go back to Java collections alone at this point - I only really used ArrayList and ConcurrentHashMap there anyway. Vector in particular is an incredible, immutable datastructure. That said, I do still use the Guava map maker (with a nice Scala wrapper) as I have yet to find a better solution for thread safe, performant, key based caching on Scala (using a synchronized map of futures works, but it's a bit clunky compared with mapmaker).

[Erlend Hamnaberg]

Speaking of performance characteristics:

I find this useful:

http://www.scala-lang.org/docu/files/collections-api/collections_40.html

--

Erlend

On Thu, Dec 1, 2011 at 8:47 PM, Dick Wall <dick...@gmail.com> wrote:

In fact, I would go a step further on this. Really knowing the performance characteristics of the very rich selection of collections in Scala is one of the best ways I can think of to improve your Scala proficiency and the efficiency of your applications. I would find it hard to go back to Java collections alone at this point - I only really used ArrayList and ConcurrentHashMap there anyway. Vector in particular is an incredible, immutable datastructure. That said, I do still use the Guava map maker (with a nice Scala wrapper) as I have yet to find a better solution for thread safe, performant, key based caching on Scala (using a synchronized map of futures works, but it's a bit clunky compared with mapmaker).

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/3pa6x1T3L48J.

[Reinier Zwitserloot]

I'm a little surprised the discussion has moved to the in my opinion relative strawman of collections API performance. As Dick said, the golden rule of performance optimization is to FIRST make sure you're using the most efficient algorithm possible because that will always outpace whatever performance suckiness you're facing from your language / VM / library (unless you're using a library with a known inefficient algorithm, but, boy, then you really picked a sucky library to roll with!). Even if scala's collection API performance is bad, that can be fixed.

What I find far more condemning, in fact, THE 'this is the true essence of why scala sucks, at least for us' line in it, is the scala community.

This line is perhaps not exactly fair to the community at large, but it felt like it hit the nail on the head:

Quote:

As my team navigated these waters, they would occasionally ask things
like: "So this one guy says the only way to do this is with a bijective map on a
semi-algebra, whatever the hell that is, and this other guy says to use a
library which doesn't have docs and didn't exist until last week and that he
wrote. The first guy and the second guy seem to hate each other. What's the
Scala way of sending an HTTP request to a server?"

That. That right there, that's gotta hurt. And to be perfectly honest I think this line of complaining is on to something. The gist is: The community just doesn't work for your average business - they have vastly different concerns, make assumptions about my knowledge of type systems and academic programming arcana that are way, way off, get cocky when it becomes clear I don't have their grasp of terminology and concepts, do not care about the things I care about, I don't care about the things they DO care about, and any foray into google or other search-for-help channels is 90%+ certain to lead in a big headache and no answer to show for it. We gotta fend for ourselves, there's no real way of doing things that is feasible for a business like us to maintain, which means even if somehow seasoned scala developers were beating the door down to our recruitment department, the learning curve for them to get up to speed on our code base will always be far, far larger vs. java.


These questions spring to mind.

(A) Is this complaint correct? (My guess: Yes, it is, very).

(B) If it is, how bad is that for scala's future (My guess: Very bad).

(C) Can it be fixed? (My guess: Probably not - I have no idea where to even start).

(D) Is this anybody's 'fault' - is there a lesson to be learned here for future languages? (My guess: Oh, I don't even know where to start).


To reiterate, I don't think this is just about a few bad apples that are turning droves of would-be enthusiasts AWAY from scala due to their behaviour, i.e. this is not about Tony Morris, Kevin Wright, and a select few other well known let's say, uh, 'enthusiastic' scala supporters. Coda's complaint goes a lot deeper than that.


In regards to question D - there's a chance that Scala's kind of complexity is the kind that attracts this community, and it's obvious to me that a community's rough outline is decided by the early adopters. Java doesn't get away scot free here - one very stupid side-effect that's IMO _entirely_ the fault of the java community is badly designed API. Pick any random java library and the API is likely a complete clusterfrak that any half-brained java enthusiast with some common sense and a day or two to think it through can do way, way, better. You know, avoid the FoobarFactoryFactoryGenerator and 25 separate convoluted XML files. Still, no matter how annoying it is to work with this (and I do see this changing, very slowly), you can go out there, ask for help, find examples, figure it out, and move on with your day. Also, even a crappy standard is still a standard and probably beats 15 novel and creative but ultimately vastly different ways of doing it.

[Cédric Beust ♔]

On Fri, Dec 2, 2011 at 8:25 PM, Reinier Zwitserloot <rein...@gmail.com> wrote:

To reiterate, I don't think this is just about a few bad apples that are turning droves of would-be enthusiasts AWAY from scala due to their behaviour, i.e. this is not about Tony Morris, Kevin Wright, and a select few other well known let's say, uh, 'enthusiastic' scala supporters. Coda's complaint goes a lot deeper than that.

There are actually discussions happening right now about moderating the Scala mailing-lists. I think it would do a ton of good to the community (I wonder why it wasn't done earlier).

-- 

Cédric

[Ricky Clarkson]

I think this may be overstating it. Look at some Scala questions on StackOverflow and you'll find excellent answers. Argumentative forums are argumentative.

---

From: Reinier Zwitserloot <rein...@gmail.com>

Sender: java...@googlegroups.com

Date: Fri, 2 Dec 2011 20:25:09 -0800 (PST)

To: <java...@googlegroups.com>

ReplyTo: java...@googlegroups.com

Subject: [The Java Posse] Re: Coda Hale on Scala

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/RAuhHDYZye8J.

[Simon Ochsenreither]

Just my 2 cents:

Theoretical talks about the "academic behavior" outweight the actual occurrences of "academic behavior" by a few magnitudes probably.

It is impressive how much text can be written without checking any facts.

Have a nice day,

Simon

[Dick Wall]

"So this one guy says the only way to do this is with a bijective map on a
semi-algebra, whatever the hell that is, and this other guy says to use a
library which doesn't have docs and didn't exist until last week and that he
wrote. The first guy and the second guy seem to hate each other. What's the
Scala way of sending an HTTP request to a server?"

>That right there's gotta hurt

Well, not really, and in my opinion this is a very easy issue to dispel. I have never talked, nor heard anyone talk, about a bijective map on semi-algebra, and I have been using Scala for 3+ years now. Next up, there are plenty of libraries in any language (Java included) with insufficient documentation, just use a different library. There are enough to choose from, for one thing you have the full choice of Scala *and* Java libraries to choose from. Case in point, the last statement displays some surprising ignorance. The "Scala" way of sending an HTTP request to a server, well you could start by taking your pick of these two:

val url = new URL(urlString)

val body = url.openStream

(i.e. the "Java" way - why fix what's not broke) or

val source = Source.fromURL("http://www.google.com")

Take your pick, but when trying to raise issues with the inherent complexity of Scala, I think you need to choose a different example. These seem pretty easy and self explanatory (and in the case of the first one, very familiar to any Java developer) to me.

Dick

[Simon Ochsenreither]

Hi Dick,

isn't URL like its cousins Date/Calender/Formatter one of the common examples of really broken code?

Bye,

Simon