tag:blogger.com,1999:blog-14853042.post3374472982753789159..comments2024-02-06T20:44:32.502+05:30Comments on One Man Hacking: Learning From Sudoku SolversRavihttp://www.blogger.com/profile/03630087669712445498noreply@blogger.comBlogger33125tag:blogger.com,1999:blog-14853042.post-35034415668184800052012-08-26T21:12:25.354+05:302012-08-26T21:12:25.354+05:30Very inspiring.
I have been trying very hard to g...Very inspiring.<br /><br />I have been trying very hard to go from a mad alchemist to deep systematic thought myself. I just hope I'm on the right path. :)Sanjoy Dashttp://playingwithpointers.comnoreply@blogger.comtag:blogger.com,1999:blog-14853042.post-64357442825766443832007-08-13T02:48:00.000+05:302007-08-13T02:48:00.000+05:30Here is a paper that details the algorithm for sol...Here is a paper that details the algorithm for solving Soduku in amy N x N puzzle, where N = m*m. The small 'm' is the submatrix. If m=3, then N=9. The author of the paper, Prof. Amy Langville, has already developed a Matlab code to solve her N x N soduku puzzle. The user just have to specify 'm' at the beginning, such as m = 6, and the algorithm will generate a N x N or 36 x 36 matrix soduku game. The author derived her algorithm using Integer Programming. <BR/><BR/>"An Integer Programming Model for the Sudoku Problem"<BR/>http://www.cofc.edu/~langvillea/Sudoku/sudoku2.pdf<BR/><BR/>Malab codes is available from the following link. You need Matlab ver 7, to run the code.<BR/><BR/>http://math.cofc.edu/langvillea/<BR/><BR/>Currently available Soduku, N = 9 (m=3), that is the soduku game is a 9 x 9 puzzle. The algorithm described above is a generalization to any N x N, eg, if m = 4, then the puzzle becomes a 16 x 16 one, which is more difficult.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14853042.post-7268764875319955412007-06-25T09:33:00.000+05:302007-06-25T09:33:00.000+05:30Hi all,I just read the top posts and I'm not sure ...Hi all,<BR/><BR/>I just read the top posts and I'm not sure whether this is a good place for this, but, here goes.<BR/><BR/>I'm trying to design in Flash a Sudoku creator. However, I'm stuck at a point where, after a while, the square I'm about to fill has run out of possible numbers to fill it with. Both a random choice of squares to fill and a top-to-bottom approach failed me.<BR/><BR/>I started with a simple algorithm, i.e. fill this square with a number that is not already chosen in the same row, column or 3x3 grid. That failed.<BR/><BR/>I then elaborated on that by filling that square by biasing on a number that has been chosen in an adjacent row, column or 3x3 grid. E.g. Suppose A1 has 1 in it. Then the next randomly chosen square D2 has a bias to choose 1 as well, but not necessarily 1 is chosen. That too failed.<BR/><BR/>Finally, I tried to limit a number to one 3-column in the same 3-row or 3-row in the same 3-column. E.g. Suppose A1 has 1, then D1-D3, G1-G3, A4-C4 and A7-C7 will not have a 1. This failed as well.<BR/><BR/>I'm thinking of back-tracking but haven't implemented it. Designing Sudoku seems to be difficult as I haven't come across any 'rules' on its design. I'm trying to think thru this on my own but am stumped. <BR/><BR/>Any suggestions are helpful. Thnx in advance.<BR/><BR/><BR/>SrynSrynhttps://www.blogger.com/profile/13285264238286095723noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-9883737629341098342007-06-12T05:59:00.000+05:302007-06-12T05:59:00.000+05:30The following is the list of all known problem sol...The following is the list of all known problem solving techniques, in order of decreasing effectiveness:<BR/>1) Knowing the solution to the problem<BR/>2) Knowing the solution to a similar/related problem<BR/>3) All other techniques.<BR/><BR/>Most of the current 'methodologies' fall under 3). They often don't help you in solving the problem at all.<BR/><BR/>As a corollary there are two kinds of engineering:<BR/><BR/>1) Orderly: In this kind, you know /understand the problem space. You r particular project may require some variation on the design that applies to this problem space. Eg:<BR/>building bridges, compiler for a new CPU.<BR/><BR/>2) Exploratory: You don't understand the problem space. Your attempts at a solution are unstructured.<BR/><BR/>Norvig obviously recognizes the problem as being part of two other well known problem classes. His attempt is very reminiscent of orderly engineering. <BR/><BR/>Jeffries is a textbook example of <BR/>exploratory engineering.<BR/><BR/>This is what pisses me off the methodology-hype train: Almost every body claims to have a panacea(UNIVERSAL MEDICINE). Ultimately, they don't apply to any problem space well.<BR/><BR/>I find it sad that so many developers unquestionably accept the latest FAD. If we are to mature as an engineering discipline we need to spend time doing more taxonomy/analysis/theory into problem domains. Compiler construction, text processing, search are excellent examples. I know most of the enterprise software business is supposed to arbitrary, ill-defined etc., but there is very little attempt to codify/internalize various domains from an IT/non-IT perspective.<BR/><BR/>Even design patterns, that SACRED COW is more about the solution space than the problem space.<BR/><BR/>As far as I know, Michael Jackson(the software guy, not the singer)'s work has always emphasized the problem:<BR/><BR/>JSP, JSP(Information systems problems of the classic, mainframe era)<BR/><BR/>Problem Frames - more recent, more modern.ananthdhttps://www.blogger.com/profile/04346108375443272176noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-7779206423598500502007-05-10T10:36:00.000+05:302007-05-10T10:36:00.000+05:30@Simon,I keep a fairly "open" blog and I don't wan...@Simon,<BR/>I keep a fairly "open" blog and I don't wantt o edit what people say as long as tehy are sincere. So , yes some of those comments can indeed look like "attacking". That is fine by me. I am a big believer in the clash of ideas and the regular slaughter of sacred cows.<BR/><BR/>"I think development should very much be test DRIVEN. Design, on the other hand, should not be."<BR/><BR/>fwiw this is totally consonant with my experience.This is how I (try to) develop these days. Of course the future may show me a better way.Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-36313999767385500002007-05-10T10:26:00.000+05:302007-05-10T10:26:00.000+05:30@Ravi,I might be reacting to things that no one ev...@Ravi,<BR/><BR/>I might be reacting to things that no one ever said. But some of the comments up there are to the point of attacking a certain person and community. I don't those who wrote them have any respect to Agile or TDD.<BR/><BR/>I think development should very much be test DRIVEN. Design, on the other hand, should not be. From my understanding and experience, test driven simply means we write the tests before we write the implementation code. Through this practice, we make sure that we try our best not to write any useless code and not to miss any test scenario. Once again, test does not drive our design. We even list all the test cases we can think of at the time before we write any test.<BR/><BR/>I've never been to any extreme programming list. There are a lot of people out there who claim to be Agile but in fact have not a single clue what it is. But there ARE also the group people who understand and love Agile. Unfortunately, they usually don't like to talk too much.Simon Linhttps://www.blogger.com/profile/05349839120131016188noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-45432416197163833912007-05-10T10:15:00.000+05:302007-05-10T10:15:00.000+05:30@Simon,"But if you ask the majority of business ap...@Simon,<BR/><BR/>"But if you ask the majority of business application developers what kind of requirement they get, the answer will most likely be something like “Make it work”, “I can tell you. But don’t expect the same answer six months from now.” or “Requirement? We are not sure”. That’s the challenge the main audiences of TDD are facing. Whoever says you don’t need TDD in this kind of situation must be either a genius or insane. No, let me rephrase that. They are just insane."<BR/><BR/>Beat your wife much?<BR/><BR/>You are reacting to things no one ever said. No one, either in the original post or any of the comments, claimed that TDD is inappropriate for certain kinds of enterprise projects or that TDD is a "bad" tool , never to be used, or that Sudoku is typical of what a typical "business application developer" faces.<BR/>These issues are orthogonal to the point under discussion.<BR/><BR/>Besides, there is a subtle difference between having good coverage with unit tests and using unit tests to drive the design. The claim that the latter, TDD, "solves" unclear requirements is just that - a claim, by you in this case.<BR/><BR/>Good unit test coverage certainly helps the design to evolve by making refactoring safe. Whether development should be test DRIVEN is a more subtle question.<BR/><BR/><BR/><BR/>As to Ron Jeffries being a bad example, good point. You might want to try saying this on the extreme programming list :-).<BR/><BR/>What does it say about the state of the agile "movement" if he is a "guru"?<BR/>:-)Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-15959698060468732242007-05-10T03:01:00.000+05:302007-05-10T03:01:00.000+05:30After reading all the comments, I have to say that...After reading all the comments, I have to say that it’s a stupid discussion. I have at least two reasons.<BR/><BR/>First, Sudoku is not the appropriate topic to base the comparison on. It’s the kind of problem that requires relatively complex algorithm but has well defined requirement. In this case, the requirement is: Solve the Sudoku. But if you ask the majority of business application developers what kind of requirement they get, the answer will most likely be something like “Make it work”, “I can tell you. But don’t expect the same answer six months from now.” or “Requirement? We are not sure”. That’s the challenge the main audiences of TDD are facing. Whoever says you don’t need TDD in this kind of situation must be either a genius or insane. No, let me rephrase that. They are just insane.<BR/><BR/>Second, Ron Jeffries’s example is terrible. He seems like the perfect guy to reference if you want to badmouth Agile and TDD. He made it sound as if TDD eliminates the need for upfront design. That’s not what we do! Brainstorm/design sessions happen a lot more often in an Agile team than in a traditional development team. TDD is there to insure that we don’t write unnecessary code and all the code we write are covered by tests. These tests are usually white box tests. We already know how we want to implement it. We just want to make sure it works and continues to work over time. There are, however, times when we have to write black box tests. That’s when we were given a chunk of legacy code that nobody knows how it’s supposed to work. We have no choice but to gather the up-to-date requirements, write test to demonstrate them and refactor/rewrite the legacy code to be readable and working.<BR/><BR/>That’s my take on this debate. Ron Jeffries is not a good representative of Agile. There are better guys out there.Simon Linhttps://www.blogger.com/profile/05349839120131016188noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-71116541406877563122007-04-29T08:10:00.000+05:302007-04-29T08:10:00.000+05:30@uncle bob (and I really hope you are not *the* un...@uncle bob (and I really hope you are not *the* uncle bob)<BR/><BR/>The Master and his gaggle<BR/>--------------------------<BR/>An old master goes on stage, demonstrating how to walk a tight rope. He fails, fails, fails, fails and fails... even with a balancing rod. Then he gives up and starts rotating his wrists, hoping desperately no one will ask him why he failed.<BR/><BR/>Another old master traipses across the same rope whistling "Waltzing Mathilda" and juggling 7 firesticks doing a few somersaults with very few steps and landing perfectly on the swaying rope. <BR/><BR/>The former old master can keep rotating his wrists oblivious of other Masters around him.<BR/><BR/>The gaggle, like all gaggles can close their eyes or choose to <B>learn</B>.Dibs on Muadhttps://www.blogger.com/profile/04506593706578740072noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-30188705778929361332007-04-28T16:15:00.000+05:302007-04-28T16:15:00.000+05:30" ...addled old men rotating their wrists, who pre..." ...addled old men rotating their wrists, who pretend to be Karate masters and even run dojos and have many disciples, but crawl home, dragging their broken legs behind them and spitting blood after meeting some real fighters...."<BR/><BR/><BR/>BWAAAAA HA HA HA HA HA HA HAAAAAAAAAA!!!<BR/><BR/>I've never seen a truer description of these "agile alliance" idiots! They should stick to "process consulting".<BR/><BR/>That was REALLY funny!<BR/><BR/>Good work dude!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14853042.post-30024371544684627622007-04-28T13:10:00.000+05:302007-04-28T13:10:00.000+05:30I met Ron in person. He might look like an idiot,...I met Ron in person. He might look like an idiot, and even talk like and idiot, but make no mistake about it: he is an idiot.<BR/><BR/>What I think is the most dangerous facet of TDD and Agile/Scrum is that it lulls people into the false belief that even if they are morons, they can still write good code because they follow the "correct process".<BR/><BR/>I have seen some morons at my work that write tests to test the tests that tests their tests in some hope that Goedels' theorem will go away. I agree that the opposite (no process, no test units) is hell. But here's the thing: test harnesses are to software like scaffoldind to building. If you are inclined to read about how Brunelleschi went to overcome obstacles, you may see that there is value in props. But only if you are good, to begin with.<BR/><BR/>Ron Jeffries (and it applies to his retared followers as well) is just an old fart with no talent for programming whatsoever. Blindly following Jeffries puts one in my "fire tomorrow, if I can" book. I can afford to say it. I wrote my own C++ debugger for Linux, and oh my, I did not use agile, nor TDD (but I do have a suite of automated tests that saved my bacon more than once).<BR/><BR/>And I am just super-lucky to have bosses in my day job that have a sixth sense for the kind of bullshit that the agile crowd is pushing, and have been able to steer clear of the Ron Jeffries putrid "charisma" so far.<BR/><BR/>I am with you man, thanks for posting.Cristachehttps://www.blogger.com/profile/08287129746971472910noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-9790555935968782092007-04-28T09:30:00.000+05:302007-04-28T09:30:00.000+05:30"With equals conditions, I bet that the TDD teams ..."With equals conditions, I bet that the TDD teams will be closer to the solution than the other"<BR/><BR/><BR/>Josue, here "I bet" === "I believe".<BR/>Believing is one thing. Lots of people "believe" in TDD. Showing belief to be valid is another, which is what this whole discussion is about.<BR/><BR/>Anyway thank you for your comment.Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-16432973290770136402007-04-28T08:48:00.000+05:302007-04-28T08:48:00.000+05:30May be I am wrong, but I think Ron showed his proc...May be I am wrong, but I think Ron showed his process from the very beginning (without any deep studying of the domain problem ). It seems to me that Norvig show only the solution, not all the mistakes he did in the way.<BR/><BR/>In my opinion, the Soduku is the kind of problem where a deep knowledge of the domain (complex math) is more important than the methodology (TDD) utilized to solve the problem. But, in real life , how many times did we found problems like that in normal development? As an equivalent, how many times we use assembler in the place of OO?<BR/><BR/>One mistake that happens with people is to think that there is silver bullets and only one thing must resolve all cases. The only silver bullet I know is to be good to go to heaven ( I hope :) ). As any other kind of thing, TDD is not silver bullet. But in my opinion, it is very very very very good. An analogy, OO is good? Well, I think so. But there is cases that we can´t not apply it (example, optimized calculus do graphical devices, where we will need the assembler help ).<BR/><BR/>If in the soduku example one reached the solution and other no, it proves nothing about the TDD process. If we want to test TDD, we have to experiment development with various teams, ones using TDD and other no, and try to isolate the other variables( the teams with more or less the same skill to develop, the same knowledge of the problem domain , the same number of members, the same schedule, the same language etc.). Of course isolate the influence variables is not easy. But a large amount of experiments could show some tendency.<BR/><BR/>With equals conditions, I bet that the TDD teams will be closer to the solution than the other. And I am speaking as someone who one day did not used TDD and nowadays is using.<BR/><BR/>By coincidence, in my graduate work I am doing a summary about papers that does this kind of study, and the only variable that was worst to TDD was the time of development in one case. In that one TDD takes 16% time longer (but the TDD team will have tests to the biggest phase of software: maintenance. And the other no). In compensation there is another study were TDD was 50% faster. There is one case where the only team that complete all the requirements requested was the TDD team. Of course, it proves nothing but with time and with more experiments we could have a good idea about the practice.<BR/><BR/>Well, personally I don´t need of any prove because I know how good developer I was before TDD and how good I am now with it.Josuéhttps://www.blogger.com/profile/12032070162411555574noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-54084069836270363072007-04-28T05:00:00.000+05:302007-04-28T05:00:00.000+05:30Argument by analogy?:-)Sadly enough all old men ar...Argument by analogy?<BR/>:-)<BR/><BR/>Sadly enough all old men are not masters of anything.<BR/><BR/>Some addled old men are just addled old men.<BR/><BR/>Worse are addled old men rotating their wrists who pretend to be Karate masters and even run dojos and have many disciples, but crawl home, dragging their broken legs behind them spitting blood after meeting some real fighters.<BR/><BR/>Withered ancients trying to pretend a mastery they don't have and desperately hoping that passersby will notice their wrist rolling and conclude it is some mystic fighting move are pathetic.<BR/><BR/>Grey Hair by itself is not a badge of merit.<BR/><BR/>Especially as in this case, when the code (or karate move) is out there for everyone (including the young black belts and the gaggle) to see (and judge).<BR/><BR/>Nice try though ;-).Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-70010643575953038992007-04-28T04:37:00.000+05:302007-04-28T04:37:00.000+05:30The old master sat in the corner rotating his wris...The old master sat in the corner rotating his wrist back and forth, back and forth. His concentration was total. He seemed oblivious to the world around him.<BR/><BR/>A young black-belt, the kind that think they actually know something, sneered as he talked with his compatriots. "The addled old fool. Why does he move his wrists so." The gaggle laughed discretely and rolled their eyes knowingly.uncle bobhttps://www.blogger.com/profile/02636068738657244865noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-80106413966216051442007-04-27T22:15:00.000+05:302007-04-27T22:15:00.000+05:30"His main claim is that TDD helps him create worki..."His main claim is that TDD helps him create working programs, and it does."<BR/><BR/>For some value of "working" yes. The question is whether that is good enough. The answer as demonstrated by his code (and his TDD driven thought process) is plainly no.<BR/><BR/>Then there is the question about a self acknowledged bad programmer (which he is if "Jeffries doesn't claim to be a great programmer; in fact he claims the opposite" is true) evangelizing a programming methodology, but we won't get into that. It is a free world.<BR/><BR/>The claim that TDD allows the design to "fall out" of the test_code_refactor_repeat cycle is what is being questioned here.<BR/><BR/>"The sudoku challenge is kind of an extreme case showing where the limits of TDD are"<BR/><BR/>Correct. But sudoku is "extreme" only wrt TDD as a design technique. Algorithmically it is only a moderately complex problem. The key is that it illustrates perfectly how limited a tool TDD is(as you correctly point out).<BR/><BR/>"Norvig ... employed a tool (backtracking search) which Jeffries probably didn't know well."<BR/><BR/>Again the tools Norvig employs are less important than the calibre of his thinking. He explicitly uses analytical,algorithmic, mathematical **thinking** while Ron stumbles around with his "TDD". It is not as simple as knowing or not knowing a particular tool.<BR/><BR/>"I suggest people analyze the problem at a high level to find a strategy, then use TDD to implement that strategy."<BR/><BR/>Excellent advice, as long as it is clear that you can create elegant, powerful programs can be created without TDD,as Norvig demonstrates. The value TDD adds *in this context* is fairly marginal.<BR/><BR/>But yes, deep analysis + tdd is a possible path.Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-62972281842970672972007-04-27T21:46:00.000+05:302007-04-27T21:46:00.000+05:30Jeffries doesn't claim to be a great programmer; i...Jeffries doesn't claim to be a great programmer; in fact he claims the opposite. His main claim is that TDD helps him create working programs, and it does. The sudoku challenge is kind of an extreme case showing where the limits of TDD are.<BR/><BR/>Meanwhile, Norvig is an expert in sudoku type problems, and he employed a tool (backtracking search) which Jeffries probably didn't know well. If he had, he could have used TDD and come up with an elegant solution.<BR/><BR/>I suggest people analyze the problem at a high level to find a strategy, then use TDD to implement that strategy.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14853042.post-16458025581394882992007-04-26T02:10:00.000+05:302007-04-26T02:10:00.000+05:30@joesomeone said "It's like comparing guitars b...@joe<BR/><BR/>someone said<BR/><BR/> "It's like comparing guitars by making Jimi Hendrix play one, and the teen next door the other. The comparison is in fact interesting, but the conclusions are all wrong."<BR/><BR/>and you (joe) said<BR/><BR/> And does your teen next door also go around claiming to a be a guitar God? Does he write books on guitar playing and presume to tell other guitar players how to play? Does he have a "guitar playing method"?<BR/><BR/><BR/>BWAAA HA HA HA HA HA HA HAHAA!!!!!<BR/><BR/>ROTFLMAO!!!<BR/><BR/>joe, that was excellent!!!!!!<BR/><BR/> >At least Ron Jeffries came up with a working solution, not being a mathematical oracle or anything like that.<BR/><BR/> he did? As far as i can see he stopped halfway and wandered off into programming shotgun images or something equally crappy, all the while proclaiming the superiority of agile/tdd? <BR/><BR/><BR/><BR/>BWAAAAAA HA HA HAHA HAAAAAA!!!!<BR/><BR/>Made my day! Thanks!! <BR/>(Tears of mirth ...)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14853042.post-82219083325675992312007-04-26T01:44:00.000+05:302007-04-26T01:44:00.000+05:30I think http://devgrind.com/2007/04/25/how-to-not-...I think http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ makes the right point that TDD is not the right tool for the job trying to develop an algorithm. You can also read my reply on my own blog, which is longer but makes the same point! :)Nestedhttps://www.blogger.com/profile/09680919094932667147noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-32520481602352338792007-04-26T01:07:00.000+05:302007-04-26T01:07:00.000+05:30Lucio Torre's comment "I think that the main diffe...Lucio Torre's comment <I>"I think that the main difference is that Norvig already *knew* how to solve it"</I> is spot on.<BR/><BR/>Others have noted that Ron exposes his thought processes whereas Peter's writing is like a textbook excerpt. I wouldn't be surprised if Peter's actual thought process was quite close to that textbook-like presentation, given that he has written textbooks in which he applies the same techniques to similar problems.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14853042.post-90498117696579729752007-04-26T00:12:00.000+05:302007-04-26T00:12:00.000+05:30@keithb"Peter's thought process moves implacably f...@keithb<BR/>"Peter's thought process moves implacably from analysis to design to code[...]" Well, the account we have here makes it look as if that's what happened. But did it really?"<BR/><BR/>I havent been inside Norvigs head to be sure about this, but im not surprised if he really did it in that way. First, its clear that soduku is a constraint propagation problem. Then, you realize that sometimes the constraints made by the numbers placed are not enough for a solution, so you apply search.<BR/><BR/>For a guy who is famous for a book that makes all AI problems look like search, that does not sound so strange.<BR/><BR/>When he reaches the search phase, he considers implementing strategies, but concludes that search will work beucase:<BR/>- the space is not so big<BR/>- search is complete, while strategies may not be, so its easier.<BR/><BR/>This questions are of second nature to someone who implements search algoritms.<BR/><BR/>I think that the main difference is that Norvig already *knew* how to solve it.<BR/><BR/>LucioUnknownhttps://www.blogger.com/profile/06517210906961030426noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-74829330515740064832007-04-25T22:46:00.000+05:302007-04-25T22:46:00.000+05:30Real Programmers - No Bullshit, No Process, Simple...Real Programmers - No Bullshit, No Process, Simple Beautiful Code, No big deal...<BR/><BR/>Crappy Programmers - Total Bullshit, Only Processes, Complex Crappy Code, Would put it on the front page if he could...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14853042.post-89669295383126867982007-04-25T22:39:00.000+05:302007-04-25T22:39:00.000+05:30If you read the agile manifesto you'll find it is ...If you read the agile manifesto you'll find it is all about the process of capturing requirements and turning them into software. I don't think that it really has much to say about algorithm development, but all of software engineering is not necessarily algorithm development. One can easily imagine that a person tasked with improving the performance of a relational database would find almost nothing of value in the agile approach. Conversely, someone focused on building business-case driven CRUD web apps will find nothing of value in a textbook about algorithms or AI techniques. That doesn't mean that one set of techniques or the other are valueless, just that they are not universally applicable.Paul Prescodhttps://www.blogger.com/profile/15412258048017521995noreply@blogger.comtag:blogger.com,1999:blog-14853042.post-54515628633604242902007-04-25T22:06:00.000+05:302007-04-25T22:06:00.000+05:30"It's like comparing guitars by making Jimi Hendri..."It's like comparing guitars by making Jimi Hendrix play one, and the teen next door the other. The comparison is in fact interesting, but the conclusions are all wrong."<BR/><BR/>If you notice Ravi doesn't conclude very much. he just says "look at X. look at Y .learn"<BR/><BR/> You use a good analogy though. And does your teen next door also go around claiming to a be a guitar God? Does he write books on guitar playing and presume to tell other guitar players how to play? Does he have a "guitar playing method"? <BR/><BR/><BR/><BR/><BR/> >At least Ron Jeffries came up with a working solution, not being a mathematical oracle or anything like that. <BR/><BR/>he did? As far as i can see he stopped halfway and wandered off into programming shotgun images or something equally crappy, all the while proclaiming the superiority of agile/tdd? <BR/><BR/>>Only a narrow amount of mathematically-gifted people will be able to solve problems in a way Norvig does, the ordinary ones may benefit more from a step-by-step approach used by Jeffries - assuming they're working all on their own, not copying or "translating" the solution.<BR/><BR/>Irrelevant. Since Ron never finished the problem. Holding Ron up as some kind of example to follow is a very --- weak.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14853042.post-2079276006196232352007-04-25T21:57:00.000+05:302007-04-25T21:57:00.000+05:30It's like comparing guitars by making Jimi Hendrix...It's like comparing guitars by making Jimi Hendrix play one, and the teen next door the other. The comparison is in fact interesting, but the conclusions are all wrong.<BR/><BR/>Also, try to write a sudoku solver yourself without reading too much on the net. At least Ron Jeffries came up with a working solution, not being a mathematical oracle or anything like that. Only a narrow amount of mathematically-gifted people will be able to solve problems in a way Norvig does, the ordinary ones may benefit more from a step-by-step approach used by Jeffries - assuming they're working all on their own, not copying or "translating" the solution.<BR/><BR/>Obviously Peter Norvig is the clear winner here, but it is not as black-and-white as you seem to put it.Anonymousnoreply@blogger.com