dynamic classes and duck typing

[BCS]

Hello Leandro,

> BCS, el  2 de diciembre a las 17:37 me escribiste:
> 
>> Hello Leandro,
>> 
>>> If you say dynamic languages don't have metaprogramming
>>> capabilities, you just don't have any idea of what a dynamic
>>> language really is.
>>> 
>> If you say you can do metaprogramming at runtime you just don't have
>> any idea of what I want to do with metaprogramming. For example:
>> 
> What you say next, is not metaprogramming per se, they are performance
> issues (that you resolve using compile-time metaprogramming). You're
> missing the point.
> 

No you're missing MY point. I was very careful to add "what I want to do 
with" to my statement. It might not be true for you but what I asserts is 
true for me. Most of the things *I* want from metaprogramming must be done 
as compile time metaprogramming. Saying "dynamic languages can do something 
at run time" doesn't imply that there is nothing more to be had by doing 
it at compile time.

>> unit carrying types: check for unit errors (adding feet to seconds)
>> at compile time. I can be sure there are no unit error without
>> knowing if I've executed every possible code path.
>> 
> There is no compile time metaprogrammin in dynamic languages, you just
> can't verify anything at compile time, of course you can't do that!
> 
> Again, you are talking about performance issues, that's doable in a
> dynamic languages, the checks are just runned at run time.
> 

The reason for doing the checks at compile time are not performance but correctness. 
I want to know a priori that the code is correct rather than wait till runtime.

>> Domain specific compile time optimizations: Evaluate a O(n^3)
>> function so I can generate O(n) code rather than write O(n^2) code.
>> If you do that at runtime, things get slower, not faster.
>> 
> Again *optimization*. How many times should I say that I agree that D
> is better than almost every dynamic languages if you need speed?

I'm not arguing on that point. What I'm arguing is that (at least for me) 
the primary advantages of metaprogramming are static checks (for non-perf 
benefits) and performance. Both of these must be done at compile time. Runtime 
metaprogramming just seems pointless *to me.*

>> Any language that doesn't have a "compile time" that is evaluated
>> only once for all code and before the product ships, can't do these.
>> 
> You are right, but if you *don't* need *speed*, you don't need all
> that stuff, that's not metaprogramming to fix a "logic" problem, they
> are all optimization tricks, if you don't need speed, you don't need
> optimization tricks.

Personally, I'd rater use non-metaprograming solutions where runtime solutions 
are viable. They are generally easier to work (from the lib authors standpoint) 
with and should be just as powerful. The API might be a little messier but 
you should be able to get just as much done with it.

> 
> The kind of metaprogramming I'm talking about is, for example,
> generating boring, repetitive boilerplate code.

For that kind of things, if I had a choice between compile time meta, run 
time meta and non meta, that last one I'd use is run-time meta.