April 17, 2009
Denis Koroskin wrote:
> On Fri, 17 Apr 2009 23:23:52 +0400, Don <nospam@nospam.com> wrote:
> 
>> Yeah, The ideal language would detect ALL bugs at compile time. We don't  want to move in the wrong direction.
>>
> 
> I would consider it a "wrong direction". You won't use it *that* frequent, only in those places where it trully fits.
> For example, a Variant class and scripting languages bindings would greatly benefit for having this functionality.

Yah, for example Variant could define opDotExp to look whether the currently stored type supports the name. With the appropriate compile-time introspection it could make that quite fast too. Pretty awesome if you ask me.

I'm very excited about this.


Andrei
April 17, 2009
Don wrote:
> Leandro Lucarella wrote:
>> Nick Sabalausky, el 17 de abril a las 14:45 me escribiste:
>>>> I'm not yet convinced, but it remains to be seen if there is some killer functionality that cannot be had without it.
>>> Same here. So far, it just doesn't seem worth the loss of knowing at a glance what is and what might not be verified at compile-time. If I wanted to be throwing compile-time guarantees out the window, I'd go use PHP.
>>
>> Being able to do it doesn't mean you have to use it always. You don't
>> loose anything if you don't use it =)
> 
> Correction: You don't lose anything if *nobody you interact with* uses it. A feature that is wide open to abuse is dangerous, even if you'll never abuse it yourself.
> The feature has to be worth using.
> 

On the other hand, using the feature requires some due diligence. It doesn't strike me as a dangerous feature that's also the path of last resistance, like casts.

Andrei
April 17, 2009
"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gsak2p$1s8a$1@digitalmars.com...
>
> I think there's merit in binding via strings. It makes for very flexible code that is future-proof, dynamic-linking-friendly, and hot-swappable without recompiling (e.g. you don't need to recompile because you now implement an interface etc.) Reflection is very useful as well.
>
> I think D can and should allow string lookup for its methods. It's a low-complexity proposition that adds a very interesting tool to D's arsenal.
>

That's a separate issue. I absolutely agree with the usefulness of being able to invoke static methods via a string identifier at runtime. But I think opDotExp is an extremely flawed way to do it. A much better way would be through a reflection mechanism:

class Foo
{
    void bar() {}
}

auto foo = new Foo();
traits(foo).func("bar").invoke();

That way, you can have the benefits of runtime-string-identifier-invocation (and have it on *every* class/method), but without completely loosing compile-time checking on the members of every class which is capable of using it.

> If anything, this agreed-fest shows that the rift between static typing and dynamic typing is alive and well. I've seen many discussions in which people were mystified how anyone gets anything done in a statically-typed OO language.

...Doesn't necessarily mean both sides have valid points. Just that there's disagreement. Outside of diplomacy, it doesn't make any sense to agree with something you disagree with, or disagree with something you agree with, just for the sake a closing a rift. Better to just continue debating the issues with logical arguments. If nothing gets accomplished, well ok, fine, but so what? That's a lot better than coming to hasty-but-wrong agreement just for the sake of agreement.

I guess what I'm saying is, people coming to an agreement is all fine and dandy, but the most important thing is to arrive at the *correct* agreement. If one group of people insist that "2+2=0" and another group insists that "2+2=10", then it's far better to keep analyzing and debating until "2+2=4" is discovered and proven than to say "let's all be happy!" and hastily agree that "2+2=5". Again, outside of diplomacy, people disagreeing is not the real problem, the real problem is that the best answer either hasn't been found or hasn't been unquestionably shown to be best.


April 17, 2009
Leandro Lucarella:
> Being able to do it doesn't mean you have to use it always. You don't loose anything if you don't use it =)

It adds complexity to the language. More things to know and remember and understand, and so on. Generally adding complexity has a cost.

Bye,
bearophile
April 17, 2009
Nick Sabalausky wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gsak2p$1s8a$1@digitalmars.com...
>> I think there's merit in binding via strings. It makes for very flexible code that is future-proof, dynamic-linking-friendly, and hot-swappable without recompiling (e.g. you don't need to recompile because you now implement an interface etc.) Reflection is very useful as well.
>>
>> I think D can and should allow string lookup for its methods. It's a low-complexity proposition that adds a very interesting tool to D's arsenal.
>>
> 
> That's a separate issue. I absolutely agree with the usefulness of being able to invoke static methods via a string identifier at runtime. But I think opDotExp is an extremely flawed way to do it. A much better way would be through a reflection mechanism:
> 
> class Foo
> {
>     void bar() {}
> }
> 
> auto foo = new Foo();
> traits(foo).func("bar").invoke();
> 
> That way, you can have the benefits of runtime-string-identifier-invocation (and have it on *every* class/method), but without completely loosing compile-time checking on the members of every class which is capable of using it.

I was expecting this objection. I think it's not based because unifying syntax is a major part of adding such a feature. If we get to dynamic invocation but we can't go the last mile, we failed. Look at IDispatch-based programming in C++ vs. interpreted languages.

