Leandro Lucarella wrote:
> Bubble sort is perfeclty acceptable for, say, a 100 elements array.

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

The thing about writing code that will be used by others is that they are not going to restrict themselves to small data sets.

For example, bubble sort. Putting that in a library is a disaster. You can't just write in the documentation that it is usable only for less than 100 elements.

One really does have to worry about big O performance, unless it is a throwaway program.

BCS wrote:
> Hello dsimcha,
> 
>> == Quote from BCS (none@anon.com)'s article
>>
>>> I don't have a link or anything but I remember hearing about a study
>>> MS did
>>> about finding bugs and what they found is that every reasonably
>>> effective
>>> tool they looked at found the same amount of bugs (ok, within
>>> shouting distance,
>>> close enough that none of them could be said to be pointless) but
>>> different
>>> bugs. The way to find the most bugs is to attack it from many angle.
>>> If I
>>> can have a language that can totally prevent one class of bugs in
>>> vast swaths
>>> of code, that's a good thing, even if it does jack for another class
>>> of bugs.
>>
>> Right, but the point I was making is that you hit diminishing returns
>> on static verification very quickly.  If you have even very basic
>> static verification, it will be enough to tilt the vast majority of
>> your bugs towards high-level logic/algorithm bugs.
>>
> 
> OTOH, if it's done well (doesn't get in my way) and's built into the language, any static verification is free from the end users standpoint. Heck, even it it gets in your way but only for strange cases where your hacking around, it's still useful because it tells you where the high risk code is.

There's a really interesting synergy between pure and unit tests. It's much easier to test a function properly if it's pure -- you know that there are no globals anywhere which you have to worry about.

On Wed, Dec 02, 2009 at 11:50:23AM +0000, retard wrote:
> The case I commented on was about fetching values from a db IIRC.

What happened to me was the value got returned as the incorrect type, stored, and used later where it threw the exception..

Conceptual code here:

===

def getPermission(userid)
begin
    return $db.query("select whatever from table where id = ?", userid);
end

def getPermissionNeeded(operation)
begin
    return $db.query("select whatever from table where id = ?", operation.id);
end

===

The most common way the code used it was like this:

if(getPermission(user) == getPermissionNeeded(op)
 || user == User.ROOT)
    op.run; // works - the db functions return equal strings in both cases


The bug was here:

if(getPermission(user) >= getPermissionNeeded(op)) // this throws at runtime
    op.run;  // never reached, users complain


If the functions were defined like they would be in D:

int getPermission(int user) {
	return db.query(...);
}

The real source of the bug - that the database query didn't give me the expected type - would have been located in the fraction of a second it takes for the compiler to run its most trivial checks.

That really is similar to putting in an out contract:
	assert(getPermission is int);
	or probably better:
	assert(getPermission >= 0);

But it is a) required, so I'm not allowed to get lazy about it and b) just plain easier, so laziness won't affect it anyway.


(Or hell, if it was PHP, the weak typing would have converted both to integer
 at that line and it would work. But weak typing comes with its own slippery
 bugs.)

Thanks to the dynamic duck typing, the code worked most the time, but failed miserably where I deviated ever so slightly.


The fix in the ruby was easy enough, once the bug was found:
	return db.query(...).to_i

The same thing dmd would have forced me to do to make it compile, but the important difference is dmd would have found the bug for me, not an end user.


It just goes to prove that you can't just forget about types in your code just because it is dynamic.

-- 
Adam D. Ruppe
http://arsdnet.net

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? 

Hello Bill,

> On Wed, Dec 2, 2009 at 3:26 PM, BCS <none@anon.com> wrote:
> 
>> Hello Sergey,
>> 
>> 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
> 

Yes, some of the performance issue (that I didn't bring up) can be addressed. But what about the points I did bring up? Like added conceptual complexity and another degree of separation between what you want and what you get?

== Quote from BCS (none@anon.com)'s article
> 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...

Oh come on.  I'm as much a fan of D metaprogramming as anyone, but even I admit that there are certain things that static languages just suck at.  One day I got really addicted to std.algorithm and decided I wanted similar functionality for text filters from a command line, so I wrote map, filter and count scripts that take predicates specified at the command line.

filter.py:

import sys

pred = eval('lambda line: ' + sys.argv[2])
for line in open(sys.argv[1]):
    if pred(line) :
        print line.strip()

Usage:
filter.py foo.txt "float( line.split()[1]) < 5.0"


Metaprogramming isn't very rigorously defined, but this has to qualify.  Try writing something similar in D.

dsimcha wrote:
> == Quote from BCS (none@anon.com)'s article
>> 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...
> 
> Oh come on.  I'm as much a fan of D metaprogramming as anyone, but even I admit
> that there are certain things that static languages just suck at.  One day I got
> really addicted to std.algorithm and decided I wanted similar functionality for
> text filters from a command line, so I wrote map, filter and count scripts that
> take predicates specified at the command line.
> 
> filter.py:
> 
> import sys
> 
> pred = eval('lambda line: ' + sys.argv[2])
> for line in open(sys.argv[1]):
>     if pred(line) :
>         print line.strip()
> 
> Usage:
> filter.py foo.txt "float( line.split()[1]) < 5.0"
> 
> 
> Metaprogramming isn't very rigorously defined, but this has to qualify.  Try
> writing something similar in D.

eval rocks.

Andrei

Hello dsimcha,

> == Quote from BCS (none@anon.com)'s article
> 
>> 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...
> Oh come on.  I'm as much a fan of D metaprogramming as anyone, but
> even I admit that there are certain things that static languages just
> suck at.  One day I got really addicted to std.algorithm and decided I
> wanted similar functionality for text filters from a command line, so
> I wrote map, filter and count scripts that take predicates specified
> at the command line.
> 
> filter.py:
> 
> import sys
> 
> pred = eval('lambda line: ' + sys.argv[2])
> for line in open(sys.argv[1]):
> if pred(line) :
> print line.strip()
> Usage:
> filter.py foo.txt "float( line.split()[1]) < 5.0"
> Metaprogramming isn't very rigorously defined, but this has to
> qualify.  Try writing something similar in D.
> 

Yup, eval is the one thing that dynamic *really* has over static. 

Thu, 03 Dec 2009 21:35:14 +0000, BCS wrote:

> Hello dsimcha,
> 
>> == Quote from BCS (none@anon.com)'s article
>> 
>>> 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...
>> Oh come on.  I'm as much a fan of D metaprogramming as anyone, but even I admit that there are certain things that static languages just suck at.  One day I got really addicted to std.algorithm and decided I wanted similar functionality for text filters from a command line, so I wrote map, filter and count scripts that take predicates specified at the command line.
>> 
>> filter.py:
>> 
>> import sys
>> 
>> pred = eval('lambda line: ' + sys.argv[2]) for line in
>> open(sys.argv[1]):
>> if pred(line) :
>> print line.strip()
>> Usage:
>> filter.py foo.txt "float( line.split()[1]) < 5.0" Metaprogramming isn't
>> very rigorously defined, but this has to qualify.  Try writing
>> something similar in D.
>> 
>> 
> Yup, eval is the one thing that dynamic *really* has over static.

You can even send the runtime generated string via network to some other process that runs on a completely different cpu architecture and still compute the result. You can do this with D too, but you need to write the interpreter or JIT yourself. Dynamic languages provide this as a built-in feature. Guess why D or C++ isn't used much in client side web site code :)