On Thu, Dec 18, 2014 at 8:09 PM, Brandon Dorsey <brandon...@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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor