Re: Why no is ro? (Re: Subroutine parameter with trait and default.)
David Green wrote: I bet we actually don't disagree much; I'm not really against ro -- I'm just not against readonly because of its length. If I were writing casually, I'd use rw and ro; formally, I'd use read only and read/write (or even readable and writable). At an in-between level, which is where I believe we should be aiming, I think I'd put rw and read-only. I'm not entirely sure why. Maybe psychologically, ro looks like it could be a word, whereas the unpronounceable rw has to be an abbreviation? Or maybe it's just because I see rw every day in ls output, but ro not so much. At any rate, if I wanted to argue in favour of ro, I think symmetry (which you already mentioned) is the strongest argument. Yes indeed, symmetry. It's powerful. Once you see rw you're going to assume the other is ro. Same with readonly and readwrite. And vice-versa and con-versa and any other versas you can think of. rw/readonly is the worst choice. It has that double wammy of bad interfaces: rote learning and counter-intuitiveness. Not only do you have to memorize that read-only is readonly and read/write is ro but you have to actively fight your intuition that they should be symmetrical. This generates mistakes. Constant mistakes. rw/ro makes similar things similar. So does readwrite/readonly. Pick one of them. Asymmetry will cause far more problems than too little or too much verbosity. -- ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: Why no is ro? (Re: Subroutine parameter with trait and default.)
On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote: David Green wrote: Happily, brevity often aids clarity. The rest of the time, it should be up to one's editor; any editor worth its salt ought to easily auto-complete ro into readonly. Eeep! The your IDE should write your verbose code for you argument! For that one, I brine and roast an adorable hamster. Fair enough. As long as you remember to share with the rest of us!! That's just another way of saying that your language is too verbose for a human to write it without hanging themselves. See also Java. But the problem with Java isn't just that it's too verbose to write; it's that it's too verbose to read, too. Why shouldn't your editor help with verbosity? The amount of typing shouldn't be a main concern in language design, because your editor can mostly compensate for that; there are other, better reasons to decide how verbose something should be. Anyhow, I see where you're going, and I understand the desire for no abbvs. But man, ro is pretty damn easy to remember. [1] This is even sillier when you hold it up against all the magic symbols we're supposed to remember. [EMAIL PROTECTED], :namevalue, |$arg, $arg!, $arg?, : $arg. As a bear of limited recall, I sometimes feel a bit overwhelmed by all the stuff there is to remember. I'm certainly not against all abbreviations. I have a deeply ingrained instinct to name my variables x, y, and z, and to name files... x, y, and z. My shell profile is full of one-letter aliases (I don't have time to waste typing 2-char command names!). However experience has taught me the value of more robust names for anything but one-liners. I bet we actually don't disagree much; I'm not really against ro -- I'm just not against readonly because of its length. If I were writing casually, I'd use rw and ro; formally, I'd use read only and read/write (or even readable and writable). At an in-between level, which is where I believe we should be aiming, I think I'd put rw and read-only. I'm not entirely sure why. Maybe psychologically, ro looks like it could be a word, whereas the unpronounceable rw has to be an abbreviation? Or maybe it's just because I see rw every day in ls output, but ro not so much. At any rate, if I wanted to argue in favour of ro, I think symmetry (which you already mentioned) is the strongest argument. You're only a beginner once, and if everything is done right for a short time. The rest of your career, you're experienced. Ooh, now that I completely agree with! Software that thinks user- friendly means dumbed-down drives me nuts. -David
Re: Why no is ro? (Re: Subroutine parameter with trait and default.)
On 2008 Sep 24, at 17:45, David Green wrote: On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote: David Green wrote: Happily, brevity often aids clarity. The rest of the time, it should be up to one's editor; any editor worth its salt ought to easily auto-complete ro into readonly. Eeep! The your IDE should write your verbose code for you argument! For that one, I brine and roast an adorable hamster. Fair enough. As long as you remember to share with the rest of us!! I would argue that if you need your editor to expand verbose language constructs to make the language usable or to express common idioms, then the language has a design deficiency. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Why no is ro? (Re: Subroutine parameter with trait and default.)
John M. Dlugosz wrote: I'm not opposed to having it be ro, but wonder why he didn't call it that in the first place, so there must be a reason. Nobody's perfect? My other thought is that since parameters are read-only by default it's not thought you'd have to write it much so clarity wins out over brevity, the flip side of Huffamn encoding. But that doesn't work out so good for normal variable declarations. The verbosity (which a hyphen would only make worse) discourages const-ing, as they say in C. It should be possible to alias it in your own scope easily. Every time someone replies to a Perl 6 language design nit with but you can change the grammar *I* kill a kitten. *meowmmmf* -- 31. Not allowed to let sock puppets take responsibility for any of my actions. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: Why no is ro? (Re: Subroutine parameter with trait and default.)
On 2008-Sep-23, at 2:32 pm, Michael G Schwern wrote: My other thought is that since parameters are read-only by default it's not thought you'd have to write it much so clarity wins out over brevity, the flip side of Huffamn encoding. But that doesn't work out so good for normal variable declarations. I'd call it straight Huffman encoding, because clarity is what we should be optimising for. (You read code more than you write it... unless you never make any mistakes!) Happily, brevity often aids clarity. The rest of the time, it should be up to one's editor; any editor worth its salt ought to easily auto-complete ro into readonly. -David
Re: Why no is ro? (Re: Subroutine parameter with trait and default.)
David Green wrote: On 2008-Sep-23, at 2:32 pm, Michael G Schwern wrote: My other thought is that since parameters are read-only by default it's not thought you'd have to write it much so clarity wins out over brevity, the flip side of Huffamn encoding. But that doesn't work out so good for normal variable declarations. I'd call it straight Huffman encoding, because clarity is what we should be optimising for. (You read code more than you write it... unless you never make any mistakes!) Happily, brevity often aids clarity. The rest of the time, it should be up to one's editor; any editor worth its salt ought to easily auto-complete ro into readonly. Eeep! The your IDE should write your verbose code for you argument! For that one, I brine and roast an adorable hamster. That's just another way of saying that your language is too verbose for a human to write it without hanging themselves. See also Java. Anyhow, I see where you're going, and I understand the desire for no abbvs. But man, ro is pretty damn easy to remember. [1] This is even sillier when you hold it up against all the magic symbols we're supposed to remember. [EMAIL PROTECTED], :namevalue, |$arg, $arg!, $arg?, :$arg. If we expect the user to remember what all that means, I think they can figure out $thing is ro. It would be incoherent to take a corner of the language design and suddenly pretend otherwise. The mark of a great interface is not that you know what everything is the first time you encounter it, but when you remember what it is the second time. The first time what's important is the user knows where to find instructions and how to play with the device. It should have a strong analogy and mesh clearly with the surrounding devices ro and rw have a strong analogy with the common read-only and read-write terms and they mesh with each other. Once this is known to the user, the second time it will be obvious. You're only a beginner once, and if everything is done right for a short time. The rest of your career, you're experienced. Instead of dumbing the language down for beginners, the trick is to turn beginners into experienced programmers as quickly and painlessly as possible. Now I've totally digressed./rant -- s7ank: i want to be one of those guys that types s/jjd//.^$ueu*///djsls/sm. and it's a perl script that turns dog crap into gold.
Re: Why no is ro? (Re: Subroutine parameter with trait and default.)
Michael G Schwern schwern-at-pobox.com |Perl 6| wrote: It should be possible to alias it in your own scope easily. Every time someone replies to a Perl 6 language design nit with but you can change the grammar *I* kill a kitten. *meowmmmf* That would not be a change in the grammar. Merely deciding for yourself which names should be short based on your own usage. Since readonly is a class name, the equivalent of a typedef would be used. I think that should be my ::ro ::= readonly; but I have some technical points that still need to be addressed/worked out. --John
Re: Why no is ro? (Re: Subroutine parameter with trait and default.)
Michael G Schwern schwern-at-pobox.com |Perl 6| wrote: John M. Dlugosz wrote: I'm not opposed to having it be ro, but wonder why he didn't call it that in the first place, so there must be a reason. Nobody's perfect? My other thought is that since parameters are read-only by default it's not thought you'd have to write it much so clarity wins out over brevity, the flip side of Huffamn encoding. But that doesn't work out so good for normal variable declarations. The verbosity (which a hyphen would only make worse) discourages const-ing, as they say in C. Perhaps he was thinking that 'constant' would be used there. But I agree, it's not the same thing. In C++ I often use const for things that are in 'auto' scope and initialized in the normal flow sequence. Anyway, was 'ro' rejected for some good reason, $Larry, or was it simply considerate as not to waste a short word on a rare use since that's the default (for parameters)? I agree that knowing 'rw', and that being common, if I wanted the other one and didn't use it every day, I would =guess= that it should be called 'ro' to match. --John
