On Thursday, May 26, 2016 at 10:50:24 AM UTC-4, John Szakmeister wrote: > > I'm very much a fan of bailing out early in imperative > programming as it helps to avoid a bunch of nested if conditions > that are to follow and read. This typically comes up when > checking arguments to ensure that they're valid (in range, of > acceptable values, etc). One of the major stumbling blocks > I've had when writing Clojure is to find a good way to keep code > concise, but readable. > > Food for thought: that is pretty much how folks felt back in the late 70s when GOTO became a four-letter word and was deprecated in favor of structured programming. So your thought that this might be a transitional thing for you seemed right. Even coming from common lisp, I am waiting out attitude transitions myself.
I introduced structured programming at my first for-hire programming job after watching the senior devs flipping through COBOL printouts back and forth trying to follow the GOTOs. When asked to take a stab at improving things, I suggested (in part) going structured. My manager liked the idea and when I said I was going to throw in the occasional dead obvious GOTO, he challenged me to go pure. I did so but with the attitude of showing how silly the code would turn out. I ended up convinced. There was an emergent property from going pure: if I crashed at line 2042, I knew all the conditions that were true, because I knew exactly how I got there. Silly had value. Then another programmer was assigned to me and asked to clone my app for a different region. When she got stuck I helped her debug it, and it took hours (because compile times were half hours). It turns out the code we were staring at was forty lines down from a buggy "GOTO my-proc-end" by passing the code we knew had to be working, and monitors were 24x80 back then. btw. I myself am quite fond of Common Lisp return-from, so I am no purist. But I am hearing your actual use cases are hairy enough that the semantics of a long chain of code chunks each of them free to bail might be hard to follow. btw2, with others, I use COND a lot for these cases. But it only goes so far. Often I do some heavy-lifting in a clause that needs repeating in another clause if this one decides not to fire. btw3, yeah, SOME is a great operator. -hk -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.