[ruby-talk:18157] Re: Ruby Golf

Hi --

On Fri, 20 Jul 2001, Stephen White wrote:

> I've been enjoying the games of Golf in here, but there's something I'd
> like to suggest...
>
> Could we play games of golf for the fastest execution, minimum resources,
> or some other solution oriented goal rather than "shortest program"?
>
> When a program is optimised for speed, there is still room for writing
> "beautiful" code. The most heavily optimised programs lose some of that
> readability, but for specific real reasons that are valuable to know.
>
> When programs are written to be as short as possible, good code gets
> thrown away in favour of syntaxic quirks. It's quicker to do $* than
> it is to do ARGV. It's shorter to define a proc than a function. It's
> less space to use globals than to pass parameters.
>
> In the Perl world, "short is good", perhaps because of all of the
> games of Golf that have been played over there. Could we aim for
> "speed/beauty/power is good" in our games of Golf here? :)

This is why in my first "bottles" version I explicitly stated that I
was not trying to espouse a philosophy of programming, just having fun
:-)

One terminological thing: I think that if it's "golf", then it's a
shortest-solution puzzle.  (At least I've never heard other kinds of
optimization referred to as golf.)  Maybe we need different sports for
different criteria of performance :-)

I hope you won't mind my saying that I winced a little at your
characterization of the Perl world.  There really are plenty of Perl
programmers who don't subscribe to the "short is good" philosophy.  In
fact, I think it would be hard to find too many who really felt that,
in a finished, useful program, the "golf" style of shortness really
mattered much at all.  But boy can it hone your skills at trimming
reasonable amounts of dead weight off of real programs!  It's rather
like other kinds of exercise (musical, gymnastic, etc.):  you do more
during the exercise than you'll ever do during the real thing, but it
prepares you.

Personally I learn a lot from different kinds of puzzles and exercises
and challenges, and I think it would be a pity to single out
shortest-solution puzzles for stigmatization.  Of course the overall
goal is for us to become programmers whose programs reflect all the
qualities you've described.  But that doesn't mean that every moment
along the way to that (elusive) goal is going to partake of all of
those qualities.  Shortest-solution code is weird, but I don't think
anyone involved doesn't have their eyes open about that.

I was really glad to see $* for ARGV today, because I learned
something from it.  (I imagine I'd seen it in the pickaxe, but my
knowledge of it was passive at most.)  But in a real program I'd never
choose $* because it's shorter than ARGV.  Still, as much as possible
I want to know what I'm doing -- and know *about* what I'm *not*
doing -- in Ruby.

We've had a number of puzzles and challenges here in the past -- the
anagrams thread, among others -- which were definitely not about
shortness, and which did indeed lead to some extremely interesting
discussions and sometimes even some useful code.  There was sort of a
flurry of that about six months ago, and less recently.  Any ideas?


David

-- 
David Alan Black
home: [e-mail]
work: [e-mail]
Web:  http://pirate.shu.edu/~blackdav