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.
