On 2013-08-01, CM <cmpyt...@gmail.com> wrote: > http://en.wikipedia.org/wiki/Programming_by_permutation > > It seems that if I can make a change to the code and then > immediately test it by running the Python interpreter and > finding out, in a few seconds, if it worked, I am going to be > *much* more likely to use this trial-and-error approach than if > I had to use a compiled language, since compiling takes so > long. E.g. "Oh, that doesn't work? Maybe if I add this...no. > OK, what about if I increment that? No...OK, wait, maybe > this...AH! That worked." (obviously it is not quite that > uninformed all the time). > > Instead, with a compiled language, because of the pain of > having to wait for the newest version to compile, one would be > encouraged to get the mechanism of how something works *clear* > and robustly represented in one's mind (or on scrap paper/notes > document) prior to testing through compiling and running.
With a big project running all tests for a Python program could be just as time consuming. If I were using a compiler for my programs compiling would still be virtually instantaneous. > I'm sick of this in my own work, and want to avoid this trap as > much as I can from now on. When I "know", for example. that it's an off-by-one error, I'm pretty guilty of just making the change and re-running the test. I think it's cool! If my test sucks, then I wasted my time, of course. As I said, I disagree that the speed of using an interpreter is the main issue. Changing certain things, even big things, in a Python program is often much easier than changing something in , say, a C program, due to Duck-Typing and dynamic typing. So experimentation is easier thanks to more maleable code. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
