On 4/10/13 1:50 PM, Paulo Pinto wrote:
> Everyone seems to be having them, it is as if after realizing that in
> many cases aggregation is better than inheritance, multi-methods is also
> a better way to add attach behaviour to objects.

My perception is that there's an exponential falloff as follows: 99% of all cases are handled by single dispatch; 0.9% are handled by double dispatch; 0.09% are handled by triple dispatch; ...

I'd tell any language designer - don't worry about multiple dispatch. Spend that time on anything else, it'll be better invested.


Andrei

On 4/10/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 4/10/13 1:33 PM, Manu wrote:
>>     It may as well be a mistake that nonvirtual functions are at all
>>     part of a class' methods. This has been quite painfully seen in C++
>>     leading to surprising conclusions: http://goo.gl/dqZrr.
>>
>>
>> Hmm, some interesting points. Although I don't think I buy what he's selling.
>
> That article ain't sellin'. It's destroyin'.

UFCS can't be the penultimate solution, for example:

class S(T)
{
    alias Type = SomeTypeModifier!T;

    static if (isSomePredicate!Type)
    {
        int x;
        void foo() { /* do something with x */ }
    }
    else
    {
        float y;
        void bar() { /* do something with y */ }
    }
}

How do you implement this with UFCS? It wouldn't look nice if you had to put those methods outside, while keeping the data inside. You'd have to duplicate static ifs outside and inside the class.

Am 10.04.2013 20:16, schrieb Andrei Alexandrescu:
> On 4/10/13 1:50 PM, Paulo Pinto wrote:
>> Everyone seems to be having them, it is as if after realizing that in
>> many cases aggregation is better than inheritance, multi-methods is also
>> a better way to add attach behaviour to objects.
>
> My perception is that there's an exponential falloff as follows: 99% of
> all cases are handled by single dispatch; 0.9% are handled by double
> dispatch; 0.09% are handled by triple dispatch; ...
>
> I'd tell any language designer - don't worry about multiple dispatch.
> Spend that time on anything else, it'll be better invested.
>
>
> Andrei
>

I agree with you, I doubt there are that much cases where more than double dispatch is required.

But they make nice language puzzles. :)

--
Paulo

On 2013-04-10, 19:46, Paulo Pinto wrote:


> Manu, maybe something you might not be aware:
>
> - Smalltalk
> - Eiffel
> - Lisp
> - Java
> - Self
> - Dylan
> - Julia
> - Objective-C
> - JavaScript
>
> Are just a few examples of languages with virtual semantics for method call. Some of those only offer virtual dispatch actually.
>
> Some of them were developed in an age of computer systems that would make today's embedded systems look like High Performance Computing servers.

The fact that successful languages have been created where virtual
dispatch is the default, or even the only possibility, does not mean
that virtual dispatch is not slower than non-virtual, nor, especially,
that this inefficiency might be a problem in some fields.

Sure, games have been written in most of these languages. AAA titles
today have somewhat stricter needs, and virtual dispatch by default is
most definitely a problem there.


> Julia is actually a new kid on block, hardly one year old, and already achieves C parity in many benchmarks.

