In message <[EMAIL PROTECTED]>, Rob Dixon <[EMAIL PROTECTED]> writes: >Mr. Shawn H. Corey wrote: >> "Real Perl Programmers prefer things to be visually distinct." >> Larry Wall >> >> I wasn't the first to have the idea. > >I can't find anywhere where that is quoted in context.
Not quite that, but Larry has written similar things on numerous occasions. (Note: I'm not taking either side.) http://www.linuxjournal.com/article/2070 One of the ideas I keep stressing in the design of Perl is that things that are different should look different. The reason many people hate programming in Lisp is because every thing looks the same. I've said it before, and I'll say it again: Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in. (Other than that, it's quite a nice language.) ... That's why scalars start with $, arrays with @, and hashes with %. That's why filetest operators look like -M, while numeric tests look like ==, and string tests look like eq. Perl is very much a What-You- See-Is-What-It-Does language. You can talk about readability all you like, but readability depends first and foremost on recognizability. http://www.wall.org/~larry/pm.html Well...Perl does one thing, and does it well. What it does well is to integrate all its features into one language. More importantly, it does this without making them all look like each other. Ducts shouldn't look like girders, and girders shouldn't look like ducts. However, he also notes there are conflicting requirements. http://dev.perl.org/perl6/doc/design/apo/A03.html But while your computer really likes it when everything looks the same, most people don't think like computers. People prefer different things to look different. They also prefer to have shortcuts for common tasks. ... # Sometimes operators should respond to their context. Perl has many operators that do different but related things in scalar versus list context. So you want different things to be visually distinct. Shortcuts might be said to cloud this, but they can also be a good thing (e.g. Perl's liberal use of default values) - and as Larry also mentions in the Apocalypse, commonly performed operations should be short (inspired by Huffman coding). Default values can contribute to that. But you might also think about subroutine vs non-subroutine as being a different "context" and, although that was about operators, you might think of shift as responding differently in each context. Following the principle of DWIM, you might also think of an array-less shift as being "give me a parameter", at which point they are the same thing - both girders, ducts, water pipes, sewage pipes, or one of Larry's other metaphors in the second article. You might then regard the fact that parameters are held in two different locations as somebody else's problem. Largely, you both have a point and, to some extent, it probably depends on taste and gut instinct. To close: Anyway. Isn't history fascinating? Especially postmodern history? As Heidi would say: 'Tsall good. Except when it sucks. -- James Coupe -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
