#Review – The Practice of Programming

In a world of enormous and intricate interfaces, constantly changing tools and languages and systems, and relentless pressure for more of everything, one can lose sight of the basic principles— simplicity, clarity, generality— that form the bedrock of good software.

Kernighan, Brian W.; Pike, Rob (1999-02-09). The Practice of Programming (Addison-Wesley Professional Computing Series) (p. ix). Pearson Education. Kindle Edition.


Programming is a craft. Some programmers refuse to acknowledge this, insisting instead that it’s a scientific or engineering discipline. There are certainly elements of that but anything that allows a human to place their own distinctive style on a made thing is a craft.

Bridges look a certain way because that’s how the physics make them look, not because the engineer was feeling whimsical that day. That’s why one bridge looks a lot like another. When a carpenter makes a bookshelf, it shares the same functionality with other bookshelves. However, there are a hundred individual decisions made by the carpenter during the design and creation process. A bookshelf is physics seasoned by art.

Two software applications may have similar functions but the underlying source code tells a different story. Anyone who reads or writes code knows that the programmer imposes their own personal style on the code in hundreds of different ways. From the use of a favorite decision loop to the design and implementation of a particular data structure, programmers have always found a way to express themselves in their work.

The Practice of Programming was written to bring programmers who are swimming in complexity back to their roots and help them regain perspective. Just to be clear, this is not a book that will teach you how to program. However, if you are learning to program or even if you’re a veteran coder, you’ll get something useful out of this text.

Despite this, Kernighan and Pike don’t romanticize the work of programming. Instead they show that by embracing (or re-embracing) the fundamental principles of coding, you can become a better, more productive programmer.

They start with a style guide, because clean, consistent code is easier to read, debug and maintain. Establishing and maintaining a consistent coding style frees up your higher brain functions for more complex decisions and problem solving.

Next we move on to algorithms and data structures. These building blocks of software should be familiar to all coders but the right algorithm choice can make the difference between a program that takes an hour versus one that takes seconds to produce the desired result.

The authors build on this foundational knowledge with discussions on design, interfaces (how to efficiently pass data), debugging, testing (which reduces debugging), performance, portability and end with a chapter on notation which includes a discussion of tools that will help you generate code automatically.

The writing is crisp and direct. Kernighan and Pike speak to you, programmer to programmer. They have decades of combined experience in the coding trenches and understand the problems you face every day, whether you’re doing an assignment for school or creating a business analytics solution for your business.

#52WeeksOfCode Week 24 – Game Programming

Week: 24

Language: Game Programming

IDE(s): Twinery 2.0 Beta

History (official):

This is the only entry in this sequence which is completely open. Since I can use any language or platform I want, there’s nobody to pick on.

History (real):

When I was a program chair for our game software engineering program, I was given a lot of textbooks from optimistic publisher reps. One that stood out from the others was “Beginning C++ Game Programming”. (Dawson, Michael. Beginning C++ Game Programming (Game Development Series). Premier Press, 2004.)

We ended up not using the book because it didn’t target a particular platform like Windows or game programming framework like Unreal. But when I took a closer look at it, I realized it wasn’t actually about game programming.

It was about learning to code by programming games.  The book took you through basic programming concepts, such as control structures, loops, data structures and even object-oriented programming. These are all of the things that would be covered by a beginning to intermediate programming text. What made it different was that every piece of code was either a game or gaming-related (like a character generator for an RPG). It almost made me want to learn C++ over again because the book made it look like so much fun.

While technology and education methodologies have progressed substantially since I was a lad, programming textbooks still have really boring assignments. The success of gamification in learning as illustrated by Khan Academy, Code Academy  and Google’s Oppia project suggests that it’s time to bring that into the classroom at the college level.


The goal this week is to write a game. I can pick any language, framework or platform I want. I am, in fact, spoiled for choice.

When I was a lad and computers were the size of draft horses and ran on steam power, computer games were text-only. They were a lot like those “Choose Your Own Adventure” books and some of them, most notably from Infocom Games, were very sophisticated.

