http://www.perlmonks.org?node_id=222738

I thought of that too, but it does have some problems. Eval-string is very cheap in that accounting. print 'a'.'b'; is cheaper then print 'a','b'; (the former constant-folds to print 'ab';).

This is why print "a"."b"; is faster and more efficient than print "a","b";. I think it is *good* to have the former be less points.

When not using constants, it's a different story: print "a".\$_; is 9 concise-lines while print "a",\$_; is 8.

I think eval-string should be avoided anyhow, in a golf contest like this one.

```- Yes, I reinvent wheels.

- Spam: Visit eurotraQ.
```

Replies are listed 'Best First'.
Re: Re: Re: Re: Beyond Golf - reading between the tokens
by Anonymous Monk on Dec 28, 2002 at 23:37 UTC
Try playing your modified golf game with a program to produce the 100 bottles of beer song. The winner is obvious, but I maintain is more complex from a maintainance perspective than a far shorter dynamic solution.

All forms of golf raise the question of trying to define what kind of shortness is appropriate. There is no good answer. And the more natural the answer that you try to come up with, the trickier the boundary cases become. There is no good solution.

PS Stupid trick for regular golf. If side-effects are unspecified, then eval is often more shortly written as s//print"Some code here"/e

Yah. You've got a point. The best way to judge such a thing may be to have an "impartial" judge decide which one they like best.

Personaly, I like the idea of the various scored programing contests. Your bottles-of-beer question is simply a bad question. A better one would have read: write a function, bottles_of_beer, which takes a single parameter, the number of bottles to start with. It should return a string of the form "\$n bottles of beer on the wall, \$n bottles of beer. You take one down, you pass it around...\n\$n-1 bottles of beer on the wall"..., where \$n is the number passed in. It should end with the line "ENOBEER", after you've passed around the last beer.

"Winners" will be programs that do it in the fewest number of characters (as mesured by ls -l, on a one-character-newline system), the fewest opcodes (as mesured by B::Concise), and the shortest running time (on my system).

(In fact, can anybody find issue with this form of rules? I might write up a Tutorial on golf contests... even though I don't purticularly like writing it. (I might like doing perl racing, or minimal-opcode-programing (NEED BETTER NAME!), though.) Hm. Two more scoring methods just crossed my mind: B::Size (more then number of opcodes, since it also includes info on constants), and the size of the output of B::Assemble (more then B::Size, less then B::Size? Different in any way the B::Size? I don't know)

Anyway, I find the topic very intersting, and am probably going to ponder mroe on it. But now, I'm going to bed.

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

I too was at a loss for good names for the minimal-opcode version of golf.. Anyway, I'd be interested in getting this tutorial to see the light of day, considering I got this particular ball rolling. :) If you don't feel like writing it all yourself, I'd be glad to lend a hand or two.

Makeshifts last the longest.