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

Advertisements

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

#Review – The New Hacker’s Dictionary

bogosity /boh-go’s*-tee/ n.

 

  1. [orig. CMU, now very common] The degree to which something is bogus. Bogosity is measured with a bogometer; in a seminar, when a speaker says something bogus, a listener might raise his hand and say “My bogometer just triggered”. More extremely, “You just pinned my bogometer” means you just said or did something so outrageously bogus that it is off the scale, pinning the bogometer needle at the highest possible reading (one might also say “You just redlined my bogometer”). The agreed-upon unit of bogosity is the microLenat. 2. The potential field generated by a bogon flux; see quantum bogodynamics. See also bogon flux, bogon filter, bogus.”

 

I love words. I’m always looking for new phrases and jargon, the more evocative the better. After I read Steven Levy’s Hackers, one of the things that stuck with me was how this group had developed their own language.

Every field of expertise has its own jargon. For hackers, though, English is just another programming language, just with looser rules. It’s a system. Hackers explore and manipulate systems, either to achieve a specific goal, see what happens or just to have some fun.

The New Hacker’s Dictionary originated in 1975 at Stanford as a simple file maintained by Raphael Finkel, collecting hacker jargon from various branches of the community. Like any language, ‘hacker-speak’ has dialects. The file was copied around the community, each group adding their own entries to what was becoming a shared history of the hacker culture. Eventually it was collected and published by M.I.T. Press and that’s when I got my hands on a copy.

Normally you don’t read a dictionary for fun, but this one is different. It’s a snapshot of a period of time that transformed not only my own personal and professional life but that of the world.

Consider this. The year the Jargon File was created, the very first personal computer was offered for sale.

It was the MITS Altair.

It came with 256 bytes of memory (expandable to 64K), had no keyboard or monitor and a single data bus. You had to key in your programs in low-level assembler code by flipping switches on the front panel one word at a time.

It sold as a kit for $297 (the case was extra).

Oh, yeah, I almost forgot. Microsoft got their start licensing software for the MITS Altair.

The year the Jargon File was finally published, more email was sent than postal mail in the United States and an IBM computer named Deep Blue became the first machine to beat a chess grandmaster.

The book includes a pronunciation guide, a guide to hacker writing and speaking style, a section describing hacker folklore and a guide to ‘J. Random Hacker’, which serves as a sort of spotter’s guide.

The words and phrases themselves range from layered and complex to playful and the book includes cartoons by Guy L. Steele, co-author and noted computer scientist.


Reference: Raymond, Eric S. The new hacker’s dictionary. Eric S Raymond. M.I.T. Press, 1996.

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

References

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 1 – JQuery Effects

Week: 1

Language: JQuery

IDE(s): TextMate

Background:

The World Wide Web (does anyone still call it that?) was once a quiet, meditative place. After all, the protocols were originally designed as a cross-platform way that scientists could exchange research papers. (That’s right, kids. At one time ‘surfing the Web’ was otherwise known as ‘reading’.) Then, of course, the rest of us got hold of it and now it’s all about talking cats demanding fast food. Well, that’s progress for you.

At any rate, Web pages were originally static documents written using a relatively simple markup language known as HTML. You didn’t need any fancy tools or advanced knowledge to set up a Web site, a simple text editor worked just fine.

In 1995 Brendan Eich, a developer at Netscape decided that the Web needed to be a bit more interesting, so he developed a programming language that would run inside the browser. Originally called LiveScript, it was designed to add dynamic elements like buttons and text fields for online forms and was later renamed Javascript (which, despite the name, is not related to Sun Microsystem’s Java programming language). Now what was once just data was now mixed with active code. Some people had a problem with this.

I first encountered Javascript several years ago and at the time it was pretty easy to learn, particularly since I was already familiar with other programming languages. The main new thing I had to wrap my brain around was the idea of code running inside of a document. I haven’t used it since then and the language has evolved considerably due to its built-in extensibility. In addition, Javascript has moved beyond the Web browser to become more of a general purpose scripting language used in productivity software, digital media development and even game engines.

Extending JavaScript is actually quite easy. You simply create a JavaScript file  with the code you wish to be able to use and then tell your scripts where to find it. Reusable code like this is referred to as a ‘library’.(You’ll see this later when we get into our example code.)

JQuery is a library of prepackaged JavaScript code that works across multiple platforms and browsers and adds a lot of useful functionality to basic JavaScript, including functions to access Web 2.0 frameworks such as AJAX and easier ways of controlling animated elements on a Web page, which I’ll use in my demonstration code.

Setup: The best way to test Web software is with a Web server. I have several options for this but I wanted to set up a local environment so I could work without an Internet connection if I wanted. Once again, there are a lot of options for this but for me the easiest was MAMP.  This is Mac-based software that gives you a simple, turn-key solution for Web development (there are versions available for Linux and Windows as well.) It’s dead easy to install and set up so I was able to quickly set up my MacBook as a programming workstation.

(Before I get indignant emails, I do realize that Mac OS X has built-in Web and database services but with the latest release they’ve become more of a hassle to setup and manage. MAMP is pretty much plug-and-play as are its Windows and Linux versions.)

So I have my test server. How do I manage my code? I wanted to keep things simple, so I went old-school – a text editor. I used Textmate, the free cousin to BBEdit. BBEdit is one of the best standalone programming editors for the Mac and I’ve been using it for years.

(My favorite Windows editor is ConText and when I’m using Linux/Unix I just use vi but if I had to pick a feature-full GUI text editor for Linux both gedit and kedit are quite good.)

Coding: When I taught beginning programming, my students would often get stuck when starting a project. This is the advice I’d give them:

