Loading ...
Sorry, an error occurred while loading the content.

Sudoku and TDD

Expand Messages
  • martijn_meijering
    A friend just sent me the following link: http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ Our very own Ron Jeffries comes in for some criticism.
    Message 1 of 22 , Apr 26 10:53 AM
    • 0 Attachment
      A friend just sent me the following link:

      http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/

      Our very own Ron Jeffries comes in for some criticism. Intelligent
      comments follow. Interesting.

      ---

      April 25, 2007
      How to not solve a Sudoku

      I found this at Ravi Mohan's One Man Hacking:

      Ron Jeffries attempts to create a sudoku solver - here, here,
      here, here and here. (You really ought to read these articles. They
      are ummm…{cough} …err…. enlightening.)

      Peter Norvig creates a Sudoku Solver.

      Compare. Learn.

      To increase the impact, I suggest you read Norvig's essay first. It's
      a great read and the elegance and concision of his solution gave me
      this tingly warm feeling of sheer developer entrancement. In contrast,
      Jeffries' writings on implementing a Sudoku solver by following a
      test-driven development approach, are just disconcerting. In the end,
      he abandons his half-finished work after five postings. If he achieves
      anything, he impressively demonstrates that he's not exactly an
      algorithms expert (which Peter Norvig, of course, is).
    • Charlie Poole
      It s clear that the blogger doesn t get that the purpose of the two exercises was entirely different and that they each meet their separate objectives. Charlie
      Message 2 of 22 , Apr 26 11:01 AM
      • 0 Attachment
        It's clear that the blogger doesn't get that the purpose of the two
        exercises was entirely different and that they each meet their separate
        objectives.

        Charlie

        > -----Original Message-----
        > From: extremeprogramming@yahoogroups.com
        > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
        > martijn_meijering
        > Sent: Thursday, April 26, 2007 10:54 AM
        > To: extremeprogramming@yahoogroups.com
        > Subject: [XP] Sudoku and TDD
        >
        > A friend just sent me the following link:
        >
        > http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/
        >
        > Our very own Ron Jeffries comes in for some criticism.
        > Intelligent comments follow. Interesting.
        >
        > ---
        >
        > April 25, 2007
        > How to not solve a Sudoku
        >
        > I found this at Ravi Mohan's One Man Hacking:
        >
        > Ron Jeffries attempts to create a sudoku solver - here,
        > here, here, here and here. (You really ought to read these
        > articles. They are ummm.{cough} .err.. enlightening.)
        >
        > Peter Norvig creates a Sudoku Solver.
        >
        > Compare. Learn.
        >
        > To increase the impact, I suggest you read Norvig's essay
        > first. It's a great read and the elegance and concision of
        > his solution gave me this tingly warm feeling of sheer
        > developer entrancement. In contrast, Jeffries' writings on
        > implementing a Sudoku solver by following a test-driven
        > development approach, are just disconcerting. In the end, he
        > abandons his half-finished work after five postings. If he
        > achieves anything, he impressively demonstrates that he's not
        > exactly an algorithms expert (which Peter Norvig, of course, is).
        >
        >
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to:
        > extremeprogramming-unsubscribe@...
        >
        > ad-free courtesy of objectmentor.com
        > Yahoo! Groups Links
        >
        >
        >
        >
      • ramacd
        A solver that doesn t waste a lot of bytes in explanation: http://www.jsoftware.com/jwiki/Essays/Sudoku
        Message 3 of 22 , Apr 26 11:07 AM
        • 0 Attachment
          A solver that doesn't waste a lot of bytes in explanation:

          http://www.jsoftware.com/jwiki/Essays/Sudoku


          martijn_meijering wrote:
          >
          > A friend just sent me the following link:
          >
          > http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/
          > <http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/>
          >
          > Our very own Ron Jeffries comes in for some criticism. Intelligent
          > comments follow. Interesting.
          >
          > ---
          >
          > April 25, 2007
          > How to not solve a Sudoku
          >
          > I found this at Ravi Mohan's One Man Hacking:
          >
          > Ron Jeffries attempts to create a sudoku solver - here, here,
          > here, here and here. (You really ought to read these articles. They
          > are ummm…{cough} …err…. enlightening.)
          >
          > Peter Norvig creates a Sudoku Solver.
          >
          > Compare. Learn.
          >
          > To increase the impact, I suggest you read Norvig's essay first. It's
          > a great read and the elegance and concision of his solution gave me
          > this tingly warm feeling of sheer developer entrancement. In contrast,
          > Jeffries' writings on implementing a Sudoku solver by following a
          > test-driven development approach, are just disconcerting. In the end,
          > he abandons his half-finished work after five postings. If he achieves
          > anything, he impressively demonstrates that he's not exactly an
          > algorithms expert (which Peter Norvig, of course, is).
          >
          >
        • Ron Jeffries
          Hello, ramacd. On Thursday, April 26, 2007, at 2:07:02 PM, you ... It s kind of a question of what one is trying to do. I m trying to let people have a
          Message 4 of 22 , Apr 26 11:30 AM
          • 0 Attachment
            Hello, ramacd. On Thursday, April 26, 2007, at 2:07:02 PM, you
            wrote:

            > A solver that doesn't waste a lot of bytes in explanation:

            > http://www.jsoftware.com/jwiki/Essays/Sudoku

            It's kind of a question of what one is trying to do. I'm trying to
            let people have a glimpse of how I use code to figure things out.

            Ron Jeffries
            www.XProgramming.com
            Find the simple path to what works and follow it,
            always looking for a simpler path. -- Patrick D. Smith
          • Adam Sroka
            ... Further, the comparison is entirely useless. What the others are doing is demonstrating known solutions to known problems. What Ron is doing is
            Message 5 of 22 , Apr 26 3:26 PM
            • 0 Attachment
              On 4/26/07, Ron Jeffries <ronjeffries@...> wrote:
              >
              >
              >
              >
              >
              >
              > Hello, ramacd. On Thursday, April 26, 2007, at 2:07:02 PM, you
              > wrote:
              >
              > > A solver that doesn't waste a lot of bytes in explanation:
              >
              > > http://www.jsoftware.com/jwiki/Essays/Sudoku
              >
              > It's kind of a question of what one is trying to do. I'm trying to
              > let people have a glimpse of how I use code to figure things out.
              >
              >

              Further, the comparison is entirely useless. What the others are doing
              is demonstrating known solutions to known problems. What Ron is doing
              is demonstrating a process to elucidate a working solution to a poorly
              understood problem. The former is almost entirely irrelevant to
              writing business software. It is academic.
            • William Pietri
              ... A math professor friend of mind once complained about a particularly tidy mathematical genius (I think it was Gauss, but it s been a decade) who ended up
              Message 6 of 22 , Apr 26 4:04 PM
              • 0 Attachment
                Ron Jeffries wrote:
                >
                > It's kind of a question of what one is trying to do. I'm trying to
                > let people have a glimpse of how I use code to figure things out.
                >


                A math professor friend of mind once complained about a particularly
                tidy mathematical genius (I think it was Gauss, but it's been a decade)
                who ended up substantially changing the way results were published.
                Before his time, published proofs tended to be longer and more
                meandering, as the reflected not just the result, but how the result was
                arrived at. This fellow (let's presume it was Gauss) relentlessly
                polished before publication, getting down to the bare minimum, the most
                brilliant proofs.

                It was apparently much more impressive to read, and everybody started
                following Gauss's approach. Although this permanently raised the bar,
                which is in some sense a good thing, it removed a lot of the clues that
                students and mere mortals used to see how good math was really done. My
                friend compared it to climbing up and pulling the ladder up after you.

                Like my friend, I think both styles have their place. But your narrative
                approach seems to fit much better with the agile values we're promoting,
                which advocates steady, relentless improvement over showy flashes of
                unreproduceable brilliance.

                William
              • Siddharta Govindaraj
                ... The point made in the post (this is in the comments of the original post) is that the algorithm will not emerge using TDD. You need to know the algorithm
                Message 7 of 22 , Apr 26 9:31 PM
                • 0 Attachment
                  > Further, the comparison is entirely useless. What the others are doing
                  > is demonstrating known solutions to known problems. What Ron is doing
                  > is demonstrating a process to elucidate a working solution to a poorly
                  > understood problem. The former is almost entirely irrelevant to
                  > writing business software. It is academic.
                  >

                  The point made in the post (this is in the comments of the original
                  post) is that the algorithm will not 'emerge' using TDD. You need to
                  know the algorithm beforehand and then you can implement it (using TDD
                  if need be). There is no point writing tests and refactoring in the
                  hope that the algorithm will reveal itself. Its valuable to completely
                  figure out an algorithm on paper before starting to code.

                  --
                  Siddharta Govindaraj
                • Adam Sroka
                  ... Which is a valid point, but so is mine. I have been writing business software for quite a while now and I can count the number of times I ve had to design
                  Message 8 of 22 , Apr 26 10:18 PM
                  • 0 Attachment
                    On 4/26/07, Siddharta Govindaraj <govind@...> wrote:
                    >
                    >
                    >
                    >
                    >
                    >
                    > > Further, the comparison is entirely useless. What the others are doing
                    > > is demonstrating known solutions to known problems. What Ron is doing
                    > > is demonstrating a process to elucidate a working solution to a poorly
                    > > understood problem. The former is almost entirely irrelevant to
                    > > writing business software. It is academic.
                    > >
                    >
                    > The point made in the post (this is in the comments of the original
                    > post) is that the algorithm will not 'emerge' using TDD. You need to
                    > know the algorithm beforehand and then you can implement it (using TDD
                    > if need be). There is no point writing tests and refactoring in the
                    > hope that the algorithm will reveal itself. Its valuable to completely
                    > figure out an algorithm on paper before starting to code.
                    >
                    > --
                    > Siddharta Govindaraj
                    >

                    Which is a valid point, but so is mine. I have been writing business
                    software for quite a while now and I can count the number of times
                    I've had to design an algorithm. A few times I had to look one up.
                    Most often I just call a library that implements it for me. The hard
                    part in business software isn't coding algorithms. It is understanding
                    what problem you need the computer to solve and why.

                    If someone paid me to write a sudoka solver I might have a different
                    outlook. Instead, they pay me to help them to make their lives easier
                    and run their business. Often they have only vague ideas about how I
                    am going to do that, but the ideas evolve over time.

                    Because this is the nature of business software, it is often more
                    valuable to come up with a naive, working solution quickly so that its
                    usefulness can be evaluated than to spend time designing a superior
                    but ultimately no more useful solution.
                  • Charlie Poole
                    Hi Siddharta, ... That s a pretty well-known characteristic of TDD, often discussed here and on the TDD list. So if the author of the comment thought he was
                    Message 9 of 22 , Apr 26 11:17 PM
                    • 0 Attachment
                      Hi Siddharta,

                      > > Further, the comparison is entirely useless. What the
                      > others are doing
                      > > is demonstrating known solutions to known problems. What
                      > Ron is doing
                      > > is demonstrating a process to elucidate a working solution
                      > to a poorly
                      > > understood problem. The former is almost entirely irrelevant to
                      > > writing business software. It is academic.
                      > >
                      >
                      > The point made in the post (this is in the comments of the original
                      > post) is that the algorithm will not 'emerge' using TDD. You
                      > need to know the algorithm beforehand and then you can
                      > implement it (using TDD if need be). There is no point
                      > writing tests and refactoring in the hope that the algorithm
                      > will reveal itself. Its valuable to completely figure out an
                      > algorithm on paper before starting to code.

                      That's a pretty well-known characteristic of TDD, often discussed
                      here and on the TDD list. So if the author of the comment thought
                      he was making a point that contradicts the notions of TDD, he was
                      wrong.

                      That said, some people think better while coding, others while
                      making marks on a yellow pad.

                      Charlie
                    • William Pietri
                      ... Hmmmm... I don t know how you figure out algorithms, but for me there s a lot of tinkering with the problem until I understand what s really going on. It s
                      Message 10 of 22 , Apr 26 11:54 PM
                      • 0 Attachment
                        Siddharta Govindaraj wrote:
                        > The point made in the post (this is in the comments of the original
                        > post) is that the algorithm will not 'emerge' using TDD. You need to
                        > know the algorithm beforehand and then you can implement it (using TDD
                        > if need be). There is no point writing tests and refactoring in the
                        > hope that the algorithm will reveal itself. Its valuable to completely
                        > figure out an algorithm on paper before starting to code.
                        >

                        Hmmmm... I don't know how you figure out algorithms, but for me there's
                        a lot of tinkering with the problem until I understand what's really
                        going on. It's getting down and dirty with the nature of the problem
                        that gives me the raw material to find the solution.

                        Sometimes I do that with scratch paper. Sometimes I do it by pushing
                        coins around on a table. Sometimes it's with scratch code. And
                        sometimes, yes, I do it with TDD.

                        There may be no point for you to use TDD, but it seems a little sweeping
                        to say that there's no point for anybody to use a method, doesn't it

                        William
                      • Ron Jeffries
                        Hello, Siddharta. On Friday, April 27, 2007, at 12:31:03 AM, you ... That s one way ... and certainly I think one has to know what to do before one does it,
                        Message 11 of 22 , Apr 27 12:29 AM
                        • 0 Attachment
                          Hello, Siddharta. On Friday, April 27, 2007, at 12:31:03 AM, you
                          wrote:

                          >> Further, the comparison is entirely useless. What the others are doing
                          >> is demonstrating known solutions to known problems. What Ron is doing
                          >> is demonstrating a process to elucidate a working solution to a poorly
                          >> understood problem. The former is almost entirely irrelevant to
                          >> writing business software. It is academic.

                          > The point made in the post (this is in the comments of the original
                          > post) is that the algorithm will not 'emerge' using TDD. You need to
                          > know the algorithm beforehand and then you can implement it (using TDD
                          > if need be). There is no point writing tests and refactoring in the
                          > hope that the algorithm will reveal itself. Its valuable to completely
                          > figure out an algorithm on paper before starting to code.

                          That's one way ... and certainly I think one has to know what to do
                          before one does it, in every case, to some degree.

                          On the other hand, what we have in the code so far is a modular
                          structure with multiple strategies, which will, I think, be
                          extendable as other strategies are discovered or invented. There are
                          sometimes known and concrete strategies for solving problems, but
                          more commonly not. The world doesn't seem to be made up of math and
                          sudoku.

                          Ron Jeffries
                          www.XProgramming.com
                          We cannot solve our problems with the same thinking we used when we created them.
                          -- Albert Einstein
                        • Ron Jeffries
                          ... Ron Jeffries www.XProgramming.com Fatalism is born of the fear of failure, for we all believe that we carry success in our own hands, and we suspect that
                          Message 12 of 22 , Apr 27 12:30 AM
                          • 0 Attachment
                            Hello, Adam. +1! On Friday, April 27, 2007, at 1:18:05 AM, you wrote:

                            > Which is a valid point, but so is mine. I have been writing business
                            > software for quite a while now and I can count the number of times
                            > I've had to design an algorithm. A few times I had to look one up.
                            > Most often I just call a library that implements it for me. The hard
                            > part in business software isn't coding algorithms. It is understanding
                            > what problem you need the computer to solve and why.

                            > If someone paid me to write a sudoka solver I might have a different
                            > outlook. Instead, they pay me to help them to make their lives easier
                            > and run their business. Often they have only vague ideas about how I
                            > am going to do that, but the ideas evolve over time.

                            > Because this is the nature of business software, it is often more
                            > valuable to come up with a naive, working solution quickly so that its
                            > usefulness can be evaluated than to spend time designing a superior
                            > but ultimately no more useful solution.



                            Ron Jeffries
                            www.XProgramming.com
                            Fatalism is born of the fear of failure, for we all believe that we carry
                            success in our own hands, and we suspect that our hands are weak. -- Conrad
                          • Siddharta Govindaraj
                            ... Exactly. Different situations need different approaches. In this case, the problem was a sudoku solver. I don t think the original blog post meant to say
                            Message 13 of 22 , Apr 27 6:39 AM
                            • 0 Attachment
                              --- In extremeprogramming@yahoogroups.com, "Adam Sroka"
                              > If someone paid me to write a sudoka solver I might have a different
                              > outlook. Instead, they pay me to help them to make their lives easier
                              > and run their business.

                              Exactly. Different situations need different approaches. In this case,
                              the problem was a sudoku solver. I don't think the original blog post
                              meant to say that TDD is bad, but that TDD is not always the answer.
                              There are situations where it works, and situations where it doesnt.

                              On a side note: Isn't there a subthread here that !TDD==Hacking?
                              That's the kind of dangerous generalisation that gives agile a bad
                              name. Every practice has a context around it.

                              --
                              Siddharta Govindaraj
                            • Tim Haughton
                              ... On a not altogether unrelated note, Uncle Bob did an interesting spot on TDD ing an algorithm. Most people wouldn t think of TDD ing algorithms, but his
                              Message 14 of 22 , Apr 27 7:37 AM
                              • 0 Attachment
                                On 27/04/07, Siddharta Govindaraj <govind@...> wrote:
                                > Exactly. Different situations need different approaches. In this case,
                                > the problem was a sudoku solver. I don't think the original blog post
                                > meant to say that TDD is bad, but that TDD is not always the answer.
                                > There are situations where it works, and situations where it doesnt.

                                On a not altogether unrelated note, Uncle Bob did an interesting spot
                                on TDD'ing an algorithm. Most people wouldn't think of TDD'ing
                                algorithms, but his results are interesting.

                                http://butunclebob.com/ArticleS.UncleBob.ThePrimeFactorsKata

                                --
                                Regards,

                                Tim Haughton
                              • ramacd
                                Colour me confused: Is Sudoku a known problem or a poorly understood one? Just like the Bowling Game, where Ron took a 3 line J solution and turned it into a
                                Message 15 of 22 , Apr 27 8:05 AM
                                • 0 Attachment
                                  Colour me confused:

                                  Is Sudoku a known problem or a poorly understood one?

                                  Just like the Bowling Game, where Ron took a 3 line J solution and
                                  turned it into a page of Ruby, I saw a simple problem being made overly
                                  complex. Now I'm not in the "why walk when you can drive" camp that
                                  results in gasoline being wasted on a lot of 2 minute trips, I'm in the
                                  "why go miles out of your way to ford the stream, when the bridge is
                                  right here?" one.

                                  Maybe using APL/J has made me leery of solutions where the code is near
                                  in size to the tests. I'm used to a ratio of 10:1 or higher. After all,
                                  in my experience, 90% of a problem is stating it.

                                  Adam Sroka wrote:
                                  >
                                  > On 4/26/07, Ron Jeffries <ronjeffries@...
                                  > <mailto:ronjeffries%40xprogramming.com>> wrote:
                                  > >
                                  > >
                                  > >
                                  > >
                                  > >
                                  > >
                                  > > Hello, ramacd. On Thursday, April 26, 2007, at 2:07:02 PM, you
                                  > > wrote:
                                  > >
                                  > > > A solver that doesn't waste a lot of bytes in explanation:
                                  > >
                                  > > > http://www.jsoftware.com/jwiki/Essays/Sudoku
                                  > <http://www.jsoftware.com/jwiki/Essays/Sudoku>
                                  > >
                                  > > It's kind of a question of what one is trying to do. I'm trying to
                                  > > let people have a glimpse of how I use code to figure things out.
                                  > >
                                  > >
                                  >
                                  > Further, the comparison is entirely useless. What the others are doing
                                  > is demonstrating known solutions to known problems. What Ron is doing
                                  > is demonstrating a process to elucidate a working solution to a poorly
                                  > understood problem. The former is almost entirely irrelevant to
                                  > writing business software. It is academic.
                                  >
                                  >
                                • ramacd
                                  A question: How do we know Gauss needed a ladder? It was Gauss after all. (another one: how does one get rid of irrelevant parts of the quoted text. It seems
                                  Message 16 of 22 , Apr 27 8:13 AM
                                  • 0 Attachment
                                    A question:

                                    How do we know Gauss needed a ladder? It was Gauss after all.

                                    (another one: how does one get rid of irrelevant parts of the quoted
                                    text. It seems like theres an HTML spiderweb surrounding all the post.)

                                    William Pietri wrote:
                                    >
                                    > Ron Jeffries wrote:
                                    > >
                                    > > It's kind of a question of what one is trying to do. I'm trying to
                                    > > let people have a glimpse of how I use code to figure things out.
                                    > >
                                    >
                                    > A math professor friend of mind once complained about a particularly
                                    > tidy mathematical genius (I think it was Gauss, but it's been a decade)
                                    > who ended up substantially changing the way results were published.
                                    > Before his time, published proofs tended to be longer and more
                                    > meandering, as the reflected not just the result, but how the result was
                                    > arrived at. This fellow (let's presume it was Gauss) relentlessly
                                    > polished before publication, getting down to the bare minimum, the most
                                    > brilliant proofs.
                                    >
                                    > It was apparently much more impressive to read, and everybody started
                                    > following Gauss's approach. Although this permanently raised the bar,
                                    > which is in some sense a good thing, it removed a lot of the clues that
                                    > students and mere mortals used to see how good math was really done. My
                                    > friend compared it to climbing up and pulling the ladder up after you.
                                    >
                                    > Like my friend, I think both styles have their place. But your narrative
                                    > approach seems to fit much better with the agile values we're promoting,
                                    > which advocates steady, relentless improvement over showy flashes of
                                    > unreproduceable brilliance.
                                    >
                                    > William
                                    >
                                    >
                                  • Elizabeth Keogh
                                    ... Dear Rubyjin, Thank you for your work on the sudoku solver. I am now using this to check the sudokus I am crafting for the newspaper. Yesterday I found
                                    Message 17 of 22 , Apr 27 9:21 AM
                                    • 0 Attachment
                                      ramacd wrote on 27/04/2007 16:05:37:

                                      > Just like the Bowling Game, where Ron took a 3 line J solution and
                                      > turned it into a page of Ruby, I saw a simple problem being made overly
                                      > complex.

                                      Dear Rubyjin,

                                      Thank you for your work on the sudoku solver. I am now using this to check
                                      the sudokus I am crafting for the newspaper.

                                      Yesterday I found that the solver came up with a different solution to
                                      mine. After some more careful manual checking, I found that there were in
                                      fact two solutions. It would have been very bad if I had submitted this to
                                      the paper!

                                      Please could you change your solver so that it tells me if a sudoku has
                                      more than one solution?

                                      Thanks,
                                      Sudokujin.

                                      PS: People are not simple problems.
                                      PPS: All problems for which people want solutions are people problems.
                                      PPPS: Deploy it to production. It's the only way to be sure.

                                      --
                                      Elizabeth Keogh
                                      liz@...
                                      http://sirenian.livejournal.com
                                      http://jbehave.org


                                      [Non-text portions of this message have been removed]
                                    • Ron Jeffries
                                      Hello, ramacd. On Friday, April 27, 2007, at 11:05:37 AM, you ... I d love to see a simpler Ruby version that follows the J style. Ron Jeffries
                                      Message 18 of 22 , Apr 27 10:57 AM
                                      • 0 Attachment
                                        Hello, ramacd. On Friday, April 27, 2007, at 11:05:37 AM, you
                                        wrote:

                                        > Just like the Bowling Game, where Ron took a 3 line J solution and
                                        > turned it into a page of Ruby, I saw a simple problem being made overly
                                        > complex. Now I'm not in the "why walk when you can drive" camp that
                                        > results in gasoline being wasted on a lot of 2 minute trips, I'm in the
                                        > "why go miles out of your way to ford the stream, when the bridge is
                                        > right here?" one.

                                        I'd love to see a simpler Ruby version that follows the J style.

                                        Ron Jeffries
                                        www.XProgramming.com
                                        Anyone can make the simple complicated.
                                        Creativity is making the complicated simple. -- Charles Mingus
                                      • Adam Sroka
                                        ... When teaching almost any discipline, it is common to take simple, understandable problems and show their solutions using techniques that have broader real
                                        Message 19 of 22 , Apr 27 11:51 AM
                                        • 0 Attachment
                                          On 4/27/07, ramacd <ramacd@...> wrote:
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          > Colour me confused:
                                          >
                                          > Is Sudoku a known problem or a poorly understood one?
                                          >
                                          > Just like the Bowling Game, where Ron took a 3 line J solution and
                                          > turned it into a page of Ruby, I saw a simple problem being made overly
                                          > complex. Now I'm not in the "why walk when you can drive" camp that
                                          > results in gasoline being wasted on a lot of 2 minute trips, I'm in the
                                          > "why go miles out of your way to ford the stream, when the bridge is
                                          > right here?" one.
                                          >
                                          > Maybe using APL/J has made me leery of solutions where the code is near
                                          > in size to the tests. I'm used to a ratio of 10:1 or higher. After all,
                                          > in my experience, 90% of a problem is stating it.
                                          >
                                          >

                                          When teaching almost any discipline, it is common to take simple,
                                          understandable problems and show their solutions using techniques that
                                          have broader real world applications. The bowling game and sudoku were
                                          both chosen for the same reasons. Those reasons are: that they are
                                          simple enough for anyone to grasp, but complex enough to demonstrate
                                          the technique and possibly lead in some interesting directions.

                                          An exploratory solution to sudoku is no more or less practical than
                                          your typical "Hello, World" example. It serves the same purpose. It
                                          shows what the technique can do without getting overly bogged down in
                                          complex domain issues. If you wanted to type "Hello, World" what type
                                          of VM would you need? Most people would just use MS Word, but how
                                          often does it come up?
                                        • William Tozier
                                          ... Or, better, fixes it so that it doesn t have more than one solution. ... Bill Tozier AIM: vaguery@mac.com; Skype: vaguery; Twitter: Vaguery
                                          Message 20 of 22 , Apr 27 1:42 PM
                                          • 0 Attachment
                                            On Apr 27, 2007, at 12:21 PM, Elizabeth Keogh wrote:

                                            > Please could you change your solver so that it tells me if a sudoku
                                            > has
                                            > more than one solution?
                                            Or, better, fixes it so that it doesn't have more than one solution.
                                            -----
                                            Bill Tozier
                                            AIM: vaguery@...; Skype: vaguery; Twitter: Vaguery
                                            thttp://williamtozier.com/slurry

                                            "People who write obscurely are either unskilled in writing or up to
                                            mischief."
                                            -- Sir Peter Medawar
                                          • Kelly Anderson
                                            ... This is clearly the case. So is XP/TDD explicitly designed to solve the problems of the business programmer? Or, is it equally applicable in all domains?
                                            Message 21 of 22 , Apr 27 8:42 PM
                                            • 0 Attachment
                                              On 4/26/07, Adam Sroka <adam.sroka@...> wrote:
                                              > On 4/26/07, Siddharta Govindaraj <govind@...> wrote:
                                              > Which is a valid point, but so is mine. I have been writing business
                                              > software for quite a while now and I can count the number of times
                                              > I've had to design an algorithm. A few times I had to look one up.
                                              > Most often I just call a library that implements it for me. The hard
                                              > part in business software isn't coding algorithms. It is understanding
                                              > what problem you need the computer to solve and why.

                                              This is clearly the case. So is XP/TDD explicitly designed to solve
                                              the problems of the business programmer? Or, is it equally applicable
                                              in all domains? My suspicion is that it's optimized for business
                                              programming, and while it would be effective at scientific
                                              programming, there might be other methods for doing that which would
                                              be just about as good in some cases.

                                              I personally found the posted code to be hard to read, even though it
                                              was compact and fast. I suspect it would be rather difficult to
                                              maintain. Ron's solution was rather verbose, and had the disadvantage
                                              of never being finished... which was really it's biggest failing from
                                              an XP perspective IMHO. Aren't we supposed to try and get something
                                              simple and limited working, and then improve it?

                                              > If someone paid me to write a sudoka solver I might have a different
                                              > outlook. Instead, they pay me to help them to make their lives easier
                                              > and run their business. Often they have only vague ideas about how I
                                              > am going to do that, but the ideas evolve over time.

                                              And Ron's ideas about the original Soduku puzzle were also vague. At
                                              the time, I ribbed Ron a bit trying to get him to do the simplest
                                              thing that could possibly work (a mildly pruned recursive search) but
                                              I don't think I got through because he was after something different
                                              than I was.

                                              If I were to approach this problem, I would use TDD for sure. I would
                                              program up the slowest Suduku solver in the world that worked, and
                                              then I would use TDD with fanatic relentless refactoring to optimize
                                              for both speed, maintainability and readability.

                                              I would rather use Ron's code base to create a Sudoku puzzle creator.
                                              And that's one next logical step.

                                              > Because this is the nature of business software, it is often more
                                              > valuable to come up with a naive, working solution quickly so that its
                                              > usefulness can be evaluated than to spend time designing a superior
                                              > but ultimately no more useful solution.

                                              Clearly.

                                              -Kelly
                                            • Ron Jeffries
                                              Hello, Kelly. On Friday, April 27, 2007, at 11:42:35 PM, you ... I wouldn t say that TDD is optimized for anything, though it might be optimal or better
                                              Message 22 of 22 , May 1, 2007
                                              • 0 Attachment
                                                Hello, Kelly. On Friday, April 27, 2007, at 11:42:35 PM, you
                                                wrote:

                                                > This is clearly the case. So is XP/TDD explicitly designed to solve
                                                > the problems of the business programmer? Or, is it equally applicable
                                                > in all domains? My suspicion is that it's optimized for business
                                                > programming, and while it would be effective at scientific
                                                > programming, there might be other methods for doing that which would
                                                > be just about as good in some cases.

                                                I wouldn't say that TDD is "optimized" for anything, though it might
                                                be "optimal" or "better" for one thing or another. As is any
                                                technique, I imagine.

                                                > I personally found the posted code to be hard to read, even though it
                                                > was compact and fast. I suspect it would be rather difficult to
                                                > maintain. Ron's solution was rather verbose, and had the disadvantage
                                                > of never being finished... which was really it's biggest failing from
                                                > an XP perspective IMHO. Aren't we supposed to try and get something
                                                > simple and limited working, and then improve it?

                                                It does go thru a few versions, but not as many as I had
                                                contemplated. I might go back to it, but I think as it stands it
                                                does show the main things I had in mind, namely how to use code to
                                                think about algorithms. It's probable, given the blog stuff we've
                                                read, that I didn't bring out that point well enough, at least for
                                                some readers, though folks here seemed to get it.

                                                >> If someone paid me to write a sudoka solver I might have a different
                                                >> outlook. Instead, they pay me to help them to make their lives easier
                                                >> and run their business. Often they have only vague ideas about how I
                                                >> am going to do that, but the ideas evolve over time.

                                                > And Ron's ideas about the original Soduku puzzle were also vague. At
                                                > the time, I ribbed Ron a bit trying to get him to do the simplest
                                                > thing that could possibly work (a mildly pruned recursive search) but
                                                > I don't think I got through because he was after something different
                                                > than I was.

                                                Yes. It would have been easy enough to do a full-on search. That
                                                wasn't my purpose: my purpose was to solve it knowing only what a
                                                human would, not someone with math and computer science degrees.

                                                To me that's what makes it fun.

                                                > If I were to approach this problem, I would use TDD for sure. I would
                                                > program up the slowest Suduku solver in the world that worked, and
                                                > then I would use TDD with fanatic relentless refactoring to optimize
                                                > for both speed, maintainability and readability.

                                                Yes ... where I wanted a strategic one that used human strategies.

                                                > I would rather use Ron's code base to create a Sudoku puzzle creator.
                                                > And that's one next logical step.

                                                >> Because this is the nature of business software, it is often more
                                                >> valuable to come up with a naive, working solution quickly so that its
                                                >> usefulness can be evaluated than to spend time designing a superior
                                                >> but ultimately no more useful solution.

                                                > Clearly.

                                                Seems so to me ...

                                                Ron Jeffries
                                                www.XProgramming.com
                                                You don't want to sell me waterfall.
                                                You want to go home and rethink your life.
                                              Your message has been successfully submitted and would be delivered to recipients shortly.