On their website (http://julialang.org/), they show two such benchmarks,
both of which seem to be exactly the kind where virtual dispatch is not
going to be a problem when you have a JIT.


> So I think how much could be a problem of D's compilers and not the virtual by default concept in itself.

Look once more at that list. They're all dynamically typed, have JITs
or the like (possibly with the exception of Eiffel). In other words,
they do devirtualization at runtime.

-- 
Simen

On 4/10/13 2:26 PM, Andrej Mitrovic wrote:
> On 4/10/13, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> On 4/10/13 1:33 PM, Manu wrote:
>>>      It may as well be a mistake that nonvirtual functions are at all
>>>      part of a class' methods. This has been quite painfully seen in C++
>>>      leading to surprising conclusions: http://goo.gl/dqZrr.
>>>
>>>
>>> Hmm, some interesting points. Although I don't think I buy what he's
>>> selling.
>>
>> That article ain't sellin'. It's destroyin'.
>
> UFCS can't be the penultimate solution, for example:
>
> class S(T)
> {
>      alias Type = SomeTypeModifier!T;
>
>      static if (isSomePredicate!Type)
>      {
>          int x;
>          void foo() { /* do something with x */ }
>      }
>      else
>      {
>          float y;
>          void bar() { /* do something with y */ }
>      }
> }
>
> How do you implement this with UFCS? It wouldn't look nice if you had
> to put those methods outside, while keeping the data inside. You'd
> have to duplicate static ifs outside and inside the class.

Agreed.

Andrei

On Wed, 10 Apr 2013 10:58:03 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Wed, Apr 10, 2013 at 07:35:27PM +0200, Paulo Pinto wrote:
> > 
> > This is what makes me happy while travelling on the bus and train:
> > 
> > https://play.google.com/store/apps/details?id=com.larvalabs.gurk
> [...]
> 
> Yeah!!! I recently played Gurk II (which according to reviews is even better than the original Gurk), and totally loved it!! It was so nostalgic that it inspired me to fire up my trusty old dosbox and relive the good ole ultima 4&5 days. :-)
> 
> Granted, I *did* discover to my dismay that the pixel graphics and tinny sounds of the *original* ultima 4&5 are a lot worse than how my memory recalls they were (the pain was somewhat relieved upon installing the graphics upgrade patch) -- but man, the gameplay was excellent. The NPC dialogues were obviously trivial, monster AI was trivially predictable, and there are tons of loopholes that you can exploit -- but the important thing was, it was FUN. I could totally immerse myself in the virtual world and forget about the pixels and loopholes.  I'm afraid I can't say the same for most modern games with their fancy 3D graphics, CD-quality sound, superior AI, etc.. The fun factor is just missing, even though all the superficial elements -- graphics, sounds, AIs, storylines -- are all far more developed.
> 
> Gurk II captures some of the fun gameplay of the original (pre-7) ultimas, and proves that a modern game without 3D graphics and a multimillion budget *can* be fun (and, judging from the reviews, it's selling pretty well too).
> 

This all reminds me, if you have an NDS, or access to one, you may want to try "Retro Game Challenge". Actually, I highly recommend it.

(Disclaimer: That's the English version of it. When I played it no English version had been announced, and it looked far too awesome to be something likely to get localized, so I went through the Japanese version, "Game Center CX: Arino's Challenge". So I don't know what differences there may be).

It takes you chronologically through the 1980's with a series of brand new 8-bit-style games, all extremely authentic, culminating with an 8-bit-style JRPG. Absolutely fantastic game. I only wish there had been a non-portable version so I could play it on a nice big TV...and that I knew more Japanese so I could actually tell what the hell anyone was saying ;)

Am 10.04.2013 20:32, schrieb Simen Kjaeraas:
> On 2013-04-10, 19:46, Paulo Pinto wrote:
>
>
>> Manu, maybe something you might not be aware:
>>
>> - Smalltalk
>> - Eiffel
>> - Lisp
>> - Java
>> - Self
>> - Dylan
>> - Julia
>> - Objective-C
>> - JavaScript
>>
>> Are just a few examples of languages with virtual semantics for method
>> call. Some of those only offer virtual dispatch actually.
>>
>> Some of them were developed in an age of computer systems that would
>> make today's embedded systems look like High Performance Computing
>> servers.
>
> The fact that successful languages have been created where virtual
> dispatch is the default, or even the only possibility, does not mean
> that virtual dispatch is not slower than non-virtual, nor, especially,
> that this inefficiency might be a problem in some fields.
>
> Sure, games have been written in most of these languages. AAA titles
> today have somewhat stricter needs, and virtual dispatch by default is
> most definitely a problem there.
>
>
>> Julia is actually a new kid on block, hardly one year old, and already
>> achieves C parity in many benchmarks.
>
> On their website (http://julialang.org/), they show two such benchmarks,
> both of which seem to be exactly the kind where virtual dispatch is not
> going to be a problem when you have a JIT.
>
>
>> So I think how much could be a problem of D's compilers and not the
>> virtual by default concept in itself.
>
> Look once more at that list. They're all dynamically typed, have JITs
> or the like (possibly with the exception of Eiffel). In other words,
> they do devirtualization at runtime.
>


You are right, I just discussing about virtual dispatch in general.

Yeah, maybe it is really not that desired in languages with AOT compilation.

--
Paulo

On 04/10/2013 01:14 PM, Nick Sabalausky wrote:
>
> Well yea, Quantic Dream goes WAAAAAY off into the "interactive movie"
> realm.

Because that's what the game is. There's nothing wrong with it if you like it, and many people do.

> Keep in mind, I'm using "interactive movie" largely for lack of a
> better term. "Videogame" definitely isn't the right word for them.

They're games, and they use the video medium. Video games. The rest of your post is mostly just a rant about what you personally like in video games/"interactive movies". You are of course entitled to an opinion, but the grumpy old man ranting gets old.

On 4/10/13 4:35 PM, Jeff Nowakowski wrote:
> On 04/10/2013 01:14 PM, Nick Sabalausky wrote:
>>
>> Well yea, Quantic Dream goes WAAAAAY off into the "interactive movie"
>> realm.
>
> Because that's what the game is. There's nothing wrong with it if you
> like it, and many people do.
>
>> Keep in mind, I'm using "interactive movie" largely for lack of a
>> better term. "Videogame" definitely isn't the right word for them.
>
> They're games, and they use the video medium. Video games. The rest of
> your post is mostly just a rant about what you personally like in video
> games/"interactive movies". You are of course entitled to an opinion,
> but the grumpy old man ranting gets old.

FWIW there's this Neal Stephenson novel "Diamond Age" taking place in the future. That book's vision is that all modern movies are "ractive" (short from "interactive") using networked real players and a loose script, whereas old movies are "passive"s and only watched by a few older people.

Andrei

On Wednesday, 10 April 2013 at 06:03:08 UTC, Manu wrote:
> Can you demonstrate a high level class, ie, not a primitive tool, but the
> sort of thing a programmer would write in their daily work where all/most
> functions would be virtual?
> I can paste almost any class I've ever written, there is usually 2-4
> virtuals, among 20-30 functions.
>

In my case it was a C++ virtual class used to supply a common interface to various database libraries. This is not a usual thing, so your point is valid, and I'll agree that most often your classes will have proportionally far less virtual functions overall. It's mostly the base classes that will contain the most virtual functions, but derived classes generally outnumber them.

>>
>> Mark your properties as final?
>>
>
> That's 90% of the class! You are familiar with OOP right? :)
> Almost everything is an accessor...

Based on what I've learned from this thread, to get the best performance I'll have to wrap up almost all my D classes with "final", or take the more painful alternative route and move all non virtual functions into UFCS.

I can understand the argument in favor if UFCS as the "final" solution, however it's something I'd have to try out first before making a conclusion. Off hand it seem like more work (an example with static if's was shown already), and for code structuring and readability it seems to me it won't be helpful. Again these are my first impressions without actually trying it out, so who knows, it may work well despite my concerns.

>
> Correct, it's not quite a systems language while the GC does whatever it
> wants. But D needs the GC to be considered a 'modern', and generally
> productive language.

The GC issue is a recurring one (how many threads on this topic?) because the current implementation directly interferes with the stated goals of D being a systems language.

Not only can the GC be fixed in simple ways (eg just give us programmers more control over how and when it does its job), but we can do one better than just improving the GC, and it's through marking sections of code as off limits to anything that may allocate, and even better than that in more general terms, prevent the use a feature (or features) of the language that is not appropriate for a marked section of code. That'll make me very happy.

--rt