On Wed, Sep 14, 2011 at 8:57 PM, Uri Guttman <u...@stemsystems.com> wrote: > it was topical as your (self admitted) blowup happened here. and it > caused a small ruckus until you calmed down.
I'd say you're both out to lunch on this. I don't even recall this subject so if I even read the affected threads then I obviously didn't think it was worth acknowledging or remembering. Sometimes people put their foot in their mouth (or on their keyboard, as the case may be). It sounds like a private matter so I see little reason to bring it up now (especially repeatedly, if my memory is correct that it's not the first thread that I've seen it re-surface on). and if it persists then all you can really do is ignore that person's posts. > my good engrish is fine very well! Personally I agree that it's very sloppy to write without capitals. It's lazy and annoying to read. Capitals are a part of the English language syntax. I don't claim to write perfect English, but I do try. Something as simple as capitalizing the first letter of a sentence is primary! You learn it in like the first or second grade. It's not like the shift key is overly difficult for you to reach for either. It's something a Perl programmer obviously must cope with unless they've somehow found a special Perl-oriented keyboard or special OS configuration that makes $ and @ and & (and all of the other shifted characters common in Perl) possible to type with a single key... Somebody so pedantic about code should certainly apply himself more in typing human language for public consumption, IMHO. > it isn't a crude filter. it is a solid rule of thumb. a useful > guideline. where did i say once that all single letter vars are out? i > said there are exceptions but few and very localized. my bigger point > which you are ignoring is that by far the larger number of vars need > proper names so using single letter names is an exception. the point is > to notice that single letter names are not useful in general. in > specific cases they could be. you haven't addressed the scope of the > number of names out there. Rob did a very good job of describing this. The amount of detail required for a variable name is proportional to the scope that the variable is visible to. A two line subroutine usually does not require a 10 or 20 character lexical variable. The variable's purpose is usually obvious. It serves no practical purpose and only serves to waste limited human memory and processing power to use a descriptive name. With self-describing code it's often obvious what the variable represents. At least in the code that I write. Adding detail to that is just redundant and verbose. There's a reason a --verbose option is the norm versus a --brief option. :) We normally don't need or want extra information. We can get by with the bare minimum most of the time, especially when we're already familiar with what we're dealing with. We'll let you know if we need more detail, thanks. :) If we do need more detail then we only need it the once. We don't need you to bring it up every time we come across something. Or if we do then you've already Done Something Wrong(tm). As elite as Uri may or may not be within the Perl community[1], you can search online for references of Linus Torvalds[2] suggesting very terse variable names whenever a more descriptive name isn't necessary. Whether or not you subscribe to elitism, I think most can agree that Mr. Torvalds is probably universally considered more elite than Uri. So I guess that's a trump. I don't stalk Linus so unfortunately I'm unaware if he has since changed his mind, but if he had I think it would only serve to demonstrate that such a topic is very subjective and people do indeed change their minds on the subject over time, sometimes even going back and forth. There is no definite right or wrong answer. It's not black and white. I'm perfectly open to discussing such a topic and actually find it rewarding to do so. It's both fun and often educational to learn of other people's experiences and possibly expand your own horizons with regards to a subject, whether subjective or not. What completely ruins the discussion though is when somebody joins in, insisting to have The One True Answer(tm), without being able to provide an unquestionable proof for it, and insisting that they're right and you're wrong. You might get away with this if the discussion is taking place on your own personal mailing list or discussion board, or for a project thereof, but if it's just a public discussion and you're not universally considered "god" by the community then I think it's only fair to add a little bit of humility to your posts and try to remain friendly and open to discussion.[3] It may well be true that in your own personal experience single-character variable names are difficult to understand, but then in my experience it may be exactly the opposite. So then which one is universally right? Perhaps neither. So that it's clear I have no interest in having any kind of beef with Uri, or anyone else on this list for that matter. I'm here to learn and have fun, and maybe, if I'm lucky, help out now and then. Making a few friends or acquaintances along the way would be icing on the cake. [1] I personally find it very petty when Uri mentions his work as a Perl "recruitment agent" (for lack of a better description right now) and implies that he'll never consider you as a potential candidate with regards to that because of your opinion on a subjective topic. That's not even a relevant qualification, IMHO; I bet there are a few thousands, if not millions, of people doing that job that don't even know the first thing about software development. Go consult http://thedailywtf.com/ for some fun stories about people being hired in senior programming roles without even knowing the very basics of programming. :-X [2] Sorry, Linus, for dragging your name into this. [3] http://static.allegro.cc/image/cache/8/0/80957c72518411bd61070d1b9a026d61.jpg -- Brandon McCaig <http://www.bamccaig.com/> <bamcc...@gmail.com> V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl. Castopulence Software <http://www.castopulence.org/> <bamcc...@castopulence.org> -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/