many respected hackers agree that those aspects did and do more bad to Perl's name than good;

some of them, especially the second one I mentioned are far from being exclusive of Perl.

Whatever, in my Insane™ ;) wanderings through "Saint Wikipedia" I just stumbled upon the surrealist movement's game of Exquisite Corpse which, to put it as briefly as possible consists of the literary composition of texts by many persons each of which will only see the last line of what the previous one wrote or be given a basic syntactic structure to start with his or her part. Alternatively, the same term describes the corresponding graphical game in which each individual in turn draws one piece of a bigger figure folding the paper so that only a minimal portion of it will be visible.

Now, I had the Insane™ ;) idea of doing the same in Perl: of course some more care than with a generic natural language should be taken to link one piece of the program to the other. Also: should each "piece" work as of its own? I don't think it necessarily should, or it would be too restrictive wrt the surrealist POV which is the common background under which one would possibly want to play this game.

For the moment I propose that one would either give:

the last statement of his piece, and if there are unclosed curlies, then specify how many of them or

all the variables used thus far, implicitly or explicitly, and how many times, so to allow for "non linear" continuation.

(As far as the second point is concerned, it means that a player may "substitute" the nth occurrence of a variable with... whatever he likes, in the spirit of the game.)

So does somebody want to (try to - it's an experiment, after all!) play with me? From a minimal snippet of code of mine to remember how "to do something" with comments removed - running under strict,warnings and 5.010 - one unclosed curly:

Update: one monk (whose name I will substitute to this anonymous mention if he likes to) sent me a /msg saying:

I personally believe that your starting code is rather unfortunate - it's hard to think of a program that does something useful and does a substitution in the last line without using its result... maybe pick something simpler for a start?

(additional emphasis by me)

I have two considerations to make in reply:

of course is it hard: but if it were not, then it wouldn't be much fun. It's not dissimilar from drawing the face of a man and just showing two little parallel ticks which should mark the border of his neck: to the next person, they may be quite about everything. If one put there e.g. a bowtie, then it would be "obvious" what to draw next, and much less surreal. Also, I claimed that this is an adaptation of a minimal example note I keep, so it should be supposed to be somewhat useful, but that may have not been my intention to start with: I actually decided to show that particular "line" while I had the one in which I used the results and I may have shown that instead. But then you would have "only" had to think of a way to create the results first... again, much less fantasy, much less randomness.

Said all this, I realize that programming is not just the same as drawing on a piece of paper or a natural language: the code must compile too! So given that AFAIK this is the first attempt at such a game, I'm all open to suggestions and modifications as far as rules are concerned as the game itself goes by. I see I have a reply, in fact, but I'm literally falling asleep now. I'll read it better (or at all, which is something I'm not sure I could guarantee in this very moment...) tomorrow morning.

I don't believe programs can handle as much randomness as you're suggesting...

Perhaps an alternative scheme;

Predefined functions Munge() and MungeConsistently() will be available.

Munge calls MungeConsistently, but passes in the count of how many calls to Munge have already been made, so it is essentially random but still reproducible.

MungeConsistently takes a number as its first parameter, which will be used to pick the sub to call.

Everybody is given a random number from 0..1, indicating their position in the program. (so that early code can do more input, and late code can do more output)

PASS 1: Everybody then submits a small block of code that does something "useful", PLUS a small subroutine to be included in the Munges

PASS 2: Each person is given the task of gluing together two adjacent pieces of code, NOT including their own. (One player is chosen to glue the command line to the first block by choosing the input parameters, so there are N glues for N players)

The second pass to glue things together should change the result from a twitching mass of random code to something that at least runs to completion. (I hope)

I don't believe programs can handle as much randomness as you're suggesting... [...] The second pass to glue things together should change the result from a twitching mass of random code to something that at least runs to completion.

I personally believe that... whoa! what you describe is an entirely different game altogether: which is not to say it wouldn't be interesting or fun. But I explained the goals of the game as I see them in my reply to graff's comment, which expressed similar concerns as yours: to be fair I'm specifically interested and I think that people who would like to play an autenthically "Exquisite Corpse" version of the game should be specifically interested in the "twitching mass of random code" getting out of it! (Thank you for contributing this very illuminating expression!)

Since both you and graff, reasonably, point at subs, I recognize that as an alternative to the "last statement rule" a player may give a sub call of a sub he didn't include in his portion of the script, for the next one to write one. But I wonder if that couldn't be too restrictive of his freedom of could turn the game, if all players choose to handle "continuations" that way into a boring series of nested sub calls... Perhaps a restriction should be imposed to the effect that this kind of continuation can not be given for more than one turn. Thus a player writing the "requested" sub may or may not actually end it or leave it open, and write further code beyond it or not: scary! ;)

