Thank you for being so condescending.

Post #149,231 by Arkadiy 3/29/04 3:44:10 PM Reply	Thank you for being so condescending. I know what regexps are, I use emacs daily (minutely is more like it). What Barry actually wrote as far as regexps are concerned is s/\$\$//g which (in Perl) means as far as I can tell "replace every occurence of literal string "()" with empty string. My problem (and Barry's, AFICT) start with figuring out why the entire statement $x = s/\$\$//g; ended up setting $x to empty string. The interactions of Perl's scalar cntext, the suspected (incorrectly, I guess) list nature of s/// 's return value, Perl's rule of list's size being returned by list in scalar context, $_ used as the string in which sust is done by default - all that confuses people. Yes, after 5 seconds with a book I was able to figure out that s/// returns 1 or "" depending on whether something matched. Yes, it's all really crystal clear - after all, if the computer can understand it, humans certainly should be able to. But somehow, the entire incident doen't inspire any confidence in Perl's friendlines to programmers. May be I am just not worthy. May be mine is the domain of static languages with restrictive syntax. Funny, though, I don't have too much problems parsing Smalltalk. Or TCL. Or Python. It's just Perl that drives me up the wall. -- Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them. --Alan Cooper. The Inmates Are Running the Asylum
Post #149,233 by Arkadiy 3/29/04 3:46:11 PM Reply	Oh, grand. My book doesn't tell me that s///g returns number of matches, not just "1". Will the wonders ever cease. -- Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them. --Alan Cooper. The Inmates Are Running the Asylum
Post #149,249 by ben_tilly 3/29/04 4:28:27 PM Reply	Look at the type of error for a second First of all I misunderstood what you found so cryptic. OK, I guessed, based on how many people complain about regular expressions. And so I responded to that part of things. But you are upset at how easily Barry was confused by his error. However look at the facts. The confusing part of Barry's mistake was that he wrote = where he meant to write =~. This is parallel to writing = instead of an operator like +=, *=, ==, !=, <=, >=, and so on. All of which will do something that you didn't expect, and can lead to conclusion. The only difference is that Barry was reaching for a Perl-specific operator rather than one that is familiar because it appears in C and most C-derived languages. If you type = instead of == in a comparison in C, you're probably in for a world of grief and wondering about why your numbers are horribly wrong. (If you're lucky, that is...) Every other example of the mistake is just as confusing to work out. Barry mistyped an operator. What resulted had a reasonable interpretation, so the compiler moved on and proceeded to do what it was told. It happens. You catch it and move on. How is that problem Perl-specific in any significant way? Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #149,258 by Arkadiy 3/29/04 4:51:19 PM Reply	Only in Perl something that _must_ have a string associated with it would bind to $_ when no string provided. Perl uses a binary operation and an odd function-like syntax where a function with three parameters would be less error- and confusion-prone. BTW, in modern C, when you write sometiong like if (a=1) return; , you get a warning. OK, may be we can get someting constructive out of this language war. Are there perl constructs that _you_ consider faux pas, not to be used except in throwaway or show-off code? -- Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them. --Alan Cooper. The Inmates Are Running the Asylum
Post #149,259 by ChrisR 3/29/04 4:56:16 PM Reply	Lint is your friend Even before the compilers started issuing warnings, Lint was able to catch a lot of these C "problems". As far as what not to use in Perl, I've heard it mentioned many times that the Strict option should be enabled to catch some of the really quirky things.
Post #149,268 by ben_tilly 3/29/04 5:37:08 PM Reply	Not only in Perl $_ has been borrowed, lock stock and barrel, by Ruby. Oddly enough I've never seen anyone complain about it there. On your comment about C, Perl has the same warning. It doesn't catch everything, though. As for your challenge, consider this: \nsub foo {\n my $bar if 0; # This makes a static variable! # do stuff\n}\n Deliberate misuse of a known bug is something that I'd never accept. In any language. Another is using `unless` together with any boolean logic. Rewrite with `if`. Really. I'm against using many of the things maintained for "backwards compatibility". Like the optional ' instead of ::, several of the more obscure special variables, and things like that. They can't be removed from Perl 5, but I wish that they could be. There are several other constructs which I consider "risky". They have small legitimate uses, but most of the time you shouldn't use them. Luckily using strict will turn several of them off. I used to argue strongly against using a map or grep for its side-effects, but then I saw someone demonstrate how that could naturally fall out of a reasonable coding style. I still think that most people shouldn't. There are plenty of "bad coding styles" that are common in Perl. I'm against most of them..in any context other than on a command line. There I accept that it can be an issue to require a small amount of extra typing. Unless there is a demonstrated reason for it in your code, I'm against the popular `my $class = ref($self) \|\| $self;` construct. I could go on, but I think that I've answered the question. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #149,270 by Arkadiy 3/29/04 5:45:49 PM Reply	Thanks for examples -- Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them. --Alan Cooper. The Inmates Are Running the Asylum
Post #149,275 by ChrisR 3/29/04 5:57:32 PM Reply	Style guide As long as we're on the subject, are there any books or references that are along the lines of "Smalltalk with Style" that are geared towards Perl? There's lotsa of nasty stuff you could do with Smalltalk that is usually controlled by the cultural idioms. Perl seems to be much looser in it's culture to force programming style (partly by the number and type of people who use perl - attempting to appeal to the masses, as well as the general philosophy of TIMTOWTDI.
Post #149,279 by ben_tilly 3/29/04 6:17:00 PM Reply	Not that I know of The closest thing is the output of `perldoc perlstyle`, which I don't think is what you're looking for. Perl culture seems to be absorbed (or not) by osmosis. And varies widely between people. As you note, Perl (or at least Larry) tries to appeal to many different programmers with very different backgrounds. A lot of useful work gets done (poorly) in Perl by programmers who haven't yet learned that consistent indentation is A Good Thing. Rather less (due to sheer force of numbers) useful work gets done (generally much better) by very competent programmers who are likely to come to Perl with strong opinions already developed that mostly are going to work out OK. This contrasts strongly with Smalltalk where (at least at the start) you could assume that anyone coming to Smalltalk was going to have some major unlearning to do first. Having a consistent style be part of the relearning makes sense in that context. The cognoscenti of Perl would generally be happy if everyone could learn not to use Matt Wright's scripts, and that the language is not called PERL. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]

Welcome to IWETHEY!