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?
