dynamic classes and duck typing

[retard]

Wed, 02 Dec 2009 21:16:28 +0000, BCS wrote:

> Hello Leandro,

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

Both the language used to represent D metaprograms and D are suboptimal 
for many kinds of DSLs. A dynamic language can provide better control 
over these issues without resorting to manual string parsing. If the DSL 
is closer to the problem domain, it can have a great effect on program 
correctness.

For instance, you could define natural language like statements in your 
DSL with functional composition. In D you basically have to write all 
metaprograms inside strings and parse them with CTFE functions. In e.g. 
lisp or io the DSL is on the same abstraction level as the main language. 
These are of course slow, but in some environments you need to be able to 
provide non-developers an intuitive interface for writing business logic. 
Even the runtime metaprogramming system can provide optimizations after 
the DSL has been processed.

I understand your logic. It's very simple. You use metaprogramming to 
improve performance. That's also the reason you use D - it's the language 
that can provide greatest performance once the compiler has matured a 
bit. To me program inefficiency is a rather small problem today. Most 
programs perform fast enough. But they crash way too often and leak 
memory. The fact that Walter actually favors segfaults won't fix the #1 
problem. The fact that D has a conservative GC won't fix the #2. Other 
problems we face today are e.g. vendor lock-in in forms of tivoization, 
closed binaries, and cloud computing. D doesn't help here either. It 
doesn't enforce copyleft (e.g. AGPL) and features like inline assembler 
encourage the use of drm systems.