Don’t try to solve the entire problem – This is good advice in general but even more so when you’re trying to do or learn something new. Instead solve the smallest part of the problem you can manage and see where that takes you. So if you’re writing a program that is supposed to process text, start by writing just enough so you can open a file and print out its contents.

Start with what you know has to be there – Every programming language has a certain minimum amount of code that has to appear in every program. For basic JavaScript that means a Web page, like so:

<!doctype html>
<html>
<head>
<meta charset=”utf-8″ />
<title>Demo</title>
</head>
<body>
<script>

// Your code goes here.

</script>
</body>
</html>

However, we’re adding the JQuery library so we have to modify this a bit:

<!doctype html>

<html>

<head>

   <meta charset=”utf-8″ />

   <title>Demo</title>

</head>

<body>

   <script src=”jquery.js”></script>

   <script>

   // Your code goes here.

   </script>

</body>

</html>

 I put the JQuery package (jquery.js) in the same folder as my Web page and then added a line to tell the Web browser where to find the code when it processed my page.

Have a project already in mind – The best way to learn a programming language (or pick up any skill) is to have an idea of how you’d like to use it. If you’re planning a trip to Italy, for example, you’ll be much more motivated and focused while learning to speak Italian. Programming is the same. Fortunately the assignment for this week is very simple – use one or more of the JQuery Effects to animate some element of a Web page.

You don’t have to reinvent the wheel – There is plenty of sample code out there, in addition to code that you’ve written yourself for earlier projects so it’s a good idea to keep old code snippets handy for future occasions. The first place to check is the vendor documentation. You can also post your question to an appropriate discussion site.

According to hacker tradition, the first program you write should be some form of “Hello World”. In other words, write a program that outputs the stated phrase in some form or another.

So in the interest of keeping things simple, I wrote a quick script that will make the words Hello World slide down on to the Web page. The complete program is here. I adapted the sample code from the JQuery documentation. (Note that I gave them appropriate credit in my script.)

 As to what it looks like, I don’t yet have a public facing Web server set up but I can show you with this screen grab:

NOTE: I regret that this was a rather abbreviated entry. I got off to a late start on the coding challenge and wanted to keep to an ongoing deadline of midnight Tuesdays throughout the challenge. Future posts will be more detailed.

 

52 Weeks of Code Launch Day

As this is the start of a new year, this LifeHacker article has inspired me to take on a year-long project for 2014, namely the 52 Weeks of Code Challenge. Each week I’ll be trying my hand at a new programming language and writing up my experiences for this blog.

The basics are simple – each week I’m assigned a different programming language, I write a program using the language and post it.

I plan on adding a few wrinkles, however:

Development Tools – Depending on the language, I’ll be programming using everything from a simple text editor to a variety of IDEs plus additional tools and utilities. As part of my weekly write-up, I’ll be describing and critiquing my toolkit. I’ll also be playing around with version control and project management systems and offering up opinions about them. I’ll be paying attention to free open-source tools as well as the current new hotness of web-based tools.

Languages – I also plan on writing up the background and applicability of the Language-Of-The-Week (™), with plenty of personal observations and opinions. Though I don’t program for a living, I have a background in IT and a graduate degree in computer science, plus I’ve taught undergraduate classes in software engineering. While I do code for myself, I’m a tool-maker: I code up utilities as I need them, everything from simple system automation tasks to an application to generate student class scheduling information.

Resources – The good thing about this challenge is that the Internet is chock-a-block with programming support, including tutorials, classes and sample code. I’ll be posting links and mini-reviews as part of my weekly postings.

Pros: This challenge plays to my strengths, as I have a strong nerd background with an eclectic range of interests. I enjoy learning new things and as a freelance writer this will give me more opportunities to polish my skills. If I end up finishing the challenge I’ll be publishing my experiences as an eBook.

Cons: I recognize that real life has a way of getting in the way of our best intentions. It’s possible that I may get sick, walk in front of a truck or have some other kind of life change that will cause me to abandon this project. I may even get to a point where I just don’t want to proceed for whatever reason and stop. This doesn’t even get into my day-to-day activities which include teaching, consulting and freelance writing. A final concern is the fact that I happen to be the World’s Slowest Coder (another reason I don’t do this professionally) so depending on the complexity of the week’s challenge I may have issues meeting my deadlines. But for now I’m optimistic. I’m already familiar with some of the programming languages and I have built-in flexibility in my daily schedule. (Besides, I’ve always had trouble getting to sleep and late night writing is a good way to calm my thoughts.)

My current tools:

Platform: I have access to Mac OS X, Windows, IOS, Android and Linux, each of which has their strengths and weaknesses as programming platforms. There are some weeks where I’ll have to use a specific platform for the challenge but in general I’ll use whatever I think is appropriate and if possible port my code between platforms. I’ll also be using a flash drive with portable applications from PortableApps.com so I can continue working on-the-go. Each week I’ll let you know which platform(s) I’m using and their respective strengths and weaknesses for that week’s task.

IDEs: I’ll be using everything from simple text editors to GUI and Web-based IDEs. I’ll be including reviews in my weekly posts.

Version Control: Right now I plan on using a very ad-hoc system jiggered together with Evernote and Dropbox. Later I may transition to a more formal system such as Git or Subversion and that will be part of the learning process which I’ll share with my readers. I’ll also be regularly posting my code on PasteBin but I may also explore other, similar services.

Project Management: Since this is a project (albeit a personal one) I’ll be experimenting with various local and Web-based project management tools and resources and polishing my workflow as I go. I’m starting with Evernote and working my way up from there.

Do you have any personal or professional goals for 2014? Have a plan to achieve them? Sound off in the comments!