Skip navigation

Tag Archives: programming

I’ve been taking quite a long time to work on my current exercise in Learn Python the Hard Way – the assignment was to make a game in a week, and now it’s well over two weeks.

There are two perfectly good excuses and one somewhat dumb but awesome excuse.

The perfectly good excuse is that I’ve been feeling behind in my community college C++ class, so I decided to step up the amount of time I spend on it. It has paid off, as this evening I was confident enough to turn in a project a week early – there was simply nothing I could add to it (or take away, as Saint-Exupéry would say).

The second perfectly good excuse is that I am going to job interviews.

So, therefore, I am not behind on my Python project, because I am lazy.

I could be behind on it, however, because I’m trying to do too much – and that is the somewhat dumb but awesome reason: I am trying to do a lot in my life, including a lot with this program. I am not writing out the project according to Zed A. Shaw’s example – I’m designing a full-on Interactive Fiction Engine – or at least the rudiments of one. I have a full structure, that is. I don’t know if it would be portable for other OSes or helpful for other coders – but – the point is – I am making a fairly complicated game from scratch. Go me!

So while I did very little last week, I’ve been making a point of getting an hour in every day this week – beginning before dawn. Tomorrow I have a little extra time in the morning, so I will be doubling that.

So this game consists of two big chunks to design: the game engine (how it all works) and the game flow (how the story / objects / actions all fit together). I’ve designed it so they’re pretty distinct components, and I am almost finished with the engine (I can feel it!). So hopefully next week I will just be working on game flow and a few extra tweaks to make the game the beautiful thing I would like it to be (with such amazing features as an ascii art skull for the death screen).

I will probably have a little bit to say once the project is done, but, for the most part, this process is not opening up any existential quandaries in my mind: it’s coming together nicely, if a bit slowly for the reasons above.

Coding is fun.

So here is where I begin to report the little lessons I learn while studying to be a programmer.

This first post is not so fresh in my mind – I’m describing something I worked on roughly a month ago as an exercise in Zelle’s book. But my notes are pretty clear.

The project was pretty simple: choose a card game, design a program in python for playing it, use a simple gui (I used a modification of Tkinter supplied by Zelle), include a splash screen. It was an extensive practice in object-oriented design – so the point was to make good use of classes. (For those who don’t know, OOD is essentially writing chunks of code that can be recalled by a name so you can play around with sticking big chunks of code together like legos instead of writing line after line of the same little details over and over.)

And I did make good use of classes. With one big mistake.

So for those familiar with Blackjack, you have a few actions you can choose from each turn. Mostly, that’s going to be hitting (getting a new card) or standing (ending your turn). Most of blackjack consists of these two things. Because most of the game is these two things, I wrote the program around them. I thought about the other options for only a second. I only thought about doubling down, which is a special kind of hitting and standing that effects your wager, and nothing else. So, no problem.

Except there’s this other important aspect of the game: splitting. I thought I could just “cram it in” like doubling down. No need to spend too much time figuring it out.

This was the mistake. You see, splitting requires you to play with two hands (at least four cards). I had enough forsight to leave enough room in the gui for two hands. So that worked out. There is a minor problem there, because sometimes you can split a split hand (depending on house rules), which means I would need to set up for three hands. I decided it was not worth thinking about. This was just an exercise in a textbook, it needed to be very good, with a lot of effort put in, but not perfect. I decided this house would allow only one split. Fine.

The problem was in coding. It became a nightmare, figuring out how to redesign the program to get input from the user when it was a split. I won’t go into the details. I will say that I spent about 8 hours working on this, and at least 4 of them were trying to get splits to work.

What was the problem? I discounted splits because they are not normal. They occur maybe 5% of the time, at most. I made the mistake of thinking that, since this happened 5% of the time, it warranted 5% of my attention. It warranted more, and it got its attention with a vengeance.

How could I have done better? Spent time mapping out options and observing patterns. I thought that, since I understand blackjack pretty well, and I even coded a primitive version of the same thing a few weeks prior, I could just breeze through. What I didn’t realize was how object oriented programming requires you to step up your planning efforts. You need to spend the time figuring out just what is an object – just what are the essential components of the program – and exactly how everything fits together.

If I had planned this game out, taken the time to map everything in a flow chart or something similar, I would have realized that it would have been easier to make a “normal” hand a simpler version of a “split” hand than it was to make a “split” hand a more complicated version of a “normal” hand. I should have expanded my definition of what a hand is to include a split hand. What I was doing was kind of looking at a split hand as an afterthought – a particular tweaking of a normal hand – and therefore not worth thinking about too much until I got to it.

