Today on my way to PyOhio, the regional Saturday/Sunday Python miniconference in Columbus. Here's a page where you can view or download the program book I made for it as a PDF.

le_bebna_kamni knows Java really well, which has come in handy for tutoring, I can tell you.

However, she also has a copy of "Beginning Python From Novice To Professional" by Magnus Lie Hetland lying around. Since Python is the language I want to make actual real projects in, I was curious. So I decided to do my homework again, in Python. This time it was six lines long.

However, I decided to take it further. The new version properly uses singular and plural English. In other words, it will say "1 hour" instead of "1 hours."

( My Python script. )
So while I was doing this, she also did the exercise in Python, except she didn't want to type the singlular/plural decision into her version three times like I did. She felt it was more elegant to make one set of pluralization instructions and have Python repeat it for hours, minutes, and seconds. She cursed at the computer for a half hour and came up with the version she will post in the comments.

I do not curse at the computer. I expect coding to be painful, and have been pleasantly surprised to be proven wrong.

pain = False

if not pain:
    gain = False

I would like very much to know who responded anonymously to my post a year and a half ago about learning to program, with the advice I have copied below. Normally I ignore all anonymous posters, but this was a well-intentioned and unusually helpful comment, rather than a cowardly bad anonymous comment. Under the circumstances I would like to know who it is and follow up.

Flashcards aren't likely to help. Or rather, you'll make a little progress, but nowhere near as much as you would actually writing code.

It doesn't take long to get the syntax down when you are actually writing code. From the things you are saying, it sounds like you are just leaving it too long between sessions. Don't expect to go a couple of weeks and then pick it up again in five minutes. It can take time to get into the right frame of mind for coding, even for experienced developers, so don't give up just because it doesn't immediately come back to you.

Don't try to do too much too soon. The decision tree looks too complicated for a beginner. Write simple things, like asking for two numbers and adding them together, then counting the number of words in a text file, etc. Not only will you get to practice your syntax, but when you come back, you can look at the code you have already written to remind you of how things should look.

Once you've written a few little programs like this, you shouldn't really have any problem with syntax. Python syntax is quite regular. You'll still have to refer to the documentation all the time to check which modules/classes/functions to use, but that's no problem. You'll learn the ones that are most useful to you quickly and the rest you don't need to memorise anyway.

At this point, you're going to want to try to write your game again. It's still not time. What will happen is that you will make a little progress at a time, write a load of spaghetti code, and end up stuck, with a lot of confused code that you don't know how to untangle and no way of moving forward. You need to *grow into* writing larger programs.

Slowly expand your skillset, while writing slightly more complicated programs each time. Your skillset, like how to access databases, how to read and write files, how to talk over the network, etc, is like your vocabulary. It's comprised of knowledge of modules, and you don't usually have to learn new syntax or concepts to use them.

But architecture is a different matter. Learning how to write larger programs is something that you can't easily describe/teach/memorise, it's something you get with practice. As you get more experienced, you'll look back on your previous programs and realise that it's a confused mess that weaves all over the place, and now you can rewrite it to be smaller and much more organised.

Once you start figuring out architecture, you are more able to spot the warning signs that you are creating a mess, and look for a better approach. It's at this point that you are capable of writing a game and actually completing the project.

It sounds daunting, but it really isn't. It's a series of small steps, one after the other. Try to run too fast and you'll fall over, but take your time and be sure of your footing, and you'll go places.

Unlike eilrahc, I recommend Python over PHP. PHP isn't significantly easier, it's more complex and irregular in many ways, it gets you into bad habits, and it's a much worse language for complicated stuff. While Python is used by many professional programmers, it's also been taught to kids in educational settings.

And, for what it's worth, I've been a professional web developer for about nine years, wrote my first program almost twenty years ago, and have a lot of programming languages under my belt.

One last thing I forgot to mention: most people assume that computers are smarter than they actually are. You are likely to approach a large decision tree, get halfway down it and realise that there's no function you can call to make a decision because the computer is dumb and can't figure big stuff like that out. Go the other way. Write small bits that you know you can handle, and then join them up into a larger program that solves a bit more of the decision tree. This is "bottom up" programming. "Top down" programming has its advantages too, but programming beginners are much better off with bottom up.