[Tutor] Learning to program, not code. [LONG RESPONSE!]

[boB Stepp]

On Thu, Dec 18, 2014 at 8:09 PM, Brandon Dorsey <brandontdr at gmail.com> wrote:
>
> Hello All,
>
> Programming has always been a passion of mine, however, I'm frequently
> frustrated at
>
> simple fact that I've been learning python for 8 months, and I have yet to
> start, and finish, a simple
>
> project.  I find difficult to not only visualize the execution, but to
> figure out when and where to
>
> use data structure 'x'.    Any suggestions on how to approach programming
> from a different angle?

I am going to take a stab at this. Perhaps the perspective from a
non-professional in the world of computer programming might be of
help. Like you I have had an ongoing fascination with computers and
programming ever since I encountered punch cards, FORTRAN and an IBM
mainframe in a computer science 101-like course in 1975. Ever since
I've from time to time had encounters with programming, that have
become more prevalent of late.

Perhaps it might be helpful to view programming more simply as
computer-aided problem solving, even though, at times, the computer
seems to be a major stumbling block if not the outright problem
itself. Thinking about it this way means that whatever techniques you
know that have proven fruitful for  solving other intellectual
problems should be useful for programming conundrums as well.

A major starting point is to make sure you understand the problem you
are trying to tackle, or, at least have a useful overall appreciation
of the task before you. As the problems get more challenging, your
initial understanding may not be as deep as you would like, but you
need to know enough to at least make some sort of start.

Next, make sure the problem you chose is likely to be solvable in the
domain you choose to approach it. An example of what I mean is that
sending all of your program's output to a textual command line
interface may not prove very fruitful if you are trying to write a
graphical dungeons and dragon game. However, even here there might be
possibilities. Some people use to do very interesting ASCII art and
graphical like images with those non-alphanumeric ASCII characters.
But more than likely you will not be pleased (at least nowadays)
creating a final product that runs in the command line. But note that
you could fully develop the logic of the adventure itself in this
environment and once you had that done, design the GUI/graphical/audio
elements.

Next, when initially approaching the design of the program, don't get
hung up on details! When I used to teach math and physics classes,
even at the university level students would get so hung up on the
details of the problem as stated, that they could not see the
underlying important principles necessary for the problem's solution.
Word problems of any kind is a classic example of this. I could window
dress up problems that are all solvable using the simple formula
distance equals speed multiplied by time, and students would get so
confused by the details of the window dressing that they could not see
that problems one through a gazillion and one were all solved using
this same underlying formula.

I think a similar thing happens with learning a programming language
and the programming process. Especially in the area of technical
vocabulary. Instead of focusing on what program statements, functions,
whatever actually DO and cannot do, the student is awash in a sea of
technical verbosity. Computer science people, in my personal
experience, often have a difficult time saying things SIMPLY. When I
was in college I mostly hung out with computer science types, and they
were forever speaking in technical acronyms, technical slang, ..., and
sometimes even technical profanity! But even though such things as
subroutines, functions, methods, and perhaps other names may be
precisely defined in somewhat different ways (and even might mean
different things to a greater or lesser extent in different
programming languages), what they all DO is usually quite similar.

Perhaps more importantly when tackling a challenging problem it is
easy to get lost in thinking about implementation details that you
will have to eventually worry about. But save that sort of worry for
later. I like to brainstorm on paper what my expectations are for a
program, the overall functionality, what might be "nice" to do, what
should be essential to do, ...  I try to decompose the overall problem
into obvious subunits and might even break these down as well. Then I
consider what I already know how to do and how it relates to my
brainstorming.

An example from circa 1977: I was recently introduced to backgammon
and was trying to get as good as possible at it. At the same time I
found out about a new room in the computer science building called the
software lab. I got permission to hang out there and noticed that they
had a relatively new minicomputer that had an experimental monitor
hooked up to it. Bear in mind that the most advanced visual display
interaction I had had to date was with an IBM Selectric typewriter
that was hooked up to a mainframe. You could type in your commands and
the mainframe's response would type out on paper before your eyes. But
this was even better! A large CRT that supposed had the ability to
display free-form graphical images, albeit only in a single color. No
one really knew how to use it to generate graphics, but it had a
manual. After glancing through the manual I thought I would try to
write a backgammon program. I felt sure I could display a suitable
monocolor 2D backgammon board once I learned how to programmatically
access the full functions of the monitor, but that was mostly studying
the manual. However, I did not know how to make the program logic that
would make the computer play a strong game of backgammon. So I delayed
that part and started in on what I had an idea of how to do. Later,
after reading plenty of backgammon books, I started to have ideas of
how to do the actual game logic, especially some mathematically based
ideas on proper use of the doubling cube. In the end I had a program
that would consistently beat most of the people that played it.
Disclaimer: Most of these people were poor backgammon players! So
tackle that which you have some idea on how to proceed first.

In general, when the going gets rough, work on the stuff you see a way
of tackling and temporarily skip the stuff that has you scratching
your head. Or if you are really stuck, work on a piece of a piece (...
of a piece). For instance if you are working on something that will
require a randomizer or some sort, work on that and expand on that
seed as much as possible. Find another little piece. Solve that
problem. As you do this you will often find that the stuff you learned
from doing the small pieces gives you ideas for approaching the true
head scratchers. And as you get more and more pieces solved, ways of
assembling them into bigger parts of the developing program will occur
to you.

Some other ideas on approaching the small pieces: Say you know you
will have to repeatedly do something. That should immediately suggest
to you that you will need some type of looping or iteration structure
even if you have, at this point, never heard of a while, for or
whatever loop. Once you realize this need, investigate your chosen
programming language to see if they have something similar to what you
realize you need. Or you realize you need some way to retain the
game's settings between playing sessions. That means you need to
somehow store things in files. Ergo, read up on files! Even if you
have no clue what you actually need to write to permanent storage, go
ahead and design simple functions to read and write files. As you do
this you will probably realize some little things that you can add to
these functions that reflect what the game is shaping up to be like.
And as you learn more about how to manipulate files, new pieces will
start falling into place for this portion of your program. Have to
make choices? Then what kind of structures does your language provide
for doing this? If-then-elif-else?

I don't know how you are, but I am like a dog gnawing on a bone until
I finally crack it, a little piece at a time, until I get to the
marrow.

If you are doing all of the above you will generate errors,
exceptions, whatever in profusion. Treat these as learning
opportunities to really dig into the meat, and, finally, DETAILS of
your chosen programming language. The smallest, itty bitty thing
MATTERS! Computers are so stupid. They try to do EXACTLY what you
type, however error ridden. As an example, yesterday I copied a
snippet of someone's code that had the potential to be helpful on my
current project at work. Even though I had what should have been a
fully functional code snippet that for the life of me I could not see
any reason why it shouldn't run, it continued to give me the same
error message that made absolutely no sense to me. It gave me a syntax
error at a pair of double quotes. But every time I typed in exactly
the same code manually into the interpreter, it ran. I was about to
pull out what remaining hair I had on top! Finally, I COPIED AND
PASTED the code snippet into the interpreter. It failed with exactly
the same error message! What the [insert profane word here]! I then
got real close to my monitor and really looked at those quotes. They
were pointing in slightly different directions! Once I replaced them
with my keyboard's normal double quotes the problem vanished.

So what to do when you can't eliminate the error message? First,
believe (mostly) what it says. I say mostly because it may not
pinpoint the actual location of the error. For instance you may have
forgotten to close quotes, parentheses, etc. somewhere earlier in your
code and the checker may not realize the actual point of the error. As
many have said, try to isolate the location of the problem with
judiciously inserted print statements. Print out whatever variable
values that might help you understand what is going on. Comment out
areas of code and see if you can isolate it that way. Maybe even get a
non-programmer to read your code for obvious typos that you just are
not seeing. You know, like in English class when you just cannot see
the misspelled word?

Don't forget the more insidious logic errors. If you understand what
you are trying to do, then you should know what you should get for
various inputs, situations, etc. Test these expectations!

Finally (I am finally getting tired of typing! And supper is done!!)
when you think you have it done and working, examine your ASSUMPTIONS.
What if the user does something different from what you intended? What
if that file you are expecting isn't actually there? Etc.

I hope I did not waste your time with this long post. As I said, my
programming skills are quite modest. But this is how I try to approach
things.

Keep at it! Persistence wins out in the end!1

Cheers!
boB