I personally believe I should thank you for taking part to the experiment: if nobody else joins say within tomorrow morning, I'll propose the next step myself, if you like, as an update to this very post. Then I'd go as far as corpse-6.pl and see which kind of "twitching mass of random code" got out of it!

Update: [Fri Nov 21 15:56:53 2008] here it is, and sorry for the minimality, but aqs you can see I've been procrastinating so much that I was beginning to think I wouldn't have done it any more if not so. Still, I think something moderately interesting may get out of it. I hope that the names of the variables are either illuminating or... pleasantly misleading enough! ;)

Dude, I fear that you must have way too much free time on your hands...

That said, I think the exercise as a whole might stand a better chance of successful execution (and might even be more amusing) if the participation were more "modular".

Imagine that the goal of the exercise is to build a filter, comprising some finite (pre-established) number of steps, with each step implemented as a subroutine call that takes, say, one or two variable parameters (plus, if you like, one or more literal args), and returns something that can be used as input to a subsequent subroutine.

The first player gets to provide the data input operation, which could include some comment about the expected nature of the input (e.g. "list of English words, one per line"), or could be "self evident" (e.g. @input = <*.txt>; ). The first player could also provide the first filtering step (subroutine call).

Each successive player sees only the previous two lines (sub calls whose return values are assigned to variables), and must add the next filtering step, using one or both of the two variables set by the two visible steps from previous players (along with literal args, if desired).

Names of subs and variables should be "suggestive" (used to "good advantage" in the game, according to each player's understanding of "good"). At the very least, the variable name being assigned the return value from a sub should indicate the nature of the value (array_ref, hash_ref, or whatever).

Code for each subroutine must be provided by the player who adds that sub call to the sequence, and would be known only to the person who adds the sub call.

(A player could re-invoke one of the two subs visible to him/her, providing different input args, but this would usually be considered bad form (i.e. lame), and might run the risk of causing "undefined behavior" -- or a crash -- since that sub's internals are known only to the previous player who first put it in.)

I think games of this sort typically involve two or more rotations, and as many distinct compositions as there are players -- e.g. if there are 6 players, the game begins with each person supplying an input line and an initial sub of their own invention. Each script then rotates around the group, and eventually comes back to the player who started it. If the players are reasonably sober, they might be aware of the point where they are adding to a script that they started, though they might not remember exactly how they started it, and in any case, they don't know what happened to the data during four intervening steps (they only see the lines added by the previous two players).

That said, I think I would respectfully decline the opportunity to play. Just about all my "idle amusement" time (meager amount that it is) is spent on sudokus, crosswords, and SoPW. (Now that I think of it, timing issues might turn out to be a problem in this game...)

Update: Naturally, in the process of adding a given statement to the filter sequence, a player is not constrained to merely assigning the return value of a sub to a variable; any single-line flow control mechanism is fair game, along with using perl built-ins, logical operators/conjunctions, etc, but again, if the player doesn't actually include a sub call of his own (to hide some code from the next players), this could be viewed as a cop-out.

Now, back to the actual game: it was in fact just an idea. The single word that's been stressed more in replies is "useful" which I think to be an error and a wrong POV to start with. Golf and Obfu are focused on writing programs that do something useful for some definition of "useful" and the interesting part is to see how they accomplish that. Here, the relationship is quite the opposite: the game, which is admittedly much less interesting, is about doing something, in surreal way: but have you ever heard about something surreal being useful? Except for the intellectual pleasure of seeing it existence by itself? Indeed a large part of the latter is about seeing if the game is feasible at all.

To make a comparison, if you stick with the "standard" graphical version of Exquisite Corpse, players could arrange things so that necessarily the end result is a human figure: just with pieces drawn by different individuals with different styles. But in the spirit of the game, it "works well" when what you get is... well, say a human head sticking out of a boot with flames surrounding it. Or something similarly weird. I would say that as with bizarro, although the latter is a much more recent genre, the main interest should be weirdness itself. As far as I'm concerned, I think there should not be any "goal of the exercise" but doing the exercise per se.

Of course, a big issue, which is also a cause of concern to the other monk who replied to me is to make the overall script work at all both in the sense that it must compile and not fail at runtime: (but the latter is much a minor problem, considering that we know we couldn't do anything for it even if we were writing "seriously...") after all there's not stated rule thus far prohibiting me from having a while (1) { ... } loop in the hidden part of my portion of the program. Your considerations are certainly useful in this sense, but I still regard them as far too restrictive wrt the spirit of the game as I interpret it, although just not as much as that other poster's. Thank you for the time you contributed thinkering about this crazy idea of mine!

Just wanted to comment on the "many respected hackers" thinking that golf and obfuscation has hurt perl. Whenever I see this argument, I find it is used as a copout. Every language has obfuscation games. No programmer worth paying attention to seriously believes a golf game is how you write production code. You can write garbled code in any language; perl just happens to provide a variety of tricks to do it. Blazar, I know you know that, confused why you cited it.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other