>> If anything, this agreed-fest shows that the rift between static typing and dynamic typing is alive and well. I've seen many discussions in which people were mystified how anyone gets anything done in a statically-typed OO language.
> 
> ...Doesn't necessarily mean both sides have valid points. Just that there's disagreement. Outside of diplomacy, it doesn't make any sense to agree with something you disagree with, or disagree with something you agree with, just for the sake a closing a rift. Better to just continue debating the issues with logical arguments. If nothing gets accomplished, well ok, fine, but so what? That's a lot better than coming to hasty-but-wrong agreement just for the sake of agreement.

Of course. One thing that suggests the righteousness is not necessarily on your side is that plenty knowledgeable, intelligent, credible people use and advocate dynamic typing. Asserting that they simply miss the point is a bit tenuous.

> I guess what I'm saying is, people coming to an agreement is all fine and dandy, but the most important thing is to arrive at the *correct* agreement. If one group of people insist that "2+2=0" and another group insists that "2+2=10", then it's far better to keep analyzing and debating until "2+2=4" is discovered and proven than to say "let's all be happy!" and hastily agree that "2+2=5". Again, outside of diplomacy, people disagreeing is not the real problem, the real problem is that the best answer either hasn't been found or hasn't been unquestionably shown to be best. 

I'm with you, and in wake of my frequent postings I guess it's pretty known by now that nothing makes me more annoying than knowing 100% I'm right :o). Certainly I'm not one who "agrees to disagree" and I'm glad you aren't either.


Andrei
April 17, 2009
"Yigal Chripun" <yigal100@gmail.com> wrote in message news:gsam1p$1ut7$1@digitalmars.com...
> On 17/04/2009 21:58, Steven Schveighoffer wrote:
>
> btw, I'm not trying to convince you that dynamic typing is necessary always a better solution. What I'm saying is that I agree with Andrei - we need to be open minded and have as many useful tools as possible in our programmer toolbox. The important thing is to choose the right tool for the job.
>

Typically, yes, having "as many useful tools as possible in our programmer toolbox" is great. But with opDotExp, that's not the whole story. What opDotExp is, is a tool of only occasional use that provides only a small benefit, *and* ends up destroying a much more important tool: compile-time checking on a class's members.

Yea, sure I want more tools in my programmer tool box. But I don't want a minor one that's going to mess up one of my major ones just by being in there.


April 17, 2009
bearophile wrote:
> Leandro Lucarella:
>> Being able to do it doesn't mean you have to use it always. You don't
>> loose anything if you don't use it =)
> 
> It adds complexity to the language. More things to know and remember and understand, and so on. Generally adding complexity has a cost.
> 
> Bye,
> bearophile

I agree. I think in this case the complexity addition is well worth the benefits.

Andrei
April 17, 2009
Nick Sabalausky wrote:
> "Yigal Chripun" <yigal100@gmail.com> wrote in message news:gsam1p$1ut7$1@digitalmars.com...
>> On 17/04/2009 21:58, Steven Schveighoffer wrote:
>>
>> btw, I'm not trying to convince you that dynamic typing is necessary always a better solution. What I'm saying is that I agree with Andrei - we need to be open minded and have as many useful tools as possible in our programmer toolbox. The important thing is to choose the right tool for the job.
>>
> 
> Typically, yes, having "as many useful tools as possible in our programmer toolbox" is great. But with opDotExp, that's not the whole story. What opDotExp is, is a tool of only occasional use that provides only a small benefit, *and* ends up destroying a much more important tool: compile-time checking on a class's members.

s/on a class's members/on the members of the class that actively chose that/

> Yea, sure I want more tools in my programmer tool box. But I don't want a minor one that's going to mess up one of my major ones just by being in there.


I don't think this argument holds.

Andrei
April 17, 2009
Andrei Alexandrescu wrote:
> Don wrote:
>> Andrei Alexandrescu wrote:
>>> I think there's merit in binding via strings. It makes for very flexible code that is future-proof, dynamic-linking-friendly, and hot-swappable without recompiling (e.g. you don't need to recompile because you now implement an interface etc.) 
>>
>> Does that still apply to the template version you proposed?
> 
> Of course. The template version includes the version that only does dynamic lookup: you can do static, and you can do dynamic. The static part allows you e.g. to optimize some cases if you so wish. With the runtime string you can only do dynamic.

I was thinking that, for example, in a DLL, the DLL needs to include a compiled version of each function name it uses; in the non-template version there are no new compiled version.
I haven't thought through the implications of this. I guess that it's really no different to foo!("funcname")(args), though.
Makes __traits(membersOf) rather interesting -- not necessarily a pure function, might change with time!

> 
> Again, making it a template in this case is a win-win thing. There's nothing inferior about it.

I have no doubt it's better for D. I think it's the only option which is viable in a statically-typed language.

> 
> 
> Andrei
April 17, 2009
"bearophile" <bearophileHUGS@lycos.com> wrote in message news:gsam1l$1usu$1@digitalmars.com...
>
> The end result is that writing tests in Python is usually not as bad as you think.
>

Maybe so, but I don't see any real benefit from it.