Though text adventures are not as popular as they once were, they’re still around, supported by an enthusiastic community of developers and storytellers. As a result, there are a number of software programs that make it easier for you to develop a text adventure and users post their files for others in the community to try.

At one time I wanted to try my hand at this and I used Inform, which was a powerful tool that included a scripting language and let you build very complex worlds. Unfortunately learning to program in Inform was definitely more work for me than my casual interest in creating a game so I did a quick project and never picked it up again.

We have more choices these days, however. A newcomer to the field is Twine, a tool that is more in the spirit of the Choose Your Own Adventure books and so not as sophisticated as Inform. Consequently, it’s much easier to build a game. There are two versions of Twine. One is a downloadable package for Windows or Mac OS X. The new version (which is still in beta) lets you do all of your development in a Web browser and then download your game as an HTML file. That looked like fun, so I started it up in a browser window.

Twine game editor

Twine Web-based game editor

The interface is a bit sparse so it took a bit of experimentation to get started. You are presented with a blank canvas. To begin you add a Passage, which is what I would have called a room. When you do, you’re presented with the Passage editor.

Passage edit window

Editing a Passage

You give the Passage a name. You can also add Tags, which contain information that is not visible to players but might be anything from a simple annotation to a link to run a custom script before the story starts. Tags are totally optional.

Unless you want the shortest story ever, you need to link to other Passages.  The easy way to do this is by adding the name of the Passage, surrounded by double square brackets, as you can see above. If the Passage you name doesn’t exist, it will be created and linked to the current Passage. You can put as many links as you want to other Passages. You can also create the new Passage directly in the editor and link to it later.

Continue creating and editing Passages until you reach an end point for your game. At any time you can play-test your game in the editor.

Starting the game

Starting up my game

Note that all of your data is saved locally in your Web browser so if you quit without saving then you’ve lost all of that work. Fortunately you can archive your work in progress by periodically clicking on the Home icon in your editor and going to your main work page.

Twine Web Main Page

Twine Web Editor home page

There you can also start a new story, import story files and work on other stories. Once you’ve completed your game, you can download it as an HTML file and either post it as a Web page or open it locally in a browser.

It was very quick and easy. Though I could have jazzed it up with stylesheets and javascripts, that’s totally optional. The thing is, I had so much fun putting using this that I can see myself coming back to it.

I may not have the Great American Novel inside me but there are plenty of short stories.

#Review – The Art of Unix Programming

There is a vast difference between knowledge and expertise. Knowledge lets you deduce the right thing to do; expertise makes the right thing a reflex, hardly requiring conscious thought at all.

I was introduced to Unix in 1986. I was working at AT&T as a communications technician and my operations manager had just gotten hold of three 3B2 minicomputers. I was tapped to do something useful with them. So I bought a copy of Unix System V Bible, plugged a serial terminal into one of the 3B2s and started learning.

I still have that book, by the way.

This was my introduction to Unix. It was also my introduction to the Unix culture, and the wider world of the Open Source software movement.

Eric S. Raymond is one of the most eloquent supporters of Open Source. His book The Cathedral and the Bazaar was a seminal work on the emerging information economy and the changing model of software development. As Cathedral was a work of philosophy, Raymond’s The Art of Unix Programming was about practice.

As I’ve said before, I’m not a professional programmer. I write code for fun and to build tools for other work. I teach programming. I blog about programming. I read about programming. These are just some of the reasons that Eric Raymond’s book has a permanent place on my bookshelf.

Another reason is that Raymond is a damn good writer. He’s engaging, passionate and smart without being condescending. This book is nominally about writing Unix programs but on a higher level it’s a treatise on software design. Raymond uses Unix as a jumping-off point to discuss the larger topic of writing good software.

It’s not about a particular programming language. You can write Unix programs in any language you like.

One of my favorite sections is “Basics of the Unix Philosophy” where he lays out the rules of design for good code. From the Rule of Modularity (“Write simple parts connected by clean interfaces”) to the Rule of Extensibility (“Design for the future, because it will be here sooner than you think.”), they all represent solid advice for designing code with any language on any platform. I’ve tried to incorporate these rules in my own code.

