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.

BCS, el  2 de diciembre a las 21:16 me escribiste:
> 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.

Well, I will have to do like Monty Python then. This thread is getting too
silly, so I'll have to end it.
http://www.youtube.com/watch?v=yTQrCjP14tA

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
¿Cómo estais? ¿Cómo os senteis hoy 29 del membre de 1961 día en que
conmemoreramos la nonésima setima nebulización del martir Peperino
Pómoro junto al Rolo Puente en la ciudad de Jadad?
	-- Peperino Pómoro

Don, el  2 de diciembre a las 22:20 me escribiste:
> Leandro Lucarella wrote:
> >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).
> 
> They are metaprogramming tasks. Dynamic languages can do some metaprogramming tasks. They can't do those ones.

Because they make no sense, I really don't know how to put it. If you need speed, you code in C/C++/D whatever. Its like saying that you can't fly with a car and that's a problem. It's not, cars are not supposed to fly. If you need to fly, go buy a plane or a helicopter. Of course is much cooler to fly than to drive a car, but if you need to go just a couple of miles, flying gets really annoying, and it would take you more time, money and effort to do it than using your car.

> >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.
> 
> "you don't need speed" is a pretty glib statement. I think the

I don't know what that means...

> reality is that you don't care about constant factors in speed, even if they are large (say 200 times slower is OK). But bubble-sort is probably still not acceptable.

Bubble sort is perfeclty acceptable for, say, a 100 elements array.

> Metaprogramming can be used to reduce big-O complexity rather than just constant-factor improvement. Lumping that in with "optimisation" is highly misleading.

It always depends on the context, of course, but when doing programs that deals with small data sets and are mostly IO bounded, you *really* can care less about performance and big-O.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
"CIRILO" Y "SIRACUSA" DE "SEÑORITA MAESTRA": UNO MUERTO Y OTRO PRESO
	-- Crónica TV

BCS wrote:
> 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.*

One of important applications of metaprogramming is code generation which would be too tedious or bug-prone to generate and support manually.  Dynamic languages can definitely provide for that.

Hello Leandro,

> Don, el  2 de diciembre a las 22:20 me escribiste:
> 
>> They are metaprogramming tasks. Dynamic languages can do some
>> metaprogramming tasks. They can't do those ones.
>> 
> Because they make no sense, I really don't know how to put it. If you
> need speed, you code in C/C++/D whatever. Its like saying that you
> can't fly with a car and that's a problem. It's not, cars are not
> supposed to fly. If you need to fly, go buy a plane or a helicopter.
> Of course is much cooler to fly than to drive a car, but if you need
> to go just a couple of miles, flying gets really annoying, and it
> would take you more time, money and effort to do it than using your
> car.
> 

Saying "you can do that at runtime" re dynamic languages and D's meta programming is like saying a VW bug can carry rock when someone's looking for a pickup to move gravel in. Yes it's technically correct, but there are any thing a pickup can do that the bug can't (and the same the other way).

The same things is true of the topic at hand; dynamic language can do /some/ of what D's meta stuff can do, but not all of it. And I'll point out yet again; not all of the extra things D does are perf related.

And befor you say it; yes ther are seom things dynamic languages beat D at. All I'm saying is that meta isn't one of them.

>> Metaprogramming can be used to reduce big-O complexity rather than
>> just constant-factor improvement. Lumping that in with "optimisation"
>> is highly misleading.
>> 
> It always depends on the context, of course, but when doing programs
> that deals with small data sets and are mostly IO bounded, you
> *really* can care less about performance and big-O.
> 

1) If I can write a lib that given me a better O() for the same effort (once the lib is written) I *Always* care about O()
2) For all programs, the program is irrelevant or you will have someone throw more input at it than you ever expected.
3) the phrase is "can't care less" (sorry, nitpicking)

Hello Sergey,

> BCS wrote:
> 
>> 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.*
>> 
> One of important applications of metaprogramming is code generation
> which would be too tedious or bug-prone to generate and support
> manually.  Dynamic languages can definitely provide for that.
> 

They can, but I question if it's the best way to do it in those languages. Generating code and running it at runtime seems to be pointless. Why have the intermediate step with the code? I have something I want to do, so I use encode it as one abstraction (a DSL), translate it into another (the host language) and then compute it in a third (the runtime). If it's all at runtime anyway, why not just use the runtime to evaluate/interpret the DSL directly. 

On Wed, Dec 2, 2009 at 3:26 PM, BCS <none@anon.com> wrote:
> Hello Sergey,
>
>> BCS wrote:
>>
>>> 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.*
>>>
>> One of important applications of metaprogramming is code generation which would be too tedious or bug-prone to generate and support manually.  Dynamic languages can definitely provide for that.
>>
>
> They can, but I question if it's the best way to do it in those languages. Generating code and running it at runtime seems to be pointless. Why have the intermediate step with the code? I have something I want to do, so I use encode it as one abstraction (a DSL), translate it into another (the host language) and then compute it in a third (the runtime). If it's all at runtime anyway, why not just use the runtime to evaluate/interpret the DSL directly.

You may be able to memoize the generated code so you only have to
generate it once per run, but use it many times.
Probably performance is the reason you wouldn't want to reinterpret
the DSL from scratch every use.  Even dynamic language users have
their limits on how long they're willing to wait for something to
finish.

--bb

retard wrote:
> 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. 

Static dimensional analysis doesn't improve performance, and I recall he mentioned that.

Andrei

Wed, 02 Dec 2009 16:00:50 -0800, Andrei Alexandrescu wrote:

> retard wrote:
>> 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.
> 
> Static dimensional analysis doesn't improve performance, and I recall he mentioned that.

Why not? I agree it does also static checking of type compatibility, but when done at runtime, computing the associated runtime type tag and comparing them also requires cpu cycles. If the analysis is done at compile time, the computational problem degenerates to operations on scalars and types can be erased on runtime if they are not used for anything else.

retard wrote:
> Wed, 02 Dec 2009 16:00:50 -0800, Andrei Alexandrescu wrote:
> 
>> retard wrote:
>>> 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.
>> Static dimensional analysis doesn't improve performance, and I recall he
>> mentioned that.
> 
> Why not? I agree it does also static checking of type compatibility, but when done at runtime, computing the associated runtime type tag and comparing them also requires cpu cycles. If the analysis is done at compile time, the computational problem degenerates to operations on scalars and types can be erased on runtime if they are not used for anything else.

Doing it at runtime... see Don's VW metaphor. The whole point is to make it impossible to write incorrect programs, not to detect those that are incorrect. There's a huge difference.

Andrei