> I am a firm believer in expressing things in the most straightforward > way possible. Most people find loops straightforward, so I'm happy to > use loops unless I have a good reason not to.
Most *people* find loops and all other programming constructs weird and opaque. Most *programmers* first programming language used if-else and some do-loop-thingy in the introductory section so *most* programmers find loops simpler than recursion or 2nd order operators, since they weren't until the advanced chapters of the book, if they were even included at all. Is this why Dijkstra said BASIC was a mind-crippling affliction? A mathematician would usually rather use a reduction to a previously solved problem than a counting argument. The beauty of Perl is that Larry has wrought a language in which you can express things according to your simplicity, and those who see an inner simplicity in the Lisp-inspired and APL-inspired dialects of Perl can also happily use our simplicity. > There are actually a lot of very prominent programmers who strongly > dislike exceptions. There are some very prominent programmers who strongly like Java too. There are many valid reasons to avoid using exceptions in a given program. There are also valid reasons to use them. TIMTOWDI. Many of the reasons to avoid using exceptions are throw-backs to the bad "it's a character string" exception of early Perl, Python, C++ exceptions. Fully wrought exception objects (which, Guido didn't seem to realize, could have a stringify operator to work compatibly with non-updated code!) address many of old issues. Exceptions do make life harder for package authors who want to support both callers who like exceptions and callers who don't but prefer to attempt to actually check all the function return codes. (Professor said to do that, but never did in the examples on the board, so few students really get the habit, alas.) > some kinds of programming they have a point. If your goal is to write > a robust program (ie one that will keep on running and doing the best > it can even though things are going to pot around and inside it) then > exceptions make your life very, very hard. Depends how you handle Exceptions If things are going to pot, exceptions can be used to focus the system on the survival priorities. Conversely, a single-threaded system trying to execute a control-law in a fixed time cycle would have a problem with exceptions (or garbage collection), but that's an obsolete criterion - even the airforce can afford multithreadable processors now. Exceptions implemented as old-style trap-this-if-found-call-that are the dual of the dreaded GOTO, they're basically a COME FROM, with all the problems of stack semnntics damage and the problems of action at a distance in the code. Try-Catch semantics control the stack semantics and localize the effects. > But in other kinds of > programming it is perfectly fine to terminate the program with an > exception, have the programmer see the error message, and fix it > properly. Exceptions do not require termination. The program can catch EVERYthing at top control loop and evaluate what's working and what isn't. There's more than one way to skin a camel. -- Bill [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
