http://qs1969.pair.com?node_id=81870

I found this in a 1972 essay and thought you folks would be interested.
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is caled "the one-liners." It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question, "Can you code this in less symbols?"---as if this were of any conceptual relevance!---or he just says, "Guess what it does!" From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz., to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language.

--
Mark Dominus
Perl Paraphernalia

Replies are listed 'Best First'.
Re: On Golf
by clemburg (Curate) on May 21, 2001 at 15:13 UTC

    From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz., to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language.

    This is wrong. What we must conclude is that there seems to be some incentive for programmers to write one-liners, and that the language under discussion offers opportunities to write those.

    Now, to damn the programming language for the sins of its users is at least questionable. Whatever gives you freedom obviously gives you the opportunity to abuse this freedom.

    And besides that, I think the author is mistaking a fun-and-games style sports event for real work here. He should also oppose the makers of sports equipment, on the grounds that they offer an open invitation to waste your time instead of doing real work.

    "Liber ludens manere" ("Stay a playing child") was my motto back in school, and I still think it is a fitting one for a programmer. To conclude with a quote from a similarly prestigious person like Dijkstra:

    I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customer got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more. -- Alan Perlis, quoted from SICP, 2nd Ed.

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

Re (tilly) 1: On Golf
by tilly (Archbishop) on May 21, 2001 at 18:49 UTC
    I notice that you didn't take a position on the quote. I also note that the same has been said about obfuscated programs, a task you have been known to indulge in.

    I also notice that there is a long-standing tradition in programming of celebrating crazy projects that no sane person would emulate.

    Finally I submit that Perl is not intended to be a "good language". It wilfully ignores many widely accepted rules of good language design. Its strengths lie in other areas, such as a strong community. Indeed my current suspicion is that in true "Worse is Better" fashion, some of the design decisions that superficially look worse, help it become better in the long run.

    And certainly an open invitation to play would be one of those design decisions...

Re: On Golf
by no_slogan (Deacon) on May 21, 2001 at 03:24 UTC
    "Programming is difficult; therefore, programming must be boring. APL is not boring, so APL is obviously not a suitable programming language." I am humbled by such a rebuke and will flagellate myself, and pray at the altar of Ada for forgiveness.

    We all know better than to golf something that needs to work. The fact that you can golf in perl just means that perl is sufficiently expressive to be interesting.

Re: On Golf
by koolade (Pilgrim) on May 21, 2001 at 08:21 UTC

    Without reading the paragraph in context it's hard to say, but does it seem like the author condemns golfing entirely? It seems like the danger the author points to is that the language would be designed to invite those kinds of practices, i.e. as opposed to writing code that's readable. Perl's TMTOWTDI gives room for golfing, but it also allows for readable and easily maintainable code as well. It's important though, that people know the difference.

    I think the danger w/ golfing is when one takes it more seriously than just a game--if someone applied golfing practices to production code, or felt in any way that it was the "right" way to do something. Frankly, I'm impressed by a lot of the solutions people on PM come up with, but if I ever saw someone do that in a professional context, I would not be pleased at all.

Re: On Golf
by premchai21 (Curate) on May 21, 2001 at 03:21 UTC
    Ow! Ow! Ow!

    I'm sorry, but I really don't see anything wrong with clever tricks, as long as they work well. "Can you code this in less symbols?" would be perfectly OK as a way to enhance mastery of other parts of the language, except that it should be "fewer symbols". I'm glad the author apologized. Had he not, I would not have.

    So there.

Re: On Golf
by jmcnamara (Monsignor) on May 21, 2001 at 20:50 UTC

    From this observation we must conclude that this language as a tool is an open invitation for clever tricks

    What programming language could stop people from using clever tricks? You see this behaviour everywhere: chess puzzles, crosswords, poetry, mathematics.

    It may be a bit fanciful but Abigail has suggested that Knuth would approve of Golf:
    I don't think Knuth would be a big fan of Perl, but he loves a programming trick just like many people here, and he certinly likes to play golf.

    I recently read an article where Knuth describes a game of golf on a 50's machine. The machine read cards, and one could put 8 machine instructions on a card. The goal was to write a program fitting on one card that would read in a number, and reverse it.

    Noone was able to do it, but Knuth once stunned his fellow students. He came in, put a card in the reader, entered the number 123456789, ran the program, and the program outputted 987654321.

    Of course, the program would always output 987654321, regardless of the number on input.

    Later, the machine got an extension. A whopping extra register, with front panel toggles. Which could be used to store an instruction as well. Knuth was delighted that that enabled him to write a single card program that reversed a number.

    John.
    --

Re: On Golf
by Cybercosis (Monk) on May 21, 2001 at 06:05 UTC
    This is actually a quote by Dijkstra (sp? and I forgot his first name), and I had a similar response when I first read it (in a rather wonderful book entitled Classics in Computer Programming (I think...)). Less symbols means less code, so it's optimization, which is of incredible conceptual importance (particularly when generating code rather than writing it. I'm starting to sympathize with the poor guys who had to write the first assemblers in machine code...). Oh well, one can't expect the man to be right all the time.

    ~Cybercosis

      > Less symbols means less code, so it's optimization

      Can't good optimization sometimes increase the number of symbols in your code (assuming you're not working in assembler)?

      You can have verbose code that is highly optimized in that it avoids any expensive processes, and you can have short, compact code that actually translates to expensive machine code.

      On any high level language like Perl, the code is never going to map directly to the same quantity of machine instructions.

      All I'm saying is that anything done in the name of optimization has to be considered from the machines point of view.

      willdooUK
      --------------
        Just to add to this, in C, a for-loop is smaller but less optimized than writing out each statement seperately.

        And using cos() or other trig functions might be smaller but a lookup table is much faster.

        When you're not specifically dealing with instructions, code size doesn't really have any correlation to speed.

        Rich

        I agree completely. However, optimization can mean any of several different things; you can optimize for speed, readability, size, footprint, or whatever. What is more important than the actual direction of optimization is mastering the process of thought involved in optimization.

        ~Cybercosis

        nemo accipere quod non merere

Re: On Golf
by Dominus (Parson) on May 24, 2001 at 03:38 UTC
In defense of Djiksta...
by indigo (Scribe) on May 25, 2001 at 03:55 UTC
    Before everyone rushes out to defend golfing (too late), consider this...

    When I golf, and I am guessing this is pretty typical, I basically slap some line noise together, and see what happens when it runs. I might edit and execute my program hundreds of times, but this is no biggee...I have a syntax highligting editor that catches typos, a shell with command line history, a windowing OS, browser open to hyperlinked man pages, and my own box with cycles to burn. If I get too clever and screw something up, I spend 99% of my time debugging, and almost none wrestling with the environment.

    Now consider the programming environment of 1972. Punch cards, line editors, batched jobs on shared mainframes, byzantine manuals on dead trees...editting, compiling, executing code, and reading docs was a pain in the ass. It could literally take hours to learn your program had a fatal one character typo.

    Given all this, I think I would stay aware from "clever" progamming languages, too. At least for a little while...:)