A style question
in [Lisp]
|
From: Ken Tilton on 27 Feb 2007 22:11 Paul Wallich wrote: > job-271842874(a)craigslist.org wrote: > >> A friend passed on an article regarding the difficulty job candidates >> had in producing even simple programs (simple as in should take a >> minute or less). One example was a program to print the numbers 1 to >> 100 except that "Fizz" should be substituted for numbers divisible by >> 3, "Buzz" should be substituted for numbers divisible by 5, and >> "FizzBuzz" should be substituted for numbers divisible by both 3 and 5. >> >> So, having received my "ANSI Common Lisp" and "Practical Common Lisp" >> books two days ago (still waiting for "Structure and Interpretation of >> Computer Programs") and having a *couple hours* of Lisp under my belt, >> I cranked out a Lisp version. It seems a bit clunky, so I thought I'd >> see if anyone had suggestions for improvements. >> >> Here's a Ruby version for comparison: >> >> def fizz_buzz n >> 1.upto(n) do |i| >> print "Fizz" if fizz = (i % 3) == 0 >> print "Buzz" if buzz = (i % 5) == 0 >> puts fizz || buzz ? "" : i >> end >> end >> >> fizz_buzz 100 >> >> and the Lisp version >> >> (defun fizz-buzz (n) >> (do ((i 1 (+ i 1))) >> ((> i n)) >> (let >> ((fizz (= 0 (mod i 3))) >> (buzz (= 0 (mod i 5)))) >> (if fizz (format t "Fizz")) >> (if buzz (format t "Buzz")) >> (format t "~A~%" >> (if (or fizz buzz) "" i))))) > > > In both cases, what the local variables add in supposed elegance seems > to me lost by the clunkiness of setting them in the first place (which > you haven't done correctly). > > I'd probably brute-force the problem with a simple cond with a nested > conditions, along the lines of > (cond ((zerop (mod i 5)) > (cond ((zerop (mod i 3)) (print "FizzBuzz")) > (t (print "Buzz")))) > ((zerop (mod i 3)) > (print "Fizz")) > (t (print i))) I would object to using cond to implement if, and the redundant code testing for (mod i 3) and associating it with Fizz. Otherwise, I am bothered by the spec. Is the FizzBuzz on 15 tied to it factoring to 3 and 5 and those substitutions, or is that coincidental? ie, Could an RFE come thru for 15 to translate to Bang? Also, is this list expected to expand? If so, will the test always be even divisibility? This is how I get thrown out of most tech interviews. kt -- "I don't like being tested." -- Tangina, Poltergeist
From: Ken Tilton on 27 Feb 2007 22:18 job-271842874(a)craigslist.org wrote: > Frank Buss wrote: > >> job-271842874(a)craigslist.org wrote: >> >>> I cranked out a Lisp version. It seems a bit clunky, so I thought I'd >>> see if anyone had suggestions for improvements. >> >> >> looks ok, but I would use loop and organize the body of the loop a bit >> different: >> >> (defun fizz-buzz (n) >> (loop for i from 1 to n >> for fizz = (zerop (mod i 3)) >> for buzz = (zerop (mod i 5)) do >> (when fizz (princ "Fizz")) >> (when buzz (princ "Buzz")) >> (when (not (or fizz buzz)) (princ i)) >> (terpri))) >> > > Thanks. Some questions/comments: > > 1) In "ANSI Common Lisp", Graham makes the following comments: > "The loop macro was originally designed to help inexperienced Lisp > users write iterative code...Unfortunately, loop is more like English > than its designers ever intended...to understand it in the abstract is > almost impossible...For such reasons, the use of loop cannot be > recommended." > > Is this a minority view? One of the things that attracted me to Lisp > was the simplicity, consistency, etc. of the language, so when I read > the above, it seemed reasonable. I was anti-loop bigot for years, now I cannot even remember the syntax of dolist. PG is a closet Schemer. Look at Arc. Pure minimalist. He does not like CLOS either. Now it may be that /you/ are a latent Schemer and that would be fine, but the spirit of Common Lisp is the more mud the better. LOOP rocks. > > 2) Thanks for the zerop tip. I like (zerop (mod m n)) better than (= 0 > (mod m n)) > > 3) Any reason why you chose (when fizz (princ "Fizz")) instead of (if > fizz (princ "Fizz")) ? > > 4) Curious about the history of "terpri" - I guess it's shorter than > "newline" but not very intuitive :) > > I'm really enjoying learning Lisp. I realize at this stage I still have > some "the grass is greener" and "oh cool, something new to learn!" > influences, but I expect as that wears off the merits of the language > will continue to shine through. It does not wear off: http://wiki.alu.org/RtL_Highlight_Film Now get to work: http://wiki.alu.org/The_Road_to_Lisp_Survey Anybody want to let me know about Roads they have added over the past years that never made it to the highlight film? I mean, it /is/ a wiki, but I would be happy to play editor and pick out the sound bites from anyone not yet in the highlight film. kzo -- Well, I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd In this world, you must be oh so smart or oh so pleasant. -- Elwood's Mom
From: Thierry Pirot on 27 Feb 2007 22:24 Thierry Pirot writes: > job-271842874 writes: > > > (defun fizz-buzz (n) > > (do ((i 1 (+ i 1))) > > ((> i n)) > > (let > > ((fizz (= 0 (mod i 3))) > > (buzz (= 0 (mod i 5)))) > > (if fizz (format t "Fizz")) > > (if buzz (format t "Buzz")) > > (format t "~A~%" > > (if (or fizz buzz) "" i))))) > > > > (fizz-buzz 100) > > > In a more functional style, my 2 cents, > Ups, it's late here... > CL-USER> (defun printing (i) > (format t "~a~%" > (cond ((= 0 (mod i (* 3 5))) "FizzBuzz") > ((= 0 (mod i 3)) "Fizz") > ((= 0 (mod i 5)) "Buzz") > (t i))))
From: Vassil Nikolov on 27 Feb 2007 22:23 On Tue, 27 Feb 2007 21:02:46 -0500, job-271842874(a)craigslist.org said: |... | 1) In "ANSI Common Lisp", Graham makes the following comments: | "The loop macro was originally designed to help inexperienced Lisp | users write iterative code...Unfortunately, loop is more like English | than its designers ever intended...to understand it in the abstract is | almost impossible...For such reasons, the use of loop cannot be | recommended." | Is this a minority view? One of the things that attracted me to Lisp | was the simplicity, consistency, etc. of the language, so when I read | the above, it seemed reasonable. Gain experience with Common Lisp; in particular, learn (in alphabetical order) DO, DOLIST, DOTIMES, and LOOP. Use them and see how others have used them. Then form your own opinion. | ... | 4) Curious about the history of "terpri" - I guess it's shorter than | "newline" but not very intuitive :) Interesting---I was checking how googlable that was, and it turns out there is even http://terpri.org/ (q.v.). ---Vassil. -- mind mate, n. One of two persons mentally compatible with each other (cf. soul mate).
From: job-271842874 on 27 Feb 2007 22:30
Ken Tilton wrote: > Paul Wallich wrote: >> job-271842874(a)craigslist.org wrote: >> >>> A friend passed on an article regarding the difficulty job candidates >>> had in producing even simple programs (simple as in should take a >>> minute or less). One example was a program to print the numbers 1 to >>> 100 except that "Fizz" should be substituted for numbers divisible by >>> 3, "Buzz" should be substituted for numbers divisible by 5, and >>> "FizzBuzz" should be substituted for numbers divisible by both 3 and 5. >>> >> I'd probably brute-force the problem with a simple cond with a nested >> conditions, along the lines of >> (cond ((zerop (mod i 5)) >> (cond ((zerop (mod i 3)) (print "FizzBuzz")) >> (t (print "Buzz")))) >> ((zerop (mod i 3)) >> (print "Fizz")) >> (t (print i))) > > I would object to using cond to implement if, and the redundant code > testing for (mod i 3) and associating it with Fizz. I agree. I expect mod is fast, but I don't like to repeat myself. > Otherwise, I am bothered by the spec. Is the FizzBuzz on 15 tied to it > factoring to 3 and 5 and those substitutions, or is that coincidental? > ie, Could an RFE come thru for 15 to translate to Bang? Also, is this > list expected to expand? If so, will the test always be even divisibility? Yes, the FizzBuzz on 15 is because the spec said to print FizzBuzz instead of i for any i that is divisible by both 3 and 5. Regarding enhancements, I'll be including one in a reply to Paul in a few minutes. > This is how I get thrown out of most tech interviews. > > kt > |