In addition to offering guidance for current and would-be programmers, there is a section on design principles, including Modularity, Textuality and Interfaces. Naturally, there are copious references to Open Source, including a discussion of software licensing and best practices.

But it’s not all sunshine and relentless boosterism. Raymond takes a clear-eyed look at the problems with Unix culture and problems in Unix design. Bonus features include a section called ‘Rootless Root’, a parody of Zen philosophy complete with Unix koans and copious examples of code demonstrating the principles that Raymond outlines the book.

The Art of Unix Programming is not just a good book for coders but for anyone who enjoys reading about the philosophy of design.



Raymond, Eric S. The Art of Unix programming. Addison-Wesley Professional, 2003.

#Coding4Humans Book Review – Programming Pearls

I enjoy reading books about computer programming. (At this point you’re probably saying to yourself, “Of course you do, Tom. You big old nerd, you.”)

But the books I prefer to read aren’t about a particular programming language or operating system but the books about the art, history and philosophy of computer programming. Programming Pearls by Jon Bentley is a classic in this particular genre.

Bentley was a computer researcher at the original Bell Labs in Murray Hills, NJ and he used to write a column on various aspects of programming design and problem-solving for the periodical “Communications of the ACM”. This book is made up of selected essays from that column.

This book has earned a permanent spot on my bookshelf in three ways. First, it’s a fascinating glimpse into the history of computing. The year it was published (1986) was the beginning of the personal computer revolution. We were taking the power back from the mainframe computer priesthood. Having a PC was to be like Prometheus with a piece of stolen fire. We had some of the power for ourselves and were struggling to figure out what to do with it. (Hackers: Heroes of the Computer Revolution by Stephen Levy is an excellent look at the people and personalities that built this era.)

This book is also about problem-solving. As Bentley says in the introduction:

The essays in this book are about a more glamorous aspect of the profession: programming pearls whose origins lie beyond engineering, in the realm of insight and creativity.

These days we’re accustomed to being able to just throw more hardware at computing problems. Bentley reminds us that there is still value in thinking a problem through and presents some interesting ideas, examples and exercises to aid in that work.

Finally, there is my favorite essay, “The Back of the Envelope”. If I had my way, this would be required reading for all of my math students.

Let me explain.

I encourage the use of calculators and computers in my math classes to do the computational heavy-lifting. My logic is that if you understand the problem well enough to explain it to a machine, then the actual computation is just a mechanical exercise. But this doesn’t mean that you should just trust outright whatever a machine tells you. You need to know what the answer should look like by using estimation so you can judge the machine’s output. Bentley devotes an entire section to estimation and these skills also extend into other essays, such as “Perspectives on Performance” and “Algorithm Design Techniques”.

Programming Pearls includes exercises at the end of each essay to help you develop your mental muscles (don’t worry, there are hints in the back of the book) and an appendix with a catalog of algorithms. At 256 pages, it’s a pretty breezy read and the organization of topics makes it easy to just dip in wherever you like and start reading. It’s not just an excellent reference but Bentley’s writing style is friendly and intelligent without being condescending. If you’re a programmer (whether hobbyist, student or professional) you need a copy of this book.


Bentley, J. L. (1986). Programming pearls. Reading, MA: Addison-Wesley.

Levy, S. (1984). Hackers: Heroes of the computer revolution. Garden City, NY: Anchor Press/Doubleday.


#52WeeksOfCode Week 17 – CSS3

Week: 17


Language: CSS3


IDE(s): Coda, MAMP



When a new technology comes out, you have to ask yourself two questions:

  1. What problem is this intended to solve?
  2. How well does it solve it?

CSS (Cascading Style Sheets) were designed to solve the problem of adding styles to Web documents. Was this actually a problem? (see question 1)

Web pages, at their heart, are just plain text. Originally if you wanted to add formatting you had to use markup tags to set the text as italic, boldface, underlined or even organized as a list or a table. This required some fiddling with individual text elements and there was no easy way to apply a style or combination of styles to text in separate areas of the page in one go. In addition, if you wanted to use the same content with different styling elements (or to present it for different browsers or platforms), you had to rather painfully re-write your markup.

