Re: Interesting rant about Scala's issues
On 4/9/2014 1:58 PM, Nick Sabalausky wrote: Tooling is certainly very important, but until someone comes up with a substitute for programming languages that actually *works well* as a *complete* substitute (decades of attempts, still zero successes), then unlike tooling, the language is still the one thing that's absolutely *mandatory*. Yeah, I've seen the programming without programming tools come and go over the decades. I'm not holding my breath. To me, they always seem like learn without effort and get fit without exercise pitches.
Re: Interesting rant about Scala's issues
On 03/04/2014 02:55, Andrei Alexandrescu wrote: A lot of them could apply to us as well. https://www.youtube.com/watch?v=TS1lpKBMkgg Andrei One interesting point near the end. He glossed over it since he was running out of time, but this was in the slides: What I'm after * I don't need a programming language. * I need a coherent set of tools for creating software. A language is incidental. I totally agree. Sure, the language may be the core, and one of the most important aspects, but the rest of the tool-chain is extremely important too. I don't think everyone in the D community (and outside it too) fully stands behind this idea. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Interesting rant about Scala's issues
On 4/9/2014 4:21 PM, Bruno Medeiros wrote: Sure, the language may be the core, and one of the most important aspects, but the rest of the tool-chain is extremely important too. I don't think everyone in the D community (and outside it too) fully stands behind this idea. I think a big part of that is because there's been a lot of work done using languages where good tooling is used as a substitute for a good language (*cough*java*cough*) - to predictably painful results. Tooling is certainly very important, but until someone comes up with a substitute for programming languages that actually *works well* as a *complete* substitute (decades of attempts, still zero successes), then unlike tooling, the language is still the one thing that's absolutely *mandatory*.
Re: Interesting rant about Scala's issues
On Saturday, 5 April 2014 at 18:47:50 UTC, Walter Bright wrote: On 4/5/2014 10:10 AM, Timon Gehr wrote: On 04/03/2014 04:45 AM, Walter Bright wrote: On 4/2/2014 6:55 PM, Andrei Alexandrescu wrote: A lot of them could apply to us as well. https://www.youtube.com/watch?v=TS1lpKBMkgg at about 44:00: I begged them not to do them [AST macros]. :-) (This is a misquote.) Yeah, I should have been more accurate. In response to a question about macros reflection: I begged them not to, not to just export the compiler to I begged them I begged them not to do it. Which is a very different statement.
Re: Interesting rant about Scala's issues
Dicebot, el 7 de April a las 12:04 me escribiste:
On Monday, 7 April 2014 at 10:07:03 UTC, Regan Heath wrote:
Got a DIP/spec/design to share?
R
I think biggest mistake of D enums is merging constants and actual
enumerations into single entity which has resulted in weak typing of
enumerations.
Yeah,
enum E { A = 1, B = 2 }
is the same as:
struct E { immutable A = 1, B = 2; }
(leaving storage aside)
Which for me it doesn't make any sense. Even thinking about the argument
(you should have a big gain to introduce syntax sugar).
enums should be enums, flags should be flags, and manifest constants
should be... well, you got the idea.
enum is to D what const is to C++ :P
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
The average person laughs 13 times a day
Re: Interesting rant about Scala's issues
Using Ada code examples below:
On Monday, 7 April 2014 at 16:25:45 UTC, Regan Heath wrote:
On Mon, 07 Apr 2014 16:15:41 +0100, Paulo Pinto
pj...@progtools.org wrote:
Am 07.04.2014 12:07, schrieb Regan Heath:
On Mon, 07 Apr 2014 00:17:45 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 4/6/14, 10:52 AM, Walter Bright wrote:
On 4/6/2014 3:31 AM, Leandro Lucarella wrote:
What I mean is the current semantics of enum are as they
are for
historical reasons, not because they make (more) sense
(than other
possibilities). You showed a lot of examples that makes
sense only
because you are used to the current semantics, not because
they are the
only option or the option that makes the most sense.
I use enums a lot in D. I find they work very
satisfactorily. The way
they work was deliberately designed, not a historical
accident.
Sorry, I think they ought to have been better. -- Andrei
Got a DIP/spec/design to share?
R
How they work in languages like Ada.
Ok, brief look at those shows me enums can be converted to a
Pos index but otherwise you cannot associate a numberic value
with them, right?
So if we had that in D, Walters examples would look like..
1)
enum Index { A, B, C }
T[Index.C.pos + 1] array; // perhaps?
type Index is (A, B, C);
d_array: array Index'Length of T;
...
array[Index.B.pos] = t; // yes?
d_array(Index'Pos(B)) := t;
2)
array[Index.A.pos + 1] = t; // yes?
d_array(Index'Succ(A)) := t;
3)
enum Mask { A=1,B=4 } // not possible?
Mask m = A | B; // Error: incompatible operator | for enum
type Mask is (A, B);
for Mask use (A = 1, B = 4);
m : Mask := Mask'Pos(A) or Mask'Pos(B);
Have I got that right?
For a proposal like this to even be considered I would imagine
it would have to be backward compatible with existing uses, so
you would have to be proposing a new keyword or syntax on
enum to trigger typesafe enums, perhaps typesafe is a good
keyword, e.g.
typesafe enum Index { A, B, C } // requires use of .pos to
convert to int 0, 1, or 2.
enum Index { A, B, C } // existing pragmatic behaviour
R
This is the C++ approach with enum class for strong typed enums.
Re: Interesting rant about Scala's issues
On Mon, 07 Apr 2014 00:17:45 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 4/6/14, 10:52 AM, Walter Bright wrote: On 4/6/2014 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident. Sorry, I think they ought to have been better. -- Andrei Got a DIP/spec/design to share? R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Interesting rant about Scala's issues
On Monday, 7 April 2014 at 10:07:03 UTC, Regan Heath wrote: Got a DIP/spec/design to share? R I think biggest mistake of D enums is merging constants and actual enumerations into single entity which has resulted in weak typing of enumerations.
Re: Interesting rant about Scala's issues
Am 07.04.2014 12:07, schrieb Regan Heath: On Mon, 07 Apr 2014 00:17:45 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 4/6/14, 10:52 AM, Walter Bright wrote: On 4/6/2014 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident. Sorry, I think they ought to have been better. -- Andrei Got a DIP/spec/design to share? R How they work in languages like Ada. -- Paulo
Re: Interesting rant about Scala's issues
On Mon, 07 Apr 2014 16:15:41 +0100, Paulo Pinto pj...@progtools.org
wrote:
Am 07.04.2014 12:07, schrieb Regan Heath:
On Mon, 07 Apr 2014 00:17:45 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 4/6/14, 10:52 AM, Walter Bright wrote:
On 4/6/2014 3:31 AM, Leandro Lucarella wrote:
What I mean is the current semantics of enum are as they are for
historical reasons, not because they make (more) sense (than other
possibilities). You showed a lot of examples that makes sense only
because you are used to the current semantics, not because they are
the
only option or the option that makes the most sense.
I use enums a lot in D. I find they work very satisfactorily. The way
they work was deliberately designed, not a historical accident.
Sorry, I think they ought to have been better. -- Andrei
Got a DIP/spec/design to share?
R
How they work in languages like Ada.
Ok, brief look at those shows me enums can be converted to a Pos index
but otherwise you cannot associate a numberic value with them, right?
So if we had that in D, Walters examples would look like..
1)
enum Index { A, B, C }
T[Index.C.pos + 1] array; // perhaps?
...
array[Index.B.pos] = t; // yes?
2)
array[Index.A.pos + 1] = t; // yes?
3)
enum Mask { A=1,B=4 } // not possible?
Mask m = A | B; // Error: incompatible operator | for enum
Have I got that right?
For a proposal like this to even be considered I would imagine it would
have to be backward compatible with existing uses, so you would have to be
proposing a new keyword or syntax on enum to trigger typesafe enums,
perhaps typesafe is a good keyword, e.g.
typesafe enum Index { A, B, C } // requires use of .pos to convert to int
0, 1, or 2.
enum Index { A, B, C } // existing pragmatic behaviour
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Interesting rant about Scala's issues
On 4/7/14, 3:07 AM, Regan Heath wrote: On Mon, 07 Apr 2014 00:17:45 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 4/6/14, 10:52 AM, Walter Bright wrote: On 4/6/2014 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident. Sorry, I think they ought to have been better. -- Andrei Got a DIP/spec/design to share? No. -- Andrei
Re: Interesting rant about Scala's issues
On 4/6/14, 6:49 PM, Walter Bright wrote:
On 4/6/2014 4:17 PM, Andrei Alexandrescu wrote:
On 4/6/14, 10:52 AM, Walter Bright wrote:
I use enums a lot in D. I find they work very satisfactorily. The way
they work was deliberately designed, not a historical accident.
Sorry, I think they ought to have been better. -- Andrei
Sorry, yer wrong!
This program compiles and flag free and no cast in sight but fails at
runtime. Textbook example of unsound type design.
import std.stdio;
enum A { x = 2, y = 4 }
void main()
{
A a = A.x | A.y;
final switch (a)
{
case A.x: break;
case A.y: break;
}
}
The | operator converts back to an A. It shouldn't. In this case it
provides a value not only outside the enum range, but even greater than
A.max (when converted to integer).
I'm fine with yes, it's unsound, but we wanted to do flags and we
couldn't find a better solution, but this it's deliberate and it's
good I just find difficult to get behind.
Andrei
Re: Interesting rant about Scala's issues
On Monday, 7 April 2014 at 21:02:04 UTC, Andrei Alexandrescu
wrote:
This program compiles and flag free and no cast in sight but
fails at runtime. Textbook example of unsound type design.
import std.stdio;
enum A { x = 2, y = 4 }
void main()
{
A a = A.x | A.y;
final switch (a)
{
case A.x: break;
case A.y: break;
}
}
The | operator converts back to an A. It shouldn't. In this
case it provides a value not only outside the enum range, but
even greater than A.max (when converted to integer).
I'm fine with yes, it's unsound, but we wanted to do flags and
we couldn't find a better solution, but this it's deliberate
and it's good I just find difficult to get behind.
Andrei
Yeah, I've seen this happen before. I think we could actually
introduce a little more type safety on enums without a great deal
of breakage. It would be nice to have a final switch give you as
much of a guarantee about what it's doing as it can.
Re: Interesting rant about Scala's issues
On 4/6/14, 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. Is it better to redesign enum semantics now? Probably not, but I'm just saying :) I fully agree. In my opinion, too, the enum design in D is suboptimal. Andrei
Re: Interesting rant about Scala's issues
On 4/6/2014 4:26 AM, bearophile wrote: So do you have an example of this risk? Algol is a rather famous one. A counterexample is Go, which has gotten a lot of traction with a simple syntax.
Re: Interesting rant about Scala's issues
On 4/6/2014 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident.
Re: Interesting rant about Scala's issues
On Sunday, 6 April 2014 at 16:46:12 UTC, Andrei Alexandrescu wrote: On 4/6/14, 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. Is it better to redesign enum semantics now? Probably not, but I'm just saying :) I fully agree. In my opinion, too, the enum design in D is suboptimal. Andrei Hey bearophile - I rest my case... -Eric
Re: Interesting rant about Scala's issues
On Sunday, 6 April 2014 at 11:26:41 UTC, bearophile wrote: Walter Bright: Having special syntax for everything makes the language unusable. While there are ways to reach excesses in every design direction, and make things unusable, the risk discussed here seems remote to me. Too much syntax diversity for almost the same things leads to a language that is harder to learn, but I think readability has little to do with special syntax, but rather how it is done and how frequently used those constructs are. You can get syntax diversity with simple formal syntax too. Lisp code often shows signs of this. D and C++ show signs of this with overuse of templates. I find template heavy code to be very poor in terms of readability and well designed special syntax would have been much better in terms of usability.
Re: Interesting rant about Scala's issues
Am 06.04.2014 19:54, schrieb Walter Bright: On 4/6/2014 4:26 AM, bearophile wrote: So do you have an example of this risk? Algol is a rather famous one. A counterexample is Go, which has gotten a lot of traction with a simple syntax. It has more to do with Google than with the language's design.
Re: Interesting rant about Scala's issues
On Sunday, 6 April 2014 at 17:52:19 UTC, Walter Bright wrote: On 4/6/2014 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident. The fact that you are unaware of how it's properly done (hint: Pascal got right with 'set of enum' being distinct from 'enum') makes it a historical accident.
Re: Interesting rant about Scala's issues
On 4/6/2014 2:26 PM, Araq wrote: The fact that you are unaware of how it's properly done (hint: Pascal got right with 'set of enum' being distinct from 'enum') makes it a historical accident. I wrote a Pascal compiler before the C one.
Re: Interesting rant about Scala's issues
On Sunday, 6 April 2014 at 19:53:43 UTC, Paulo Pinto wrote: A counterexample is Go, which has gotten a lot of traction with a simple syntax. It has more to do with Google than with the language's design. That, and being perceived as a http-server-language and having standard libraries and a threading model geared towards web servers. In addition Go has managed to improve the C syntax by removing in-most-cases redundant syntax. Which is quite nice for readability, IMO.
Re: Interesting rant about Scala's issues
On 4/6/14, 10:52 AM, Walter Bright wrote: On 4/6/2014 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident. Sorry, I think they ought to have been better. -- Andrei
Re: Interesting rant about Scala's issues
Walter Bright: Having special syntax for everything makes the language unusable. While there are ways to reach excesses in every design direction, and make things unusable, the risk discussed here seems remote to me. So do you have an example of this risk? Or examples of languages that have fallen in this trap? Perhaps Ada? Bye, bearophile
Re: Interesting rant about Scala's issues
Walter Bright, el 5 de April a las 21:15 me escribiste: On 4/5/2014 6:28 PM, Leandro Lucarella wrote: Walter Bright, el 5 de April a las 11:04 me escribiste: Of course, you can hide all this in a template. Well, you can emulate enums as they are now with structs too, so that doesn't change anything in the argument about why to provide syntax sugar for one and not the other. The argument for syntactic sugar is it must show a very large benefit over using a template. Having special syntax for everything makes the language unusable. What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. Is it better to redesign enum semantics now? Probably not, but I'm just saying :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- El techo de mi cuarto lleno de cometas
Re: Interesting rant about Scala's issues
On 4/6/2014 4:17 PM, Andrei Alexandrescu wrote: On 4/6/14, 10:52 AM, Walter Bright wrote: I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident. Sorry, I think they ought to have been better. -- Andrei Sorry, yer wrong!
Re: Interesting rant about Scala's issues
bearophile, el 4 de April a las 18:39 me escribiste:
Walter Bright:
Thank you for the answers.
Here's one:
enum Index { A, B, C }
T[Index.max] array; // Error: Index.max is not an int
...
array[B] = t; // Error: B is not an int
In the last months I've grown a moderate desire for optionally
strongly typed array indexes in D (as seen in Ada, but with a
What about:
enum Int : int { One = 1, Two, Three } // implicitly casteable to int
enum Symbolic { Dogs, Cars, Trees }// not implicitly casteable (and
// maybe not even expose the
// internal value)
?
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 01:54:16 UTC, Ben Boeckel wrote:
There is *zero* rationale as to why this would be a compilable
implementation of comparison:
int compare(int a, int b) {
return a * b;
}
The fact that this compiles when used as a comparison is
*insane* when
you take a fresh look at how you can construct a language.
You're actually not restricted to int; you can also return float,
or in fact any type that's compare to 0, including user-defined
types that implement their own `opCmp`.
Re: Interesting rant about Scala's issues
On 04/03/2014 04:45 AM, Walter Bright wrote: On 4/2/2014 6:55 PM, Andrei Alexandrescu wrote: A lot of them could apply to us as well. https://www.youtube.com/watch?v=TS1lpKBMkgg at about 44:00: I begged them not to do them [AST macros]. :-) (This is a misquote.)
Re: Interesting rant about Scala's issues
On 4/5/2014 2:40 AM, Leandro Lucarella wrote:
enum Symbolic { Dogs, Cars, Trees }// not implicitly casteable (and
// maybe not even expose the
// internal value)
?
struct Symbolic {
private static struct _impl { private int x; }
enum Dogs = _impl(0);
enum Cars = _impl(1);
enum Trees = _impl(2);
}
Of course, you can hide all this in a template.
Re: Interesting rant about Scala's issues
On 4/5/2014 10:10 AM, Timon Gehr wrote: On 04/03/2014 04:45 AM, Walter Bright wrote: On 4/2/2014 6:55 PM, Andrei Alexandrescu wrote: A lot of them could apply to us as well. https://www.youtube.com/watch?v=TS1lpKBMkgg at about 44:00: I begged them not to do them [AST macros]. :-) (This is a misquote.) Yeah, I should have been more accurate. In response to a question about macros reflection: I begged them not to, not to just export the compiler to I begged them I begged them not to do it.
Re: Interesting rant about Scala's issues
On Saturday, 5 April 2014 at 18:47:50 UTC, Walter Bright wrote: In response to a question about macros reflection: I begged them not to, not to just export the compiler to I begged them I begged them not to do it. A reboot is in progress on this, too: http://scalareflect.org
Re: Interesting rant about Scala's issues
Walter Bright, el 5 de April a las 11:04 me escribiste:
On 4/5/2014 2:40 AM, Leandro Lucarella wrote:
enum Symbolic { Dogs, Cars, Trees }// not implicitly casteable (and
// maybe not even expose the
// internal value)
?
struct Symbolic {
private static struct _impl { private int x; }
enum Dogs = _impl(0);
enum Cars = _impl(1);
enum Trees = _impl(2);
}
Of course, you can hide all this in a template.
Well, you can emulate enums as they are now with structs too, so that
doesn't change anything in the argument about why to provide syntax
sugar for one and not the other.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
Re: Interesting rant about Scala's issues
On 4/5/2014 6:28 PM, Leandro Lucarella wrote: Walter Bright, el 5 de April a las 11:04 me escribiste: Of course, you can hide all this in a template. Well, you can emulate enums as they are now with structs too, so that doesn't change anything in the argument about why to provide syntax sugar for one and not the other. The argument for syntactic sugar is it must show a very large benefit over using a template. Having special syntax for everything makes the language unusable.
Re: Interesting rant about Scala's issues
On 4/3/2014 9:54 PM, Meta wrote: In the case of your example, alias this does not make it typesafe, as a MyInt can still be implicitly converted to int. You can disable the implicit conversion to int with this scheme. The alias this only takes effect if there is no other member that will take the operation.
Re: Interesting rant about Scala's issues
On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright newshou...@digitalmars.comwrote: You can disable the implicit conversion to int with this scheme. The alias this only takes effect if there is no other member that will take the operation. What is the exact method of disabling the implicit cast? I had a look after you sent your last mail. Didn't find anything in the spec.
Re: Interesting rant about Scala's issues
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.
Re: Interesting rant about Scala's issues
On Thursday, 3 April 2014 at 22:58:24 UTC, w0rp wrote: I notice that he mentioned the objection to defining equality and so on for the root object. I have heard this before from Philip Wadler, and the more I think about it, the more it makes sense. This is essentially the idea of removing every method from Object, which we have dicussed before. I used to discuss against it, but came to realize it does actually make sense. Java came up with it most likely as it was the way in Smalltalk. But nowadays we know better, those concepts are better expressed via interfaces/traits/protocols, or whatever they are called in every language. In languages with generics support and some form of interface definitions, there is no need for root objects. -- Paulo
Re: Interesting rant about Scala's issues
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. I guess you need to be more up to date to Scala news. :) https://groups.google.com/forum/m/#!msg/scala-internals/6HL6lVLI3bQ/IY4gEyOwFhoJ https://github.com/lampepfl/dotty -- Paulo
Re: Interesting rant about Scala's issues
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.
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 08:00:09 UTC, w0rp wrote: 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. Bah, except that if you use everywhere big ints, floating point intervals instead of floating points (the former is the correct representation of reals, the latter isn't), normalized strings, the obvious optimisations won't necessarily be enough to avoid being very slow..
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 08:05:58 UTC, renoX wrote: On Friday, 4 April 2014 at 08:00:09 UTC, w0rp wrote: 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. Bah, except that if you use everywhere big ints, floating point intervals instead of floating points (the former is the correct representation of reals, the latter isn't), normalized strings, the obvious optimisations won't necessarily be enough to avoid being very slow.. Says who? And slow to whom? 1 - Write correct code 2 - Use a profiler, if the code isn't fast enough for the use case being written for 3 - If desired use case isn't there, use the profiler information to improve the specific hotpaths in need of tuning. I see too many people micro-optimize for nothing. -- Paulo
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 08:16:20 UTC, Paulo Pinto wrote: Says who? And slow to whom? 1 - Write correct code 2 - Use a profiler, if the code isn't fast enough for the use case being written for 3 - If desired use case isn't there, use the profiler information to improve the specific hotpaths in need of tuning. I see too many people micro-optimize for nothing. -- Paulo While this is true in general, spotting performance overhead from using bigints everywhere in profiler can be rather tricky because it will be evenly spread across the program. Micro-optimizations are bad but this is not very practical example.
Re: Interesting rant about Scala's issues
On 4/4/2014 12:23 AM, Rory McGuire wrote: On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright newshou...@digitalmars.com mailto:newshou...@digitalmars.com wrote: You can disable the implicit conversion to int with this scheme. The alias this only takes effect if there is no other member that will take the operation. What is the exact method of disabling the implicit cast? I had a look after you sent your last mail. Didn't find anything in the spec. It's supposed to be by adding your own opImplicitCast overload, but that isn't implemented yet.
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 09:07:31 UTC, Dicebot wrote: On Friday, 4 April 2014 at 08:16:20 UTC, Paulo Pinto wrote: Says who? And slow to whom? 1 - Write correct code 2 - Use a profiler, if the code isn't fast enough for the use case being written for 3 - If desired use case isn't there, use the profiler information to improve the specific hotpaths in need of tuning. I see too many people micro-optimize for nothing. -- Paulo While this is true in general, spotting performance overhead from using bigints everywhere in profiler can be rather tricky because it will be evenly spread across the program. Micro-optimizations are bad but this is not very practical example. To pick up on the bigints example, most compilers only use them if they don't fit into registers. -- Paulo
Re: Interesting rant about Scala's issues
okay, awesome, I guessed correctly then. (on where to find it anyway). On Fri, Apr 4, 2014 at 11:16 AM, Walter Bright newshou...@digitalmars.comwrote: On 4/4/2014 12:23 AM, Rory McGuire wrote: On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright newshou...@digitalmars.com mailto:newshou...@digitalmars.com wrote: You can disable the implicit conversion to int with this scheme. The alias this only takes effect if there is no other member that will take the operation. What is the exact method of disabling the implicit cast? I had a look after you sent your last mail. Didn't find anything in the spec. It's supposed to be by adding your own opImplicitCast overload, but that isn't implemented yet.
Re: Interesting rant about Scala's issues
Walter Bright: Because every cast breaks the type system. A type system that requires too many casts for normal things is NOT a type safe system. I have explained this on numerous occasions. You have discussed many times about the unsafety of casts and I agree with your point of view. I try to reduce the number of casts as much as possible in my code (and recently I have replaced many cast(double)x with nice double(x), as time passes D allows to remove more and more casts from the code, this is an improvement). You see I care of casts also from the little casts statistic I've done on your Warp: http://forum.dlang.org/thread/lhf0u6$2r80$1...@digitalmars.com?page=3#post-wjjivmmeyeismgkntwsj:40forum.dlang.org Or from answers I keep giving in D.learn, where I suggest to minimize the usage of casts: http://forum.dlang.org/thread/efbjrtwqywkhfybmy...@forum.dlang.org But since I follow D development and I write D code I don't remember any kind of discussion regarding the specific disadvantages of a stronger typed enum. This means answering questions like: what does it happen if D enums become strongly typed? How many casts is this going to cause in D code? Is it true that such enum casts are going to be worse than type unsafety of the current design? I don't remember seeing any little study that shows that stronger casts in D increase a lot the number of casts. Perhaps this little study was done before I have started to use D1 and I have missed it. I suspect that in my D code most cast usage does not need casts if you replace them with stronger casts as the enum class of C++11, but I have no proof of this. Bye, bearophile
Re: Interesting rant about Scala's issues
I suspect that in my D code most cast usage does not need casts if you replace them with stronger casts as the enum class of C++11, but I have no proof of this. Too much casting. I meant to say: I suspect that in my D code most usages of enum don't need casts if you replace them with stronger enums (like the enum class of C++11), but I have no proof of this. Bye, bearophile
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 07:43:22 UTC, Paulo Pinto wrote: Java came up with it most likely as it was the way in Smalltalk. That's right. As Smalltalk is dynamically typed it is not an issue there anyway and Java to begin with had to parameterized types till JDK4. I guess you need to be more up to date to Scala news. :) https://groups.google.com/forum/m/#!msg/scala-internals/6HL6lVLI3bQ/IY4gEyOwFhoJ https://github.com/lampepfl/dotty Interesting. But it kind of looks like yet another academical thing similar to Scala. To me Kotlin is the better Scala done right language. But I won't play with it until I see its compiler speed being a lot better than with Scala ...
Re: Interesting rant about Scala's issues
04-Apr-2014 13:16, Walter Bright пишет: On 4/4/2014 12:23 AM, Rory McGuire wrote: On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright newshou...@digitalmars.com mailto:newshou...@digitalmars.com wrote: You can disable the implicit conversion to int with this scheme. The alias this only takes effect if there is no other member that will take the operation. What is the exact method of disabling the implicit cast? I had a look after you sent your last mail. Didn't find anything in the spec. It's supposed to be by adding your own opImplicitCast overload, but that isn't implemented yet. The difference between opImplictCast and alias this being ... ? -- Dmitry Olshansky
Re: Interesting rant about Scala's issues
First use alias this go import functionality transparently. Then use opImplicitCast to set what can be implicitly casted to. On 04 Apr 2014 12:45 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote: 04-Apr-2014 13:16, Walter Bright пишет: On 4/4/2014 12:23 AM, Rory McGuire wrote: On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright newshou...@digitalmars.com mailto:newshou...@digitalmars.com wrote: You can disable the implicit conversion to int with this scheme. The alias this only takes effect if there is no other member that will take the operation. What is the exact method of disabling the implicit cast? I had a look after you sent your last mail. Didn't find anything in the spec. It's supposed to be by adding your own opImplicitCast overload, but that isn't implemented yet. The difference between opImplictCast and alias this being ... ? -- Dmitry Olshansky
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 09:16:26 UTC, Walter Bright wrote: It's supposed to be by adding your own opImplicitCast overload, but that isn't implemented yet. Wait, this is back? What else did the community get wrong when trying to interpret discussions? http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections Previously proposed, but now dropped: * opImplicitCast * Separating arrays and slices (T[new]) (see NG:digitalmars.D/95225) Demise of T[new] NG:digitalmars.D/98602 * Make references and arrays library types (see NG discussion) * this() for structs. * Make array literals immutable. * Remove 'new'. * Remove C-style struct initializers.
Re: Interesting rant about Scala's issues
On 4/4/2014 3:24 AM, bearophile wrote:
You see I care of casts also from the little casts statistic I've done on your
Warp:
http://forum.dlang.org/thread/lhf0u6$2r80$1...@digitalmars.com?page=3#post-wjjivmmeyeismgkntwsj:40forum.dlang.org
Most of the casts in Warp come from the workarounds I had to do to get around
the auto-decode of std.array.front(). I have designed byChar, byWchar and
byDchar ranges for Phobos to get around this issue, but that is stalled now
because of the messed up design of ranges.
None of that has anything to do with enums.
But since I follow D development and I write D code I don't remember any kind of
discussion regarding the specific disadvantages of a stronger typed enum.
Here's one:
enum Index { A, B, C }
T[Index.max] array; // Error: Index.max is not an int
...
array[B] = t; // Error: B is not an int
And another:
array[A + 1] = t; // Error: incompatible types Index and int
And another:
enum Mask { A=1,B=4 }
Mask m = A | B; // Error: incompatible operator | for enum
and on it goes. These are routine and normal uses of enums.
This means answering questions like: what does it happen if D enums become
strongly
typed? How many casts is this going to cause in D code? Is it true that such
enum casts are going to be worse than type unsafety of the current design?
Yes, because I have to fill the above code with cast(int), and you are well
aware that such blunt casting destroys all type safety.
And besides, even if such strongly typed enums were a good idea, making such a
change would be an utter disaster for existing code. It is out of the question.
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 18:02:02 UTC, Walter Bright wrote:
Here's one:
enum Index { A, B, C }
T[Index.max] array; // Error: Index.max is not an int
...
array[B] = t; // Error: B is not an int
And another:
array[A + 1] = t; // Error: incompatible types Index and int
And another:
enum Mask { A=1,B=4 }
Mask m = A | B; // Error: incompatible operator | for enum
and on it goes. These are routine and normal uses of enums.
It's trivial to write an EnumMemberValue template that convert
the enum member to its underlying value at compile time. Also, if
I remember correctly, min and max are terribly broken for enums
in the first place.
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 18:15:43 UTC, Meta wrote:
And another:
array[A + 1] = t; // Error: incompatible types Index and int
And another:
enum Mask { A=1,B=4 }
Mask m = A | B; // Error: incompatible operator | for enum
and on it goes. These are routine and normal uses of enums.
https://github.com/D-Programming-Language/phobos/pull/2058
Perhaps we *will* get typesafe enums of a sort via a library
implementation.
Re: Interesting rant about Scala's issues
Walter Bright:
Thank you for the answers.
Here's one:
enum Index { A, B, C }
T[Index.max] array; // Error: Index.max is not an int
...
array[B] = t; // Error: B is not an int
In the last months I've grown a moderate desire for optionally
strongly typed array indexes in D (as seen in Ada, but with a
different syntax) (it's optional, so it's meant to be an additive
change, that causes no harm to existing D code). With them code
like yours becomes OK (as it's OK in Ada). Such optional strong
typing for array indexes is not means for script-like D programs,
but for the medium-integrity D programs.
And another:
array[A + 1] = t; // Error: incompatible types Index and int
This can be solved with optionally strongly typed array indexes
plus a succ/prec property for enums. I have asked for such
property years ago. In Ada you use the built in function Succ.
Alternatively, in D you can also use a library-defined group of
little functions/templates succ/prec/Succ/Prec (that contain a
cast, but it's in Phobos, so it's less dangerous than a cast in
user code):
array[Succ!(Index.A)] = t;
auto i = Index.A;
array[i.succ] = t;
And another:
enum Mask { A=1,B=4 }
Mask m = A | B; // Error: incompatible operator | for enum
In GitHub there is a patch that is meant to implement Flags in
library code (in C# such Flags are almost first-class, using
[Flags]):
https://github.com/D-Programming-Language/phobos/pull/2058
If such Flags is implemented with enums, then it contains casts,
but again casts in Phobos are less dangerous than casts in user
code.
Bye,
bearophile
Re: Interesting rant about Scala's issues
Meta: Also, if I remember correctly, min and max are terribly broken for enums in the first place. Yes, perhaps they need to be deprecated. Also, there is a ugly name clashing between enum field names and the enum properties. The solution is to group them into a single namespace (like meta), and then forbid an enum member with the name of the namespace. https://d.puremagic.com/issues/show_bug.cgi?id=4997 Unfortunately overall the design of D enums has more holes than swiss cheese. This is why in a recent post I said to Andrei that perhaps there are still several little breaking changes to do to D, and they need priority over additive enhancements. Bye, bearophile
Re: Interesting rant about Scala's issues
And another:
enum Mask { A=1,B=4 }
Mask m = A | B; // Error: incompatible operator | for enum
That would be a 'set of enum' in Pascal/Delphi.
Re: Interesting rant about Scala's issues
On Fri, Apr 04, 2014 at 11:02:01 -0700, Walter Bright wrote:
Most of the casts in Warp come from the workarounds I had to do to
get around the auto-decode of std.array.front(). I have designed
byChar, byWchar and byDchar ranges for Phobos to get around this
issue, but that is stalled now because of the messed up design of
ranges.
Sorry, I'm a D noob; what's 'auto-decode'?
Here's one:
enum Index { A, B, C }
T[Index.max] array; // Error: Index.max is not an int
...
array[B] = t; // Error: B is not an int
Maybe instead of having array indices be int, having them specify some
interface (akin to Ix[1] used by Haskell's Array). Not that this is
likely fixable at this point.
And another:
array[A + 1] = t; // Error: incompatible types Index and int
And another:
enum Mask { A=1,B=4 }
Mask m = A | B; // Error: incompatible operator | for enum
I like Qt's Q_FLAG and Q_FLAGS where you have a separate type for the
flags and combined flags. Maybe something like:
enum MaskBits { mixin EnumBits!MaskBits; A=1, B=4 }
alias Flags!MaskBits Mask;
where EnumBits would define the binary operations would be possible?
And besides, even if such strongly typed enums were a good idea,
making such a change would be an utter disaster for existing code. It
is out of the question.
Agreed.
There's also Haskell's 'newtype' which might be useful to have
(strongalias? strictalias?). I guess this is no different than something
like:
class NewType(T) {
private:
T store;
public this(T store) {
this.store = store;
}
package T unT() {
return store;
}
}
and if you want unT to be public:
public T unT(NewType!T nt) {
return nt.unT();
}
--Ben
[1]http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Ix.html
Re: Interesting rant about Scala's issues
array[Succ!(Index.A)] = t; auto i = Index.A; array[i.succ] = t; And with enum precondition in the succ() function you can do both cases with a single function: array[Index.A.succ] = t; auto i = Index.A; array[i.succ] = t; Bye, bearophile
Re: Interesting rant about Scala's issues
On 4/4/2014 11:47 AM, bearophile wrote: Also, there is a ugly name clashing between enum field names and the enum properties. The solution is to group them into a single namespace (like meta), and then forbid an enum member with the name of the namespace. https://d.puremagic.com/issues/show_bug.cgi?id=4997 Actually, that was intentional, which is why the issue is marked as enhancement. The builtin properties are override-able. Unfortunately overall the design of D enums has more holes than swiss cheese. Enums are not meant to be rigidly typed. This is why in a recent post I said to Andrei that perhaps there are still several little breaking changes to do to D, and they need priority over additive enhancements. I understand your concerns, but I don't share your opinion that they need fixing. Their behaviors were deliberately designed, and in my experience work out nicely.
Re: Interesting rant about Scala's issues
On 4/4/2014 12:05 PM, bearophile wrote: And with enum precondition in the succ() function you can do both cases with a single function: array[Index.A.succ] = t; auto i = Index.A; array[i.succ] = t; What about i+10? Do you expect the person to write i.succ.succ.succ.succ.succ.succ.succ.succ.succ.succ? Sorry, that sux! And what about: int j; array[i+j] ? And forcing the user to use templates to do any logical or arithmetic operations on enum operands? It's just awful.
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 18:57:44 UTC, Ben Boeckel wrote: On Fri, Apr 04, 2014 at 11:02:01 -0700, Walter Bright wrote: Most of the casts in Warp come from the workarounds I had to do to get around the auto-decode of std.array.front(). I have designed byChar, byWchar and byDchar ranges for Phobos to get around this issue, but that is stalled now because of the messed up design of ranges. Sorry, I'm a D noob; what's 'auto-decode'? unicode decoding. front decodes a code-point from a string instead of a code-unit (single char)
Re: Interesting rant about Scala's issues
On 2014-04-04 04:31, Walter Bright wrote:
On 4/3/2014 7:19 PM, bearophile wrote:
I have asked for fully typesafe enums in D,
You can do this:
struct MyInt {
int x;
alias this x;
... put your various constraints here ...
}
to get typesafe enums. In fact, you can use this construct to create a
type that overrides selected behaviors of any other type.
For a more complete implementation of typesafe enums, here's my take:
https://github.com/Biotronic/Collectanea/blob/master/biotronic/enumeration.d
--
Simen
Re: Interesting rant about Scala's issues
My knowledge of compiler constructions is fairly limited and I might be wrong, but it seems to me that the Scala compiler is broken. Scala has gained some bad reputation for long build times (just google for Scala and build time) which IMHO cannot be explained by the large number of language features. D has a comparable large number of language features and compiles much faster than Scala. D has been designed from the beginning with caution on compilation speed and thinking about how to keep it slow to begin with. D not only in that way is a language that was thought out. On the contrary, Scala seems to me to be a language where many features of various languages were thrown into one and then a compiler was built for it. The incremental Scala compiler pretty much rescues the build time problem, though, and they are mostly lucky now. Also, IMHO, implicits are really crazy and it should have been clear from the beginning that they will become a problem for scalable build times, see http://java.dzone.com/articles/implicits-scala-conversion. Interestingly. Martin Odersky got his Ph.D. from Niklaus Wirth at the ETH and I don't want to know what Wirth would say about implicits. The presentation by Paul Phillips was discussed in the Scala forums at great length: What's up with Paul Phillips? https://groups.google.com/forum/?hl=de#!topic/scala-debate/IgrKCdConlA 54 replies What's up with Paul Phillips? https://groups.google.com/forum/?hl=de#!topic/scala-user/ImqlClXTrS4[201-225-false] 201 replies Sadly, the only serious language on the JVM besides Java8 is Scala. Ceylon has not taken off at all after becoming 1.0. Groovy's language extensions are basically AST transformations and not truly baked into a real language. Nobody knows how Kotlin will be doing when it turns 1.0 maybe somewhen in autumn/winter this year. To get a plus for your skill set when applying for Java jobs you will have to learn Scala. For a Java developer like me any chances for a job doing D are very slim. But I keep looking into D just out of interest and to get some food for my mind. There is so much to learn from looking at D and playing with it that I keep doing it just on a fun interest basis.
Re: Interesting rant about Scala's issues
On Thursday, 3 April 2014 at 08:18:01 UTC, Bienlein wrote: My knowledge of compiler constructions is fairly limited and I might be wrong, but it seems to me that the Scala compiler is broken. Scala has gained some bad reputation for long build times (just google for Scala and build time) which IMHO cannot be explained by the large number of language features. D has a comparable large number of language features and compiles much faster than Scala. D has been designed from the beginning with caution on compilation speed and thinking about how to keep it slow to begin with. D not only in that way is a language that was thought out. On the contrary, Scala seems to me to be a language where many features of various languages were thrown into one and then a compiler was built for it. The incremental Scala compiler pretty much rescues the build time problem, though, and they are mostly lucky now. Also, IMHO, implicits are really crazy and it should have been clear from the beginning that they will become a problem for scalable build times, see http://java.dzone.com/articles/implicits-scala-conversion. Interestingly. Martin Odersky got his Ph.D. from Niklaus Wirth at the ETH and I don't want to know what Wirth would say about implicits. The presentation by Paul Phillips was discussed in the Scala forums at great length: What's up with Paul Phillips? https://groups.google.com/forum/?hl=de#!topic/scala-debate/IgrKCdConlA 54 replies What's up with Paul Phillips? https://groups.google.com/forum/?hl=de#!topic/scala-user/ImqlClXTrS4[201-225-false] 201 replies Sadly, the only serious language on the JVM besides Java8 is Scala. Ceylon has not taken off at all after becoming 1.0. Groovy's language extensions are basically AST transformations and not truly baked into a real language. Nobody knows how Kotlin will be doing when it turns 1.0 maybe somewhen in autumn/winter this year. To get a plus for your skill set when applying for Java jobs you will have to learn Scala. For a Java developer like me any chances for a job doing D are very slim. But I keep looking into D just out of interest and to get some food for my mind. There is so much to learn from looking at D and playing with it that I keep doing it just on a fun interest basis. If I remember what the state of Groovy is (around 2012). The compiler devs focussed quite heavily on functionality not performance. Even refused to go that direction. It was quite bad. Its a real shame. I liked it. Although if they had and had unsigned types I probably wouldn't be in D!
Re: Interesting rant about Scala's issues
If I remember what the state of Groovy is (around 2012). The compiler devs focussed quite heavily on functionality not performance. Even refused to go that direction. It was quite bad. Its a real shame. I liked it. Although if they had and had unsigned types I probably wouldn't be in D! Since Groovy 2.0 there is optional static type checking and when using it performance is much better. When Groovy is run over the Havlak benchmark it is only 10% behind in speed compared to Java with static typing and only about 40% in behind when purely dynamic as with pre-2.0 Groovy. See the bottom most paragraph in the readme of https://github.com/oplohmann/havlak-jvm-languages The benchmark in this article (http://java.dzone.com/articles/groovy-20-performance-compared) only measures method invocation time, but it also gives some idea that performance in Groovy is really good now. What Scala is really good at is concurrency. You must give them that. Akka (akka.io) and new ideas about futures and promises really started in the Scala community. Some of that stuff also made it into JDK8. Something like Akka for D will be a killer app for D. It can't be done as a spare time activity, otherwise I would already have embarked on it ;-).
Re: Interesting rant about Scala's issues
On Thursday, 3 April 2014 at 08:18:01 UTC, Bienlein wrote: My knowledge of compiler constructions is fairly limited and I might be wrong, but it seems to me that the Scala compiler is broken. Scala has gained some bad reputation for long build times (just google for Scala and build time) which IMHO cannot be explained by the large number of language features. D has a comparable large number of language features and compiles much faster than Scala. D has been designed from the beginning with caution on compilation speed and thinking about how to keep it slow to begin with. D not only in that way is a language that was thought out. On the contrary, Scala seems to me to be a language where many features of various languages were thrown into one and then a compiler was built for it. The incremental Scala compiler pretty much rescues the build time problem, though, and they are mostly lucky now. Also, IMHO, implicits are really crazy and it should have been clear from the beginning that they will become a problem for scalable build times, see http://java.dzone.com/articles/implicits-scala-conversion. Interestingly. Martin Odersky got his Ph.D. from Niklaus Wirth at the ETH and I don't want to know what Wirth would say about implicits. The presentation by Paul Phillips was discussed in the Scala forums at great length: What's up with Paul Phillips? https://groups.google.com/forum/?hl=de#!topic/scala-debate/IgrKCdConlA 54 replies What's up with Paul Phillips? https://groups.google.com/forum/?hl=de#!topic/scala-user/ImqlClXTrS4[201-225-false] 201 replies Sadly, the only serious language on the JVM besides Java8 is Scala. Ceylon has not taken off at all after becoming 1.0. Groovy's language extensions are basically AST transformations and not truly baked into a real language. Nobody knows how Kotlin will be doing when it turns 1.0 maybe somewhen in autumn/winter this year. What about Clojure? It is getting real world use. The recent release makes it easier to call Clojure from Java. Example: IFn map = Clojure.var(clojure.core, map); IFn inc = Clojure.var(clojure.core, inc); map.invoke(inc, Clojure.read([1 2 3])); is all you need to use Clojure's map from a Java program. https://github.com/clojure/clojure/blob/master/changes.md
Re: Interesting rant about Scala's issues
On Thursday, 3 April 2014 at 11:03:56 UTC, bachmeier wrote: What about Clojure? It is getting real world use. The recent release makes it easier to call Clojure from Java. Example: IFn map = Clojure.var(clojure.core, map); IFn inc = Clojure.var(clojure.core, inc); map.invoke(inc, Clojure.read([1 2 3])); is all you need to use Clojure's map from a Java program. https://github.com/clojure/clojure/blob/master/changes.md Yeah, you might be right. I was maybe too much focused on imperative/OO languages. It is now especially easy to call Closure from Kotlin. Have a look: http://blog.jetbrains.com/kotlin/2014/04/kotlin-gets-support-for-s-expressions
Re: Interesting rant about Scala's issues
On Thursday, 3 April 2014 at 08:43:33 UTC, Bienlein wrote: If I remember what the state of Groovy is (around 2012). The compiler devs focussed quite heavily on functionality not performance. Even refused to go that direction. It was quite bad. Its a real shame. I liked it. Although if they had and had unsigned types I probably wouldn't be in D! Since Groovy 2.0 there is optional static type checking and when using it performance is much better. When Groovy is run over the Havlak benchmark it is only 10% behind in speed compared to Java with static typing and only about 40% in behind when purely dynamic as with pre-2.0 Groovy. See the bottom most paragraph in the readme of https://github.com/oplohmann/havlak-jvm-languages The benchmark in this article (http://java.dzone.com/articles/groovy-20-performance-compared) only measures method invocation time, but it also gives some idea that performance in Groovy is really good now. Sounds like a lot has changed since I was in it then. What Scala is really good at is concurrency. You must give them that. Akka (akka.io) and new ideas about futures and promises really started in the Scala community. Some of that stuff also made it into JDK8. Something like Akka for D will be a killer app for D. It can't be done as a spare time activity, otherwise I would already have embarked on it ;-). Yes Akka is definitely a rather neat and great technology. Also would be great to have in D. I would love to help get something like this working in D. But time. Its bad enough with Cmsed in its current state. Let alone if I were to meet its goals of providing pretty much everything under the sun. Like node communication between frontend and backend for a web service. That also would be rather a killer feature. But in saying this it would actually probably be better if it was built like Akka. So on second thoughts guess what I'll be working on soon. Something like Akka. If you hear from me within a week in the format of an announcement please help :)
Re: Interesting rant about Scala's issues
On Thursday, 3 April 2014 at 13:23:16 UTC, Paulo Pinto wrote: I think you missed the post date. I think so too ...
Re: Interesting rant about Scala's issues
I notice that he mentioned the objection to defining equality and so on for the root object. I have heard this before from Philip Wadler, and the more I think about it, the more it makes sense. This is essentially the idea of removing every method from Object, which we have dicussed before.
Re: Interesting rant about Scala's issues
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 His examination of the compare function was interesting. I think, though, that it's misguided, and not one of Scala's problems. Returning an int to denote less than, equal, and greater than is a very small complexity, and makes it very fast to check the result.
Re: Interesting rant about Scala's issues
A more interesting point of his is the limitation of Scala's ability to optimize functions like filter... This is also a problem in D, but not as visible as we do not have macros to perform the sort of transformation he describes (turning filter f1, filter f2, filter f3 into filter f1 f2 f3). Maybe we should think about enforcing that lambas passed to higher order functions are pure, when we can (not in the compiler, of course. In the library.)
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 01:14:37 UTC, Meta wrote:
A more interesting point of his is the limitation of Scala's
ability to optimize functions like filter... This is also a
problem in D, but not as visible as we do not have macros to
perform the sort of transformation he describes (turning filter
f1, filter f2, filter f3 into filter f1 f2 f3). Maybe we should
think about enforcing that lambas passed to higher order
functions are pure, when we can (not in the compiler, of
course. In the library.)
And unfortunately, his next example also compiles in D. At least
D has some rationale for allowing this in the fact that it's a
systems-level language, but this is still awful.
import std.stdio;
void main()
{
float f = long.max;
int n = int.max;
auto x = f - n;
writeln(typeof(x).stringof, , x);
}
Re: Interesting rant about Scala's issues
Whoops, should be:
import std.stdio;
void main()
{
float x1 = long.max;
float x2 = long.max - int.max;
writeln(typeof(x2).stringof, , x2);
}
Not that it makes a difference.
Re: Interesting rant about Scala's issues
Meta: Returning an int to denote less than, equal, and greater than is a very small complexity, and makes it very fast to check the result. The point of that part of the rant is that using an integer is very not-precise, typing-wise. Having more precise typing sometimes helps. In a little higher level language using a 3-value enum (as in Haskell, more or less) is still sufficiently efficient. And Ada language shows that often you can have both precise types (strong typing) and almost C-like efficiency. Bye, bearophile
Re: Interesting rant about Scala's issues
On Fri, Apr 04, 2014 at 00:59:23 +, Meta wrote:
His examination of the compare function was interesting. I think,
though, that it's misguided, and not one of Scala's problems.
Maybe not major, but it's not completely ignorable.
Returning an int to denote less than, equal, and greater than is a
very small complexity, and makes it very fast to check the result.
See, this is *exactly* his point. You're basically putting the well, C
does it and int is fast as your rationale. I think by this point, we
(as a collective community) have seen that C has some serious flaws when
you start allowing user input from untrusted sources into your code. The
latter is easily classified as premature optimization.
There is *zero* rationale as to why this would be a compilable
implementation of comparison:
int compare(int a, int b) {
return a * b;
}
The fact that this compiles when used as a comparison is *insane* when
you take a fresh look at how you can construct a language.
If you have sum types, you can both deny the above silliness and
represent it as an integer and be just fine. In fact, you're possibly
better off since you can now do:
add $offset $compare_result
jmp *$offset
rather than doing 2 comparisons and a branch since you *know* the result
will never be more than 2.
--Ben
Re: Interesting rant about Scala's issues
On 4/3/2014 6:14 PM, Meta wrote: A more interesting point of his is the limitation of Scala's ability to optimize functions like filter... This is also a problem in D, but not as visible as we do not have macros to perform the sort of transformation he describes (turning filter f1, filter f2, filter f3 into filter f1 f2 f3). Maybe we should think about enforcing that lambas passed to higher order functions are pure, when we can (not in the compiler, of course. In the library.) Since in D you can detect if a function is pure, and specialize accordingly, it is not necessary to require that the filter function be pure.
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 01:31:20 UTC, bearophile wrote:
The point of that part of the rant is that using an integer is
very not-precise, typing-wise. Having more precise typing
sometimes helps.
In a little higher level language using a 3-value enum (as in
Haskell, more or less) is still sufficiently efficient. And Ada
language shows that often you can have both precise types
(strong typing) and almost C-like efficiency.
Bye,
bearophile
I would agree if D actually had type-safe enums.
enum a
{
val = 1
}
enum b
{
val = 1
}
assert(a.val - b.val == 0);
Re: Interesting rant about Scala's issues
On Thu, Apr 03, 2014 at 18:51:56 -0700, Walter Bright wrote: Since in D you can detect if a function is pure, and specialize accordingly, it is not necessary to require that the filter function be pure. Is there a built-in compose operator or function (Haskell's (.) operator)? How would you copy the common attributes of the composed functions to the new function (if not builtin)? --Ben
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 01:51:58 UTC, Walter Bright wrote: Since in D you can detect if a function is pure, and specialize accordingly, it is not necessary to require that the filter function be pure. That's true, but then somebody somewhere accidentally passes in a delegate that references some outside state, and performance is suddenly shot for no apparent reason. The upside in D is that you can explicitly mark delegates as pure and have the compiler check for you, but that still puts the onus on the user to be disciplined and not forget.
Re: Interesting rant about Scala's issues
Meta:
I would agree if D actually had type-safe enums.
enum a
{
val = 1
}
enum b
{
val = 1
}
assert(a.val - b.val == 0);
C enums are mostly type unsafe. C++11 has enum class that is
strongly typed. D enums are intermediate (and it has final
switches). I have asked for fully typesafe enums in D, but in
several years I think Walter has never answered, nor he has
explained why D has chosen such intermediate point. I presume
this choice is based on practical reasons, but I don't know
exactly what they are (perhaps to minimize the number of casts).
D used to have several corners of weak typing (like a partial
confusion between pointers and dynamic arrays) that later have
being (painfully and slowly) fixed (and this despite D Zen is
supposed to prefer a strict design first, followed by some
relaxations later).
Bye,
bearophile
Re: Interesting rant about Scala's issues
On 4/3/2014 7:01 PM, Ben Boeckel wrote: Is there a built-in compose operator or function (Haskell's (.) operator)? How would you copy the common attributes of the composed functions to the new function (if not builtin)? The compiler does attribute inference for template functions and lambdas.
Re: Interesting rant about Scala's issues
On 4/3/2014 7:00 PM, Meta wrote: The upside in D is that you can explicitly mark delegates as pure and have the compiler check for you, but that still puts the onus on the user to be disciplined and not forget. It's really like everything else in programming - at some point, if you don't avail yourself of the checking features, you have to check it yourself.
Re: Interesting rant about Scala's issues
On 4/3/2014 7:19 PM, bearophile wrote: I have asked for fully typesafe enums in D, but in several years I think Walter has never answered, nor he has explained why D has chosen such intermediate point. I presume this choice is based on practical reasons, but I don't know exactly what they are (perhaps to minimize the number of casts). Because every cast breaks the type system. A type system that requires too many casts for normal things is NOT a type safe system. I have explained this on numerous occasions.
Re: Interesting rant about Scala's issues
On 4/3/2014 7:19 PM, bearophile wrote:
I have asked for fully typesafe enums in D,
You can do this:
struct MyInt {
int x;
alias this x;
... put your various constraints here ...
}
to get typesafe enums. In fact, you can use this construct to create a type that
overrides selected behaviors of any other type.
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 04:31:41 UTC, Walter Bright wrote:
On 4/3/2014 7:19 PM, bearophile wrote:
I have asked for fully typesafe enums in D,
You can do this:
struct MyInt {
int x;
alias this x;
... put your various constraints here ...
}
to get typesafe enums. In fact, you can use this construct to
create a type that overrides selected behaviors of any other
type.
Combined with your other post about casts, I'm not sure we're
talking about the same kind of type-safety. In the case of your
example, alias this does not make it typesafe, as a MyInt can
still be implicitly converted to int.
struct MyInt
{
int x;
alias x this;
}
void takesInt(int n)
{
}
void main()
{
//Fine
takesInt(MyInt(1));
}
Implicit conversions are generally not a facet of type-safe
systems. Saying that too-strong typing is bad because casts break
the type system is a strawman, although I agree that there is a
balance that must be struck.
Re: Interesting rant about Scala's issues
Andrei Alexandrescu: A lot of them could apply to us as well. https://www.youtube.com/watch?v=TS1lpKBMkgg The slides: http://www.slideshare.net/extempore/keynote-pnw-scala-2013 Bye, bearophile
Re: Interesting rant about Scala's issues
On 4/2/2014 6:55 PM, Andrei Alexandrescu wrote: A lot of them could apply to us as well. https://www.youtube.com/watch?v=TS1lpKBMkgg Reminds me of our empty-front-popFront discussion. Trying to support all kinds of variations on that results in unoptimizable code.
Re: Interesting rant about Scala's issues
Andrei Alexandrescu: A lot of them could apply to us as well. https://www.youtube.com/watch?v=TS1lpKBMkgg I agree that D language/compiler could improve its integration with versioning systems (slide 31). How to design this? Bye, bearophile
