Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Sat, 3 Aug 2013 07:49:39 -0500 (CDT)
From: Wayne Werner <wayne@waynewerner.com>
To: CM <cmpython@gmail.com>
Subject: Re: Does Python 'enable' poke and hope programming?
In-Reply-To: <6b1769f8-222b-4953-99c8-a1d73cec3d60@googlegroups.com>
References: <6b1769f8-222b-4953-99c8-a1d73cec3d60@googlegroups.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1146322715-1375534179=:2301"
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.153.1375534210.1251.python-list@python.org>
Lines: 157
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:51856

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1146322715-1375534179=:2301
Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 1 Aug 2013, CM wrote:

> (My subject line is meant to be tongue and cheek inflammatory)
>
> I've been thinking about why programming for me often feels like ice skating uphill.  I think part of the problem, maybe the biggest part, is what now strikes me as a Very Bad Habit, which is "poke and hope" (trial and error) programming (of several names this page provided, I kind of like that one):
>
> 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.
>
> Basically this amounts to:  with an interpreted language (so of course this is not really just about Python--I just think in terms of Python), it's easier to be mentally lazy.  But, ironically, being lazy winds up creating *way* more work ultimately, since one winds up programming in this terribly inefficient way, and progress proceeds at an, at times, evolutionary (slow!) pace.
>
> And of course I am not really blaming it on Python or any interpreted language; I am blaming it fully on my own lame habits and attitude.
>
> I'm sick of this in my own work, and want to avoid this trap as much as I can from now on.
>
> Thoughts?


I see that many others have had thoughts already - but rather than take the
time to read their responses and either find out that they said the same thing
(oops, sorry!) or become influenced by their arguments, I feel like I should
respond to this with a clean slate.


I don't think that Python enables the "poke and hope" style programming (I like
the name!) any more than a compiled language does - if you're doing it right.

Example: My brother had a kid in his C++ class that would go about randomly
flipping >, <, <=, >= signs until he got the behavior that he wanted. There was
no mental effort of thinking about the problem or applying the scientific
method - i.e. form a hypothesis, test the hypothesis, check results. My
experience is that people who go throughout their programming careers without
this attitude will do it whether it requires several seconds (or minutes) of
compile time or not. Whether or not it's a conscious choice I don't know - at
least in your case you seem to desire to make a conscious choice in the
direction of "wait a minute, this is a stupid way to program".

Though "poke and hope" is headed in the right direction, I think it's a bit
naive and misses the very essential nature of the better (best?) method -
formulation of a /real/ hypothesis. For instance "I think my program will work"
is a hypothesis of exactly the same quality of, "When I turn on my water
faucet, it will rain." Of course the smaller the application, the more valid
the original hypothesis. For instance, the "poke and hope" programmer might
write this program:

      x = 3
      if x > 3:
          print "x is less than 3"
      else:
          print "x is greater than 3"

And then of course make the weak hypothesis "if I change my > to < then maybe
my program will work" - or "if I change my x to 5 then maybe my program will
work".


The problem is that these are really just random guesses - flips of the coin
that eventually might produce a correct result - but only because of the
monkeys[1].

What you really want is to actually understand cause and effect at a more
fundamental level (in programming) than what you may currently enjoy. And this
is in fact something that, while makes it easier for the "poke and hope", also
provides a much more enjoyable laboratory experience for the initiated. And
when you combine that with the REPL (interactive interpreter) you get an
embarassingly powerful laboratory in which to experiment to your heart's
delight.

For instance, say you want to really understand the previous example. You could
do something like so:

     >>> x = 3
     >>> x > 3
     False
     >>> x < 3
     False
     >>> x >= 3
     True
     >>> x <= 3
     True
     >>> x == 3
     True


And *this* type of "poke and hope" *is* actually valuable. This is where
understanding is formed, and high-quality developers are forged. At your
fingertips you begin to see "A hah! so *that's what this does!" You are free to
explore and play and understand the rules of the system. And you can build on
the previous experiments:


     >>> if x > 3:
     ...  print("Hello?")   #single space indentation for the interpeter
     ...
     >>> if True:
     ...  print('True?')
     ...
     True?
     >>> x = 5
     >>> if x > 3:
     ...  print('x > 3')
     ...
     x > 3
     >>> x = 2
     >>> if x < 3:
     ...  print('x < 3')
     x < 3


With this understanding you can then say something like, "If I write a program
that checks to see `if x < 3` then print 'x < 3', and `if x > 3` print 'x > 3'
and `if x == 3` then print out 'x is 3', that should do those things correctly"
- which you then test by writing the (again naive) program:


     x = 5
     if x > 3:
         print('x > 3')
     if x < 3:
         print('x < 3')
     if x == 3:
         print('x is 3!')


This is still not the ideal program - obviously you can use elif/else - but
the style of the program is beside the point. We really care about the thought
process that went into (ultimately) developing the correct solution.
Experimentation is OK - that's how we learn. But we need to direct our
experiments and /use what we learned/ when formulating our hypothesis. when
this happens we evolve beyond the "poke and hope" into the inquisitive,
intelligent programmers that we all should be. Not merely fumbling around in
the dark, flailing for the correct answers, but finding a problem and apply our
understanding of the way the world (maybe just the digital world of 1's and
0's) works to create the solution. The solution that works[2].


At least that's my 2¢
-W

[1]: You know, the ones with typewriters.
[2]: Turns out there are several values for 'works'. If the computer is the
only one that sees it, then 'produces the correct solution' is the most
important. But if you have people coming 'round to 
change/update/extend/enhance, the obviously a system that's easier to maintain
is a worthwhile trade-off. After all, people are the more valuble resource -
computers just help us make better use of it.
--8323329-1146322715-1375534179=:2301--