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.

On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright <newshound2@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.

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.

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

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

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.

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..

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

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.

On 4/4/2014 12:23 AM, Rory McGuire wrote:
> On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@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.