Cascading Style Sheets let us define styles for different HTML elements (either in the Web page itself or in a separate CSS file) and apply them directly. Whenever the Web browser sees text with a label defined in CSS, it applies the appropriate style. Using a separate CSS file is considered better as it allows you to apply a common look-and-feel to multiple Web pages and makes it easy to re-format a Web page simply by applying a different CSS file.

So CSS does indeed seem to be a solution to a legitimate problem. But how good of a solution is it?


  • Keeps content and design separate, making our HTML cleaner and easier to read.
  • Makes it easier to display the same page correctly on multiple devices in multiple browsers
  • Size and positioning of objects (such as images) can be pre-defined in CSS
  • Gives readers more flexibility and control in how they view Web pages


  • Not all browsers support CSS the same way
  • Using CSS to position your Web page objects gets ugly really fast.
  • CSS is ‘markup centric’ rather than ‘design centric’, forcing many Web designers to craft their code by hand


Needless to say, opinions differ. (The comments are pretty heated at that link. I recommend reading all of them.)

We are trying to move from print (which has had nearly a thousand years to evolve) to the Web (which has only been around since about 1993). I don’t think we’ve figured out the new design paradigms yet, but sites like CSS Zen Garden offer some intriguing possibilities.



This week I used MAMP as my Web server as usual, but instead of TextWrangler I decided to use Coda from Panic Software. It’s not free but Panic makes very good, clean, well-behaved software and Coda is not exception. Coda is not only specifically designed to manage Web code but comes with built-in documentation for

I was looking for something interesting to do with CSS and I came across a wonderful little tutorial at CoDrops. It walks you through setting up a Web page with CSS and JQuery that renders an animated billboard that flips between two different signs. I modified the images included using GraphicConverter and ImageMagick.

The output looks like this (as an animated GIF):

Hello World billboard

hello world animated billboard

#52WeeksOfCode Week 16 – HTML 5

Week: 16

Language: HTML 5

IDE(s): TextWrangler


Technically, HTML isn’t a programming language but a markup language. But version 5 has some interesting features so I’m learning something here.

Boy, did I wade into a crap storm.

It’s been quite a while since I’ve poked around with HTML and I was interested in the multimedia support that was being built into the HTML 5 specification. Like a lot of us, I’ve had to struggle with browser plug-ins like Flash, Silverlight and once even RealPlayer.  All just to watch a video or play an animation or listen to a sound file.

That’s just for a desktop computer, by the way. Once you get into mobile devices, it gets even worse. Either the plug-ins aren’t available (and you are blocked from whole chunks of the Internet) or they chew up your battery life like crazy.

But what if we didn’t have to deal with that? What if we could just play this stuff in our browsers with no extra software required? That’s one of the problems that HTML 5 was designed to solve and that’s also how the W3C ran into a buzz saw of nerd rage.

Let me explain. Every Web browser has something called a DOM or Document Object Model. You can think of it as an abstract model of a Web page that, in theory, lets Web developers write code that works across different platforms without having to create different versions for multiple operating systems or browsers.

Please note the phrase ‘in theory’.

A DOM is supposed to be a standard so, of course, every browser vendor came up with their own version. Sure, the basic elements were supported by everybody but they just couldn’t resist putting their own special little features to differentiate themselves from the competition. So before you knew it, Web developers were having to write different code for different platforms.

If you’ve ever gone to a Web page and got a message that you needed a different browser or if the same page doesn’t work the same way in two different browsers (if it works in either), then you know exactly what I’m talking about.

ANYWAY, it’s gotten better. Kind of.

The W3C created a new DOM element for HTML 5, called HTMLMediaElement, which gives the DOM the ability to present content like audio and video which would have previously required a plug-in.

But the advantage of the plug-ins (for content providers, anyway) was that they allowed restrictions on how that content was consumed using DRM or Digital Rights Management.

Now nerds (and other people — I count myself as a nerd) are not big fans of DRM. “Information wants to be free” and all that. People who create content (or just own it) occasionally want to get paid.

