On 08/03/2013 10:30 AM, CM wrote:
But what I meant is that if one is writing a program, there is a way
to **know**--without experimentation--what a particular set of code
is going to do.
Even when you /know/, experimenting is still good for two other purposes:
- check that what you know i
On Sat, Aug 3, 2013 at 6:30 PM, CM wrote:
> In sum: experimentation is for when you don't know what you're doing and
> there is no manual; but, after the initial learning time, you *should* know
> what you're doing and you should have the manual handy, and therefore the
> time for experimentat
Wayne, thanks for your thoughts.
I am all for the scientific method--in understanding the natural world, which
doesn't come with a manual. But Python is an artificial system designed by
mere people (as well as Guido), and, as such, does have a manual. Ideally,
there should be very little ne
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 an
CM wrote:
> 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 programmin
I find myself doing this a lot with libraries whose documentation encourages an
understanding based on intuition, rather than one based on formal concepts.
When doing more 'pure' stuff with mostly the standard library, not so much.
Most imperative languages let their users get kind of loose wit
CM wrote:
> 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):
>
I recall when a "compile" took up to two days, before we got the punched
paper tape to begin testing. If we wante
On Thu, Aug 1, 2013 at 6:57 PM, CM wrote:
> 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 h
On 2013-08-01, CM 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 t
(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)
progra
10 matches
Mail list logo