A more general definition of a hand, based on a more careful perspective, would have allowed me to include the shared characteristics of both normal and split hands, saving me the step of redesigning everything towards the end of the process and making the whole process faster and easier.

You’re probably detecting a kind of moral lesson out of this. And I think there definitely is one. In any situation, it’s better to accept all cases and account for them – whether its at home, in politics, in your day to day affairs of life – than it is to marginalize. If you want to see beauty and some kind of order in your life, you have to make sure you are making relevant distinctions. If not, you risk either rejecting something valuable or neglecting something significant.

See, programming has a lot to teach. More to come.

(Note: this review refers to the Second Edition of the book.)

Last July I decided to study computing in earnest, and I wanted to find a good textbook to serve as a good, solid introduction to the fundamentals of the science. But I wanted to also learn some practical skills while learning more abstract concepts. Google searches on the subject led me to the blog Programming Zen, whose author wrote an article about how to get into computing. He said that beginners should make their entry with the Python language, and that John Zelle’s book, Python Programming: An Introduction to Computer Science, was the best way to start.

I looked it up on amazon, read reader reviews, looked at a few pages and, after careful deliberation, decided it was a good choice. So I ordered it and began working through it. I’ve just finished it now, having taken a large, nearly two-month break in the middle. Accounting for that, I completed the text and its exercises in about 10 weeks, with considerable time spent (often more than 4 hours per day).

I’ve put a lot of time and effort into working through the course of the book, and so I have a lot of strong feelings about the book. There is a lot that is, frankly, quite brilliant and well done. Some things not so much, but, even then, there are some qualifications. In the end, I’d say it’s a wonderful production. It feels strange saying that, after all the frustration I’ve experienced at the hands of the text, but, a few days past it, I can really see how valuable it was. It really shines in comparison to other textbooks that I have gotten know since finishing Zelle’s.

But let’s get into the details, shall we?

1. The Name

Let’s get this out of the way. The name is problematic. Zelle states clearly in his introduction that this is not a book about Python; rather, it’s an introduction to basic concepts in computing, serving as an introductory course to computer science – using Python as an excellent way to start. Zelle is essentially using the fluidity of Python as a playground or laboratory for the archetypal, essential elements of programming he really wants to teach. In the process, you do learn a bit about Python. Enough to make significantly complicated, useful programs, in fact. But that’s almost a side effect of the actual stated goal of the book, which is to impart a deeper understanding of computing concepts. In the end, this focus on core programming concepts makes the book actually very helpful in learning how to program in all languages, including Python. Just in an immediate, “master this in 3 days” kind of way. But that’s not a very valuable way to learn anything anyway.

So I’m left calling the name problematic, instead of outright misleading. Also, you’ll notice that the blog post that led me to the book insisted this was a good way to learn Python, and I’m not criticising that statement, either. It’s a little bit of a gray area: I can see some people saying that, no, this book does not in fact teach Python. And they would be right from a technical standpoint. I happen to be someone who values core concepts and looks at them as an essential part to studying anything I truly wish to understand, so I tend to look at what Zelle is doing here as learning how to program. It’s not quite as direct as other methods, but I think it goes far deeper.

2. Structure and Topics

The thirteen chapters of the book essentially divide into three sections. The first 8 chapters, plus chapter 11, are about basic elements of computer programming: expressions, variables, functions, arrays, strings and string methods, loops and the like. Chapters 9, 10 and 12 focus on design, starting with simple simulations and moving to more complex programs and introducing object oriented design. Chapter 13 is about Algorithm Design, including recursion, and, as such, is the only chapter exclusively devoted to concepts of computer science. Sure, the rest of the book is tempered by a perspective of computer science, but the last chapter is the only one featuring any CS “meat.”

This also presents a problem in defining the scope of the book. When talking about the name, I pointed out how this is supposed to be a book about computer science that uses Python programming as a method to that end. Really, the book is getting you up to speed on programming as an art and science, rather than discussing computer science directly. That doesn’t disqualify it as a computer science textbook, but it makes the focus of the book seem even less clear.

This seems to open up another gray area, as the title did. Is a book really about computer science if it spends most of its text discussing the art of computer programming? Barely. But does spending so much time on design make it a good introduction to the science? There is no better way to introduce a science than
to lead your student to direct experience in the environment that the science works with. As I will explain in the next section, this book will provide you with hundreds of hours worth of practice experience. Practical experience is really the best route to understanding, that is, a full grasp of the concept, as opposed to knowledge.

