Don't you hate it when you write a whole bunch of code without compiling or running it at intermediate steps, usually because it's a big thing that really doesn't do anything unless it's complete? For example, an involved recursive algorithm, where unless all the parts are integrated correctly, and data is returned correctly at each invocation, you don't get anything at the end 
So now I'm about to hit compile and watch everything blow up at me, and I'm about to go through that inevitable frustration where after a while you think it's working, and then you find yet another bug.
Paul Graham, however, thinks this is the most natural way to program. He doesn't mind at all:
For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.
I like debugging: it's the one time that hacking is as straightforward as people think it is. You have a totally constrained problem, and all you have to do is solve it. Your program is supposed to do x. Instead it does y. Where does it go wrong? You know you're going to win in the end. It's as relaxing as painting a wall.
I really like his philosophy... "you know you're going to win", therefore it should be relaxing.
PyMeld looks like neat stuff. Via Stuart.
A simple, lightweight system for manipulating HTML (and XML, informally) using a Pythonic object model.
A PyMeld.Meld object represents an XML document, or a piece of one. All the elements in a document with id=name attributes are made available by a Meld object as object.name. The attributes of elements are available in the same way.
Check out the examples to really get a handle on what this allows you to do.
It probably makes me a bad programmer, but I still don't get unit tests. I get what they do, of course, but I haven't integrated it into my development. I mean, for something that crunches numbers (and probably doesn't change program state!), it's really easy to write something that verifies the answer. Either write a different algorithm and make sure the result is the same, or check the inverse of the function (assuming that makes sense) against the input (for instance, you can test that square(sqrt(x)) == x).
But for stuff that makes network connections, messes with the database, deletes files, etc. it seems less straightforward. How do you write unit testing for a parser, which is what I've been working on for the past day or two?
Anyway, John Lim came across Simple_Test for PHP. It has a lot of examples, and since I tend to use PHP a lot, maybe it'll help me get into unit testing.
Man, now I can write about this stuff in my wiki rather than dumping crap here people probably don't care about. Plus, when I post stuff containing long URLs, it usually breaks my layout! So, bonus.
Great thing about the wiki, too, is that the content of that page can be kept current, rather than having to make a new stinking weblog post every time I have further thoughts.
Friday, May 9, 2003
Permalink
Girls, please don't get breast implants
sorry but another thing i have tomake a comment on about youmen...the men...
happynow: Nov 17, 11:36pm