So when the W3C came out with something called Encrypted Media Extensions (EME) that extend the functionality of HTMLMediaElement to play protected content, a large portion of the nerd universe exploded in white-hot rage-gasm. (Remember, I’m a nerd. I can use that word.)

The Free Culture Foundation posted an indignant online editorial entitled “Don’t let the myths fool you: the W3C’s plan for DRM in HTML5 is a betrayal to all Web users.”

(I left the emphasis in to portray just how irritated they were.)

Let’s take a look at the relevant part of the documentation:

This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems. Implementation of Digital Rights Management is not required for compliance with this specification: only the simple clear key system is required to be implemented as a common baseline.

The common API supports a simple set of content encryption capabilities, leaving application functions such as authentication and authorization to page authors. This is achieved by requiring content protection system-specific messaging to be mediated by the page rather than assuming out-of-band communication between the encryption system and a license or other server.

Now I’m just a Simple Country Lawyer, but it seems like this is saying that while DRM is not built in to HTML 5, EME is designed to let content providers still use DRM.

So if you were looking to get rid of browser plug-ins, then good news for you. If you were looking to get rid of protected content on the Web, you’re out of luck.


I used MAMP for my Web server and built a quick and dirty little Web page that includes an audio file. HTML 5 makes this much easier than it once was, since you can let the Web server and browser figure out between themselves how to present the content. Here’s the code:

<!DOCTYPE html>
<title>52 Weeks of Code - Week 16 - HTML 5</title>
<meta charset="utf-8">
<meta name="description" content="The head tag contains the title and meta tags - important to the search engines, and information for the browser to properly display the page.">
<p>My first HTML 5 webpage</p>
<p>Here is the sound of someone saying 'hello'<p>
<p>Just click on the play control.<p>

<audio controls src="sounds/hello.mp3">
<p>It's very easy to embed sounds in HTML 5. Just use the code:<p>
<pre><audio controls src="hello.mp3">

I snagged the sound file from here. Here’s what it looks like in Google Chrome:


#52WeeksOfCode Week 10 – Windows Presentation Foundation

Week: 10

Language: Windows Presentation Foundation

IDE(s): Microsoft Visual Express


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

C.A.R. Hoare (British computer scientist, winner of the 1980 Turing Award)

Sometimes it seems to me like Microsoft exists in some parallel universe which only occasionally intersects with our own. I come by this opinion honestly. I’ve watched for decades as Microsoft rejects perfectly good technology (such as DNS) time after time and invents their own, incompatible version (like WINS).

This is not to say that the software in the Microsoft universe (Microverse?) is inferior but it’s as if they refuse to believe other software developers exist. The Windows Presentation Foundation is a good example of this. It uses MVVM, (Model-View-ViewModel), a Microsoft-developed descendant of the venerable MVC (Model-View-Controller) design model. It also uses their own version of XML (Extensible Markup Language) known as XAML (Extensible Application Markup Language). See? Like our universe, but different in many subtle ways!


WPF, as the name implies, is a User Interface (UI) framework. As such, I’ll readily admit that it makes creating a graphical interface extremely easy with simple drag-and-drop of a rich library of UI controls. In many ways, it reminds me of Apple’s Interface Builder, which offers similar functionality but is a separate application from their IDE, XCode. WPF, by contrast, is fully integrated with both MS Visual Studio and MS Visual Express.

Once I got Visual Express installed and running, I used one of the many good tutorials available to quickly work up some code. Building the UI was as simple as advertised and, since I didn’t need to do anything fancy, I added a single line of code and produced something that compiled and ran properly. (Basically, it was a button and textbox in a window. When you clicked on the button, “Hello World!” would appear in the textbox. The code is so trivial I’m not even going to bother embedding a link to it.)

That was really all the code I was looking for at this time, so I decided to get a sampling of opinions from developers about the technology. The ones that like WPF and XAML seem to do so because it’s a very clean separation of UI and programming logic. In addition, they like it because it’s so much better than what they used to use.

The ones who don’t like it, on the other hand, seem to do so because it’s not as good as what they used to use. They cite problems such as a poor design experience, bad animation performance, weak support for drag-and-drop (ironically enough) and that WPF makes the hard things trivial but the trivial things hard.