dynamic classes and duck typing

[BCS]

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

I rather like doing meta program and I've only done one program that uses 
string parsing. Aside from that one, the two or three most complicated libs 
I've done work 100% within the normal D grammar.

Show me ONE thing that can be done using run time meta programming that can't 
be done as well or better with run time, non-dynamic, non-meta and/or compile 
time meta. Unless I'm totally clueless as to what people are talking about 
when they say runtime meta, I don't think you will be able to. Anything that 
amounts to making the syntax look nicer can be done as compile time meta 
and anything else can be done with data structure walking and interpretation. 
All of that is available in non dynamic languages. 

I guess I should concede the eval function but if you don't like CTFE+mixin...

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

I dispute that claim.

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

No, that is a flawed statement. ONE of the things I use metaprogramming for 
is to improve performance. Look at my parser generator, my equation solver 
and my units library. None of these have performance as a main driving motivation. 
For most of the stuff I've done where perf is even considered, it's not a 
mater of "lets make this faster by doing it meta" it a mater of "if this 
solution wasn't done meta, it wouldn't be viable and a more conventional 
solution would". But even that isn't the norm.

> 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,

Why is that a problem?

> and cloud computing. 

I've never liked the cloud model, but not from the lock-in issues.

> D doesn't help here either. It doesn't enforce copyleft (e.g. AGPL)

And I think it shouldn't.

> and features like inline assembler encourage the use of drm systems.

How does that follow?