Does Python 'enable' poke and hope programming?

Neil Cerutti neilc at norwich.edu
Thu Aug 1 14:08:23 EDT 2013


On 2013-08-01, CM <cmpython at 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



More information about the Python-list mailing list