Yammer moving away from Scala

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You're assuming intellectual honesty on behalf of the claimant. Given
that the position held by the potential student is already bogus, all I
can do is wish you the best in the battle ahead of you.

On 12/04/2011 01:36 AM, Rex Kerr wrote:
> Why don't we try explaining things in a helpful and friendly way, instead
> of deleting useful things that might require explanation?
>
> (I would dump /:\, though, as it serves little purpose. "fold" is clearer
> and faster to type (for most people), and /:\ suffers from
> which-goes-on-what-side ambiguity. (Especially given that people typically
> start with left folds to avoid stack overflow.))
>
> --Rex
>
> On Fri, Dec 2, 2011 at 4:55 PM, Simon Ochsenreither <
> simon [dot] ochsenreither [at] googlemail [dot] com> wrote:
>
>> I know, it sounds lame ... but can we get rid of /:, :\ and /:\?
>>
>> I'm sick and tired that the conclusion of “language experts” that Scala
>> sucks is based to 90% on those three method names.
>>
>

CAJf6Usga8BdLLjiRWQrsbFTW5o1uBgH58v9kyRAeKp3k8P3r_w [at] mail [dot] gmail [dot] com" type="cite">

Are you going to let wrong people affect the API of scala? It can only get better from here!

On Dec 3, 2011 7:55 AM, "Simon Ochsenreither" <simon [dot] ochsenreither [at] googlemail [dot] com" rel="nofollow">simon [dot] ochsenreither [at] googlemail [dot] com> wrote:

I know, it sounds lame ... but can we get rid of /:, :\ and /:\?

I'm sick and tired that the conclusion of “language experts” that Scala sucks is based to 90% on those three method names.

On 03.12.2011 14:24, Peter C. Chapin wrote:
> definition of "private." On the other hand seeing all that weird looking
> stuff in the scaladocs can also be motivational. It goes like this:
>
> 1. What the $%&%$ is that?
> 2. Hmm.
> 3. Google/Books/Papers/Tutorials
> 4. Interesting.
> 5. Cool!

Actually that was sort of how it was for me when I first discovered
Scala, and was part of what attracted me to it. All that new weird,
"complex" stuff seemed like a magical forest waiting to be explored. It
brought the fun back in programming, and I hadn't quite felt that way
since I learned assembly in my late teens.

Wow. That sounded fantastically nerdy. :)

Knut Arne Vedaa

There are far less condescending ways to make a point.  Messages like this exchange will be moderated for 'tone'.   You'll be given an opportunity to rephrase a post to get your point across.  Different opinions are welcome on the list.  Veiled insults are not.  No matter who they are aimed at.

Yes, of course it would. But the motivation was not the point of view but the attitude with which it is displayed.

Regards,

Roland

Am Samstag, 3. Dezember 2011 23:50:00 UTC+1 schrieb John Nilsson:

If you argue for being tolerant against people with a different view point I guess it would be incredibly arrogant to ban people with the "wrong" view point, wouldn't it?

BR,
John

Den 3 dec 2011 20:23 skrev "Kenneth McDonald" <ykke [dot] [dot] [dot] [at] gmail [dot] com>:

The point that he makes that (to me, at least) resonates most strongly relates to the Scala community. I don't know how to fix it, but we really do need to fix it.

It must be possible to create a supportive and welcoming environment for people coming to the language. Right now, the Scala community is nothing like that.

Sadly, I must agree. However, I think it's a fairly small number of people who give this impression. I have posted many inane, newbie questions and received polite, thorough responses from people who I'm sure have better things to do with their time.
So I'm going to call what you've pointed out the "FP" response, though it's not limited to FP, and certainly many hardcore FP-ers don't share this mindset. Because Scala is good at supporting different programming paradigms (FP, Actors, whatever), it can attract people who are locked into those mindsets; and if some of those people decide to move their attitude to the mailing lists, the result is pretty nasty.
I can think of only two responses. I'm reluctant to even suggest the second, but think it must be said:
1) Have Martin periodically post a message reminding everyone that Scala is a multiparadigm language, and asking for tolerance for other points of view.
2) If necessary, banning people from a list. I don't like it, but if the atmosphere on the lists might cause Scala to fail, I think it's worth considering.
Ken

 

On Wed, Nov 30, 2011 at 11:45 PM, Raoul Duke <raould [at] gmail [dot] com> wrote:

>> Personally, I'm strongly in favour of Scala. I'd rather stick pins in my
>> eyes than use Java and I don't see any credible choice other than Scala. But
>> my case is severely weakened by by the squabbles, flame wars and just plain
>> rudeness that constantly breaks out here.

i wonder to what degree Scala is powerful enough to let various
disparate communities think they can use it, and then they come to
loggerheads on the lists? Like, there's the "i wish i were doing
haskell" crowd that will poo poo you if you don't already know the
typeclassopedia by heart; there's the performance nuts; there's the
people who really just kinda want a slightly less painful java but not
much more than that; there's yadda yadda yadda.

with java nobody is under any mistaken impression that it is or can be
anything other than plain old java. if you add on something like guava
or apache functional stuff you know you are out in la la land and your
noize only shows up on those mailing lists for only like-minded
suckers to read.

That I not true, I got flamed on SO for using obscure language features like instance initializers and qualified "this" when some guy wanted the golfiest snippet to traverse a list + this in pure Java:

for (X x : new ArrayList<X>(xs){{ add(EnclosingClassX.this); }}) {



    // Profit!
}

So apparently you can be one of the weird guys in the Java world as well.

 

fun.

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

On Wed, Nov 30, 2011 at 20:11, Aleksey Nikiforov wrote:
> On Wed, Nov 30, 2011 at 3:43 PM, Jesper Nordenberg
> wrote:
>>
>> Aleksey Nikiforov skrev 2011-11-30 21:27:
>>
>>> When I first dicovered that for loops were not optimized I was surpised.
>>> When I discovered a resistance to optimizing them I was shocked. The
>>> decision to do nothing about for loops baffles me to this day.
>>
>>
>> For comprehensions are just syntactic sugar. Optimizing just them is not
>> very useful, instead effort should be put into generic optimization of HOF's
>> (and other inlining).
>>
>> /Jesper Nordenberg
>
>
>
> This is exactly the thinking that baffles me. There are for-loops in Java.
> Not comprehensions, LOOPs. Anyone coming from Java will expect for LOOPs or
> simlar functionality.
>
> It does not matter to me if it is a syntactic sugar or if they are
> comprehensions. What matters to me is to be able to write the code:
>
> var sum = 0; for (i <- 0 until array.length) sum += array(i)

The body of the loop compiles (with -optimize) to:

59: iload 8
61: iload_3
62: if_icmpne 93
(last iteration code elided)
93: iload 8
95: istore 6
97: aload 5
99: aload 5
101: getfield #50; //Field scala/runtime/IntRef.elem:I
104: aload_0
105: getfield #11; //Field XXS$$array:[I
108: iload 6
110: iaload
111: iadd
112: putfield #50; //Field scala/runtime/IntRef.elem:I
115: iload 8
117: aload 7
119: invokevirtual #53; //Method scala/collection/immutable/Range.step:()I
122: iadd
123: istore 8
125: goto 59

Java's

4: iload_2
5: aload_0
6: getfield #2; //Field array:[I
9: arraylength
10: if_icmpge 28
13: iload_1
14: aload_0
15: getfield #2; //Field array:[I
18: iload_2
19: iaload
20: iadd
21: istore_1
22: iinc 2, 1
25: goto 4

I had noticed before this strange characteristic of Scala bytecode of
breaking loop bodies in two parts, and jumping between them. I suppose
that's probably related to the inlining of closures, but, still, this
unnecessary jumping can't possible be good.

Anyway, notice how lines 104-111 in Scala are the same as lines 14-20
of Java. Where it differs is that Scala is using IntRef all over the
place. That's sum stored as IntRef on slot 5, on the heap. And look at
lines 93, 95 and 108: slot 8 is "i", but it reads it on 93, stores on
slot 6 on 95, then do the arithmetic, and next restores it from slot 6
on 108! Slot 6 need not exist at all, and it could have just read from
slot 8 at that point!

And on the elided part, it does this as it returns:

84: putfield #50; //Field scala/runtime/IntRef.elem:I
87: aload 5
89: getfield #50; //Field scala/runtime/IntRef.elem:I
92: ireturn

I even understand why it isn't optimizing this, but these lines would
be completely unnecessary if "sum" was on the stack in first place!

I'm impressed by the job done to inline the closure, but then it seems
to punt out on a minor optimization such as getting rid of IntRef. So
close, yet still so far...

Here are the test classes if anyone wants to look into it:

class XXS {
private val array = Array.range(0, 100)
def tst = { var sum = 0; for (i <- 0 until array.length) sum +=
array(i); sum }
}

class XXJ {
private int[] array;

XXJ() {
for (int i = 0; i < 100; i++)
array[i] = i;
}

int tst() {
int sum = 0;
for (int i =0; i < array.length; i++)
sum += array[i];
return sum;
}
}

>
> And have it work as fast as possible. Scala fails that expectation. It fails
> it so much that this is one of the most frequent questions on stack
> overflow. Also, it appears to be the number 1 on the list of problems with
> Scala as viewed by the employee at Yammer who wrote the email:
>
> 1. Don't ever use a for-loop.
>
> So, they were looking for loops as well, not comprehensions. Why not send
> them an email and ask them if perhaps they were "talking about for
> comprehensions or just foreach"?! If you think I was overreacting, I would
> LOVE to see their response.
>
>
> It is nice to have for-comprehensions optimized. But I really do not care
> about for-comprehensions. I want something that looks like for loops and
> works like for loops. 99% of my code uses emulated for-loops via
> while-loops. It's painful and error prone, so I take this issue very
> personally.
>
> Not providing proper for-LOOPs is akin to saying: Scala is not meant for the
> applications that require for-loops. Which sends the message that Scala is
> not meant for performance-sensitive applications. So guess what, the folks
> at Yammer got the message and went back to Java.
>
> You can tell me that they are comprehensions, or a more general case should
> be optimized. But I do not care about those uses at all. Ranges and closures
> can never be optimized to the level of while loops. And I need the LOOPs.
> And so do many other people not interested in functional aspects of Scala.
>

On Wed, Nov 30, 2011 at 3:43 PM, Jesper Nordenberg <megagurka [at] yahoo [dot] com> wrote:

Aleksey Nikiforov skrev 2011-11-30 21:27:

When I first dicovered that for loops were not optimized I was surpised.
When I discovered a resistance to optimizing them I was shocked. The
decision to do nothing about for loops baffles me to this day.

For comprehensions are just syntactic sugar. Optimizing just them is not very useful, instead effort should be put into generic optimization of HOF's (and other inlining).

/Jesper Nordenberg

This is exactly the thinking that baffles me. There are for-loops in Java. Not comprehensions, LOOPs. Anyone coming from Java will expect for LOOPs or simlar functionality.

It does not matter to me if it is a syntactic sugar or if they are comprehensions. What matters to me is to be able to write the code:

var sum = 0; for (i <- 0 until array.length) sum += array(i)

And have it work as fast as possible. Scala fails that expectation. It fails it so much that this is one of the most frequent questions on stack overflow. Also, it appears to be the number 1 on the list of problems with Scala as viewed by the employee at Yammer who wrote the email:

1. Don't ever use a for-loop.

So, they were looking for loops as well, not comprehensions. Why not send them an email and ask them if perhaps they were "talking about for comprehensions or just foreach"?! If you think I was overreacting, I would LOVE to see their response.

It is nice to have for-comprehensions optimized. But I really do not care about for-comprehensions. I want something that looks like for loops and works like for loops. 99% of my code uses emulated for-loops via while-loops. It's painful and error prone, so I take this issue very personally.

Not providing proper for-LOOPs is akin to saying: Scala is not meant for the applications that require for-loops.

Which sends the message that Scala is not meant for performance-sensitive applications. So guess what, the folks at Yammer got the message and went back to Java.

You can tell me that they are comprehensions, or a more general case should be optimized. But I do not care about those uses at all. Ranges and closures can never be optimized to the level of while loops. And I need the LOOPs. And so do many other people not interested in functional aspects of Scala.

My understanding is that if -optimize worked so well, it would be enabled by default. If it's not the default, there are good reasons for it.

On Wed, Nov 30, 2011 at 3:35 PM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Wed, Nov 30, 2011 at 9:27 PM, Aleksey Nikiforov <lexn82 [at] gmail [dot] com> wrote:

When I first dicovered that for loops were not optimized I was surpised. When I discovered a resistance to optimizing them I was shocked. The decision to do nothing about for loops baffles me to this day.

That's simply not true. The position is that we should not do isolated ad-hoc fixes but go to the root of things. Scala's overall optimizations need to be good enough that they can optimize standard for-loops. And they are already very close of doing this. I wonder whether Yammer ever tried compiling with -optimize.
Cheers
 -- Martin

I used to religiosly compile all my code with -optimize. However at some point I found that it was inlining excessively and resulted in slower bytecode. I have not tried -optimize for a long time. My understanding is that if -optimize worked so well, it would be enabled by default. If it's not the default, there are good reasons for it.

On Wed, Nov 30, 2011 at 3:35 PM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Wed, Nov 30, 2011 at 9:27 PM, Aleksey Nikiforov <lexn82 [at] gmail [dot] com> wrote:

When I first dicovered that for loops were not optimized I was surpised. When I discovered a resistance to optimizing them I was shocked. The decision to do nothing about for loops baffles me to this day.

That's simply not true. The position is that we should not do isolated ad-hoc fixes but go to the root of things. Scala's overall optimizations need to be good enough that they can optimize standard for-loops. And they are already very close of doing this. I wonder whether Yammer ever tried compiling with -optimize.
Cheers
 -- Martin