#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.


#Book Review – Code Reading

The reading of code is likely to be one of the most common activities of a computing professional, yet it is seldom taught as a subject or formally used as a method for learning how to design and program.


Aspiring writers are always told to read as much as they can if they want to become better writers. As Dave Thomas points out in his foreword to Diomidis Spinellis’ Code Reading, aspiring programmers almost never get this advice. By code, of course, I mean the program source code, the fundamental recipe for any piece of software.

Imagine that you’re taking a writing course. You get assignment after assignment – persuasive essays, memos, poetry, research papers or prose. Now imagine that you have to do every one of these assignments from scratch, without any examples. You have to work everything out yourself.

This is the traditional method of teaching programming. I know because I used to teach programming classes.

Code Reading is both refreshing and an eye-opener. Not only does Spinellis present a solid case for the habit of reading program source code, he also fills his book with code examples, complete with commentary. Though the examples are mainly from Java and C, the lessons learned can be applied to any programming language.

Just to be clear, the code presented is not from the toy examples found in programming textbooks. This is material from real, working software projects. The book covers major programming topics and even includes analysis of a complete, working program. Spinellis gives tips and techniques for the novice code reader to aid them in developing their skills.

From my own experience, reading code can be very educational, even entertaining. Every programmer tries to put their own personal stamp on their work and part of the fun is seeing the human mind behind the algorithms.

For example, I was teaching game software development and wanted to get my students some practice in reading code. We downloaded the source code for BZFlag, a tank game based on the video game BattleZone combined with Capture the Flag. It’s a fun, cross-platform game that you can play solo or over the Internet with teams.

There was one particular feature in which I was interested. During play, you can set your tank to AutoPilot mode and let it play for you. This makes a nice change from having to pause your game whenever you have to get up and take care of business.

We grovelled through the source code files for a bit and I finally found the sections having to do with AutoPilot. As I read them, I spotted some code that looked very intriguing but was never actually called by any other part of the program. It looked like someone was trying to build a heuristic system for the AutoPilot mode. In short, it was meant to have the program build a solution starting with the goal and working its way backwards. It was very clever and had a lot of potential. I could add see why it hadn’t been  implemented due to the inherent complexity of the method.

The fact that the code was just left there, unfinished, was fascinating. When I saw that code, I put myself in the mind of that programmer. I’ve also had coding ideas that got stuck in blind alleys. But here was someone like me, trying to solve a problem in an interesting way and failing that, leaving a note for the explorers to come after in hopes that they would ultimately succeed where he did not.

This book shouldn’t just be on any programmer’s reference shelf, it should also be the basis of at least one undergraduate programming class.

Spinellis, Diomidis. Code reading: the open source perspective. 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 12 – Java ME

Week: 12

Language: Java ME

IDE(s): Java ME SDK32


The question for this week is why would anyone develop in Java ME? Java ME (Micro Edition) is designed for devices with limited memory, display and power capacity such as cell phones, PDAs, MP3 players, set-top boxes and Blu-Ray disc players. The most popular such devices are cell phones but they don’t support it. Android supports ‘real’ Java with their own framework. Apps for Apple’s iPhone and iPod Touch are built with Objective C and Windows phones don’t support Java in any form. In fact, according to NetMarketShare Java ME is in 3rd place in mobile operating systems with a 4.44% market share as of February 2014.

Not so fast. One place where Java ME thrives is in feature phones, the precursors to today’s smartphones. While smartphone shipments worldwide finally outpaced those of feature phones in 2013, about 42 percent of cell phone sales (839 million) were feature phones. In fact, if you’re living outside of the US and living on $10 a day, chances are pretty good that you don’t have an iPhone, Android or Windows phone. Facebook’s recent acquisition of WhatsApp was in part because of the app’s worldwide reach. Basically, it runs on everything, including Java ME devices. The market of the developed world is relatively small compared to the 3 billion other people on the planet who don’t have smartphones.

Now, if I were a developer (and as the official World’s Slowest Programmer(™), clearly I’m not), I wouldn’t readily dismiss this potential market.


As always, the first step is to get the software. The first thing you notice is that the latest version (3.4) is only available for Windows, so if you want to develop on Mac OS X, you have to use an earlier version (3.0). If you use Linux, however, you’re out of luck. You’ll have to use version 2.5.2 but you won’t have access to the emulator so you can’t test your software.

I have access to both Windows and Linux but since (as I’ve pointed out) I Am Not A Developer, I set up the IDE on my MacBook. Oracle does not make it easy to find any non-Windows version of the IDE. Even then, you have to register for a (free) user account on Oracle’s website. However, eventually I managed it.JavaME_IDE.png

If you prefer, you can also use Eclipse Pulsar and the default download comes with plug-ins for NetBeans. If you want to set up a new project, you can either import an existing wireless project or create a new one. But the demos give you plenty of code to play with and tutorials are readily available.

I set up a new project, taking the defaults. When I built and ran it, the software emulator automatically started and ran the app:HelloJ2MEApp.png

It’s similar to the Android SDK, except our graphic comes up as a feature phone (appropriately enough).


#52WeeksOfCode Week 11 – Android

Week: 11

Language: Android