Many tech authors decide that the best way to teach everything is to, well, teach everything. Their books become massive, monolithic braindumps that provide thorough documentation on their subject, but very little in the way of imparting wisdom or understanding. Zelle excels in this latter method, making his book a true guidebook. A nice contrast from some of the other choices available.

3. Exercises

Wow. Massive. And subtly so: the actual quantity of exercises is not that incredible. But pay close attention (and you will, if you’re trying to go through all of them), and you’ll see that many of these projects are full-scale projects. The book was intended to be a classroom textbook, so perhaps the exercise sections were designed to be picked through by an instructor, shortening the time to complete them. I read this book for self-study, however, and I soon found that the 4 hours per day I had given myself for practicing Python was not enough to complete both the chapter reading and the exercises; then it became a matter of only getting a few exercises done per day; then it got to the point where I was taking multiple days to complete one project. Toward the end, I had entered into an Ahab-like state of obsession, putting all of myself into finishing all of the exercises and coming up with something good at the end. I finished, and it was a spectacular feeling.

Now, that’s just good education. When a teacher gets you to put so much effort into something that it becomes an intense point of focus like that, he’s really throwing you into the task. For a few days at the end, my life was coding. I got to feel what it was like to commit myself to coding. This also ending up being one of those experiences, where I gain insight into myself and how I do work.

Of course, I don’t think that this intense kind of experience was Zelle’s intention – at least not directly. What I credit him for is setting me, the reader, up with a swan dive into the material. This is an excellent balance and a good model for other textbook writers: though the pace of the text is slow, steady and thorough, the exercises can be fierce enough to really challenge you and get you to a high level of real understanding.

Here are some examples of exercises I liked: everything in chapter 4, which introduces graphical concepts at a relatively early stage for a textbook, having you design programs that draw faces and houses at the click of the mouse, for example; the decoding exercises from chapter 5; the bouncing ball animation from chapter 7 (exercise 17); the greyscale conversion (exercise 14) and photo negative (exercise 15) programs from chapter 8; most of chapters 9, 10 and 12 were fun. The end of chapter 12 is really a list of massive projects, where you’re asked to create games that simulate dice, card and board games. Chapter 13 had you working out some pretty funky algorithms, but, in the end, it was too short a treatment of the subject for your projects to get all that advanced. Though it is nice to come away with a script that solves the weekly jumble.

I’d also like to point out that all the exercises are fair. I’ve looked at a few tech texts so far that pull what I would consider a rookie mistake: carelessly creating exercise lists that, while they have to do with the topic at hand, rely on understanding concepts that weren’t directly discussed in the lesson. While this might seem like a small error – I find that for me, and other people I’ve observed, this can be a huge break in the “flow” of the text that throws off the learning experience. I’ll leave it at that, though, just to say that Zelle does not make this mistake.

I want to note that there was a single exercise I didn’t complete. This was chapter 12, exercise 6, which asks you to learn the rules of contract bridge and write a program that sets up the first hand. I’m sorry, I’m not going to spend my programming time learning how to play a game I have no interest in. I know, as a coder I might be tasked in dealing with things I’m not interested in. I’d be glad to. For money.

Not to end this section on a low note, but I must mention the “Review Questions” that come at the end of each chapter, before the exercises. The discussion questions were great – but I wish there had been a lot more of them and that they were more challenging. The true/false and multiple choice exercises were so short and easy they might just as well have not been included. Some drill-like exercises would have been nice in their stead.

4. Conclusion

This was a fantastic read. A true education in the subject, any gray areas its confusing title and structure might evoke for you are really insignificant compared to the insight into programming you are going to come away with. The text is 100% ideal for absolute beginners. I would call myself an advanced beginner – someone who programmed a lot as a kid, but who is just getting back to it after a decade or two – and the level of the text was still excellent for me. There was a lot of review, but it was very constructive – I feel I have a firm grasp on these concepts now. This book is not for more advanced programmers – but they’re not going to be reading any introductions to computer science any time soon. An intermediate programmer wouldn’t get anything out of the lessons earlier, but someone who is short of complete mastery of the subject, I think, will still be able to enjoy the exercises. The easy ones won’t take much time at all – but the later ones make a nice challenge.

This one is going to stay on my shelf a while – if not for myself, then to pass on to other beginners as a strongly recommended introduction.