in reply to list reversal closure

It's an interesting idea. But one that easily can be skewed towards any particular language's strengths (even unconsciously).

I find this particular example fairly uninspiring, as I'm not sure when I would ever use such a thing. It feels like a completely arbitrary use of a closure to make it hard for languages that don't have such a thing. So, in short, I think it's too arbitrary. E.g. it could just as easily be a list object that overloads stringification to reverse the list. So to me, that makes the "list reversal closure" seems like an example with some unconscious bias.

A better "test" is probably one that considers how a language performs (loosely speaking) on average across similar tasks each presented by advocates of a different language. The idea isn't to see how well one language performs on things it does well, but to see how well it performs on things that other languages do well.

Even that is likely to be highly controversial and unsatisfying. But to the OP's point, I don't think any single test will reveal much of anything.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re^2: list reversal closure
by apotheon (Deacon) on Aug 21, 2006 at 11:22 UTC

    The closure requirement isn't really all that awful, if you think about it: it translates directly into two other requirements that seem quite reasonable, for most purposes, to impose. The first is lexical scoping (or equivalently protected scope) and the second is the ability to return a function from a function and pass it around in a variable, while still being able to execute it.

    I'm generally a little unfairly biased against a language that doesn't support closures, perhaps, but I'm not so sure that a bias against languages that don't support everything needed to construct closures is at all unfair (despite the fineness of that distinction). While I'm keen on closures, that doesn't mean that closures don't provide a simple, clean, succinct, and fair means of demonstrating other positive characteristics of programming languages. In other words, the bias is conscious, but (as far as I can tell) largely irrelevant in this case.

    As for the notion of comparing on a series of tasks, that's sorta what's happening that prompted me to come up with this in the first place. There's sort of an ongoing series of task-examples being dreamed up by me and a small number of others who make use of various languages for the enjoyable exercise of comparing implementations across languages. In fact, it was a Pythonista that suggested doing something involving list processing in the first place.

    Single tests can demonstrate good points, though. You simply have to ensure that everyone involved in the comparisons is honest in the analysis, including an analysis of the shortcomings of the specific test task in demonstrating much. For instance, a succinctness test on "hello world" programs certainly won't declare a "winner" between Perl and Python, but it does demonstrate to a useful degree the significant and unwieldy scaffolding overhead required by Visual Basic for the simplest of tasks.

    print substr("Just another Perl hacker", 0, -2);
    		 - apotheon
    CopyWrite Chad Perrin

[reply]
[reply]

In Section Meditations