IDE(s): Eclipse for Android


Android developers have both a huge opportunity and a huge problem. Both of these can be laid directly at Google’s doorstep as they spring straight out of Google’s Android Strategy:

1. Create a mobile operating system that is ‘good enough’ and give it away at no cost.

2. Let others modify the platform any way they want

Number 1 means that Android gets wide distribution very quickly. Last year Android devices made up almost 80% of global smartphone shipments and according to Google’s numbers there are 900 million Android devices out in the wild. Great news! Sounds like becoming an Android developer is a license to print money with all of those potential customers out there.

Not so fast, Hoss.

The problem comes with step 2. Smartphone companies get to decide for themselves what version of the operating system to use and what features they’ll support. So those 900 million phones are not all running the same OS and so your choice is to either support every active version available (thus costing you money and time) or just support the latest versions (plus or minus a release or two) and cut down on your potential customer base.

This isn’t even going into the problem of fragmentation on the hardware side. Storage capacity, memory size, screen sizes and resolutions…so your app still may not work on all devices even if they’re running a supported version of the OS. The major problem with Android (particularly for Android developers) is fragmentation.

Google, however, has an idea that they think will fix this. Simply put, they plan to restrict access to Google Mobile Services (GMS) to devices that ship with up-to-date versions of Android. So if you’re a smartphone maker and want to be able to ship apps like Google Maps, Google Drive, Google Play, Google Calendar and Gmail, you’re going to need to make sure you comply.

Great idea. There’s one teensy little problem, though. You don’t have to ship Google apps with your Android device. That’s exactly what’s happening in China, which has almost 300 million Android users, 70 percent of whom don’t use Google apps.


I want to be clear, this is not some kind of anti-Android or anti-Google screed. I have an Android phone and I rely on Google apps quite heavily (I’m typing this post in Google Docs, for example).

The reason China is rejecting GMS is because China and Google are having a fight over China’s censorship of Google search results.

So maybe the problem is about control. Perhaps if you want to give away software (and please note I’m a big fan of Open Source and Free Software), maybe you have to be willing to give up control and rely on what value you can provide through services and have your services compete openly with others rather than try to lock in your customers and rely on that to control them.

But I’m just a Simple Country Lawyer. (Metaphorically speaking.)


Getting the Android Software Development Kit (SDK) was pretty easy. You can do your development on Windows, Mac OS X or Linux and you can even use your own IDE, as long you download and install the SDK tools and whatever other Android packages you’re going to need.

I decided to go with the full bundle, so after I agreed to the Terms and Conditions, I went ahead and grabbed the approximately 450 MB download of the Android development platform for my MacBook. And though I have an Android phone, the kit comes with a software emulator so I won’t have to risk bricking my smartphone.

Android software uses the Java programming language and the IDE of choice is Eclipse. (You can also use the SDK tools from the command line but you’re still going to be programming with Java.) The download was a ZIP file consisting of two folders, eclipse and sdk. I followed the setup instructions and unpacked the ZIP in a folder called Development.

When I launched Eclipse, I was given a window with a button labelled “New Android Application” and three tutorials, “Build Your First App”, “Design Your App” and “Test Your App”. Selecting “Build Your First App” takes you to the Android Developer tutorial page where you’ll begin a walkthrough.

Like most modern IDEs, Eclipse has a New Project wizard that walks you through setup in order to make sure that you don’t miss anything. For this tutorial I created a project called “My First App”.

First problem – the simple act of creating my app (remember, I haven’t built or run it yet) generating a list of errors 337 lines long. This does not bode well. The full error log is here, if you’re interested. I’m going to soldier on, however.

One of the features that interests me about mobile application development is being able to test your app in a virtual device. As I’ve said, I have an Android phone but I’d like to try the emulator first.

The primary advantage of using the emulator is that you get to test your app on different hardware models with different versions of the Android OS. I launched the Virtual Device Manager (VDM) from the Eclipse toolbar and the first thing I see is a window with six error messages in it about multiple virtual devices that failed to load. As I haven’t created any devices yet, these may be older versions of the API that were not included as part of the SDK I installed. So I soldier on.

The next thing I notice is that my model phone is not on the list of devices available. I have an Galaxy S3 and the nearest I can find is the S4 so I pick that. The only Android API version available to my emulated device is level 19, which might explain why the other versions failed to load earlier. For the rest of my options, I take the defaults. My VDM window now shows that I have a valid Android Virtual  Device. I select the device, click on ‘Start’ and shortly a window pops up and I get what looks like an Android boot screen. At first it looks like it’s not doing anything but in a couple of minutes, I get a home screen. It’s a little pokey, but that’s to be expected. I have to use my laptop keyboard for the controls but the Android folks provide a helpful table for this.

The first run didn’t work but once I closed the emulator window and ran the app again it did.  Here’s what it looks like:MyFirstApp.png

Overall, it looks like getting started on Android development is fairly straightforward, as long as you ignore the Looming Spectre of Fragmentation (as discussed above). Like everything else, there are still issues. But, as the Buddha says:

What is the noble truth of suffering? Birth is suffering, ageing is suffering and sorrow and lamentation, pain, grief and despair are suffering.

He was a pretty fun guy.

#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.