From: Marnen Laibow-Koser Date: 2009-12-30T03:06:27+09:00 Subject: Re: Creating my own method for sorting an array Phillip Gawlowski wrote: > On 29.12.2009 18:32, Marnen Laibow-Koser wrote: >> Yup. It's more fun to program with good tests. You can go faster, and >> you can see things work right away. > > Hahahaha. No. > Tests are a safety net (and a rather thin one), that a beginner doesn't > need. I could not disagree with you more -- at least if we're talking about TDD-style tests. Writing tests first allows the beginner to reify his thinking about what he wants the program to do, and to know at once when he has got the program to do it. (Old-style a posteriori tests certainly aren't necessary for beginners.) > > It's a good habit to get into, yes. After a beginner knows what this > "programming" thing is, and thus can understand what tests are, and how > to write a good test. A *test* is another level of abstraction that a > beginner at programming doesn't need, and doesn't understand as yet. I don't think you're right. A beginning programmer has to explicitly break things down into bits to be able to develop them at all. It shouldn't be hard to write a rudimentary test for each bit as part of that process. Sure, this is unnecessary at the hello-world stage. But by the time you're writing something with the complexity of a recursive sort, I think it's a good idea. I know I'd have learned faster if I'd known about this technique sooner. > > And an improperly written test is worse than no test at all: It makes > you believe that your code is correct when it isn't. Of course. So can no test at all. > >> Anyway, if he's really a new programmer, he shouldn't be writing sort >> algorithms. > > Why not? It's the most basic algorithm there is, allow fancy-pants > things like recursion to be explored with (comparative) ease. There are better introductions to recursion. Look at any Lisp book for better ideas. > > >> I didn't say a word about design patterns. All I recommended was tests. >> These actually make it less confusing, since you can more clearly see >> what's going on. > > Tests *are* a design pattern. Not in the usual sense of that term. > >> And we'd all be better programmers if we thought about good practice as >> an integral part of the craft, not something bolted on later. > > Every apprentice, in any craft, learns the basics of a craft first, and > *then* moves on to the complex things. Good practice is basic. > > Would you expect a carpenter to be able to plan a table before s/he is > able to hold a drill properly? Perhaps. Conceptual ability to plan a design has nothing to do with physical skill to hold a drill. > >>> Yeah, the way I tell if I have a working program is (generally) to run >>> it. >> >> The tests run it for you. Have you ever actually tried this? Sounds >> like not. > > Tests don't run a program. OK, the test runner software runs the program. Split hairs if you like; my point stands. > They check if a part of a program, an atomic > piece, is correct as defined by the test. > Right. And that's something that is helpful for programmers at any level, from novice to Ward Cunningham. >> For "hello world", yes. For anything more complex, no. And a sort >> implementation is certainly complex. > > You don't need tests for something complex. Nor do you need them for > something "simple". You need them for something that requires > *correctness*. If a program is worth writing, it requires correctness. > >> I did give him some guidance. Now, since you brought it up...what >> guidance have *you* given him? > > Good guidance: Not to listen to know-it-alls unable to grasp what's > appropriate for a given situation and what isn't. Yup. The application of this maxim is left as an exercise. :) Best, -- Marnen Laibow-Koser http://www.marnen.org marnen@marnen.org -- Posted via http://www.ruby-forum.com/.