Interesting rant about Scala's issues

w0rp devw0rp at gmail.com
Fri Apr 4 01:00:08 PDT 2014


On Friday, 4 April 2014 at 07:43:18 UTC, Bienlein wrote:
> On Thursday, 3 April 2014 at 01:55:48 UTC, Andrei Alexandrescu
> wrote:
>> A lot of them could apply to us as well.
>>
>> https://www.youtube.com/watch?v=TS1lpKBMkgg
>>
>>
>> Andrei
>
> He's got a point in mentioning things like "def equals(x: Any): 
> Boolean" and "def compare(x: T, y: T): Int" (although the 
> latter is not the worst problem I can think of). But the real 
> message is to me what is said starting from 24:20:
>
> "There remain those periodic stepwise jumps in performance 
> taking place in the compiler. ... There is a factor of 10 lying 
> around. It's that bad.
>
> It's so hart to pinpoint what is doing what and why that ain't 
> nothing possible to modify. You can't make it fast if you can't 
> change it."
>
> So build time performance problems in Scala is not simply 
> because the language has so many more features than Java. There 
> are real problems in the compiler. What was done in D was to 
> "stabilize" D and call it D1 and then start on D2. I think this 
> was a wise thing to do. Maybe for the Scala compiler guys it's 
> time to
> stabilize Scala and call it Scala1 and start with Scala2.

Yeah, generally the message I was getting was that you should be 
fighting against piling on new features, fighting against 
inelegant hacks for performance, and working on improving the 
things that you have.

It's like with his argument for compare. Suppose you had a 
typesafe enum which was tri-state. Like a type class. Less, 
Equal, More. (Basically 'Ordering' from Haskell, though without 
dumb unreadable abbreviations.) You get programs which are more 
obviously correct, and there's an obvious efficiency gain to be 
had there. If you can prove that your values are only Less, 
Equal, or More, you could represent that with exactly -1, 0, 1 
internally and then it would be obviously better than the 
apparently faster C-like thing.

I think this is a really interesting argument. Don't write ugly 
things to get performance. Instead write obviously correct things 
and then make obvious optimisations. This argument makes me think 
a lot about component programming and then optimising that after 
you can prove interesting things about it, like inlining lambdas, 
etc.


More information about the Digitalmars-d-announce mailing list