There's no such thing as real programming

There are lots of confusion online about what "real programming" is.  Most people aren't programmers, and the myths that programmers create about their own profession result in a lot of confusion.

My interest was piqued when I saw this question on a very popular programming site. I could imagine a confused kid, sitting through a boring lecture, wondering why a language was not 'real' enough for the programming world. And it is a confusing: there is no distinction between Physics and "real" Physics, so why programming?

There is a cottage industry of people claiming to teach you the tools that professional programmers use. I suspect these people are exploiting the confusion and fear related to programming.  A non-programming parent looks at the course curriculum to finds that their kids are being taught BASIC. "Basic? Wow, that stuff is dead. My child should learn what Google and Facebook engineers use so my kid can earn his first million right out of high school."


I write software for a living.  I am as real as a programmer gets. And I'm here to tell you that

 This notion of a "real programmer" is completely bogus.

It started out as typical male machismo about programming. And it has only gained in bullshit with time. It is an easy way to deride honest programming activity because it isn't as painful as the work that programmers do all day. The claim is that unless you are working with gigabytes of code and are fixing painful bugs you are an imposter.

Reminds me of a long time ago when I was learning juggling. A fellow juggler, let's call him Jack, was really good. Jack mentioned to me how you can't call yourself a "real juggler" till you could juggle five balls. I was just starting out, so I thought there must be a good reason for this. The mystery was cleared when a friend told me that Jack says this to everyone because:

A) 5-ball juggling is hard
and more importantly
B) Jack can juggle 5 balls

Jack needed external validation, that poor insecure fellow.

If you can juggle more balls than the hands holding them, you are a juggler. 


Programming is much the same. If you can write a program to make your life easier, irrespective of language and technical difficulty, then you are a programmer. I use a specific set of tools: an IDE, a debugger, a specific revision system. But plenty of expert programmers use completely different tools. There is no one tool that fits all tasks. An Integrated Development Environment can be great for large, unwieldy code-bases where you need to debug extensively and yet it can be a impediment to understanding and running a simple five-line program. The popularity of Arduino suggests that there is a huge demand for a simple programming environment rather than the complexity of a full IDE with an integrated debugger.

The essence of programming is writing down steps to solve a problem. The problem could be a very complicated one (What webpage matches the words "real programming") or a very simple one (What is the tip on a $20 meal). Since computing has become so pervasive, more problems can be solved with a computer. Previously, you would have a paper address-book with names written in them. Now you have them all written on a computer. This allows you to solve the problem (How many of my contacts live in Delhi) with very little effort. Simple programs can help reduce a lot of repetitive work.

But programming goes beyond. It is an aesthetic activity: making the computer draw fun shapes, or do silly things with sound or letters. All of this can be achieved with programming as well. Many programmers started out writing small fun programs in obscure languages and grew fond of the possibilities.

Programming is as enjoyable as painting.  Even if you never paint a million-dollar masterpiece.

(Image courtesy: Jim Pennucci)

Basic 256: a great way to learn programming

Want to have some fun programming? Pick up Basic 256, a BASIC interpreter that runs on your system.

Programming is fun, but introducing someone to programming can be difficult. Even a simple program requires a lot of background knowledge, and it takes a long time to write something useful. Most new programming languages require a great deal of understanding: a simple line like 'import string' in Python is devilishly confusing to a child. Most programming books today aren't fun anymore, and that is a real pity. Programming can be as enjoyable as playing with Lego, except that you never run out of bricks and no laws of Physics limit your structures.

So I was very pleased when I recently tried out Basic 256, which is a Basic language interpreter that runs on Linux, Windows and Mac. The default window shows an editor on one side and text and graphical output on the other side. You can start right way, asking the computer to speak out "Hi there" which is this program:

say "Hi There"

That's all there to it: a child could do that. It has support for drawing graphics, accepting mouse input, synthesizing music, and more. The best part is that it is accessible: someone with no programming background could sit down and have a good time modifying programs they find online.

In addition to being an excellent environment to program in, there are two things that make Basic256 a superb resource:

1. An excellent book: So you want to learn how to program? by James Reneau. The book is available free online, as an inexpensive PDF online, and also as a paper copy. I have read through a few chapters: it does a great job at introducing programming in bite-sized chunks of fun.
2. A collection of copy-and-paste examples. This is a great collection of simple programs that do something concrete. Complete code samples like this are a great way to see how something works end-to-end and learn by taking things apart and modifying them.

In addition to having everything I remember from my early BASIC days, Basic256 has support for networking, databases, fonts, and a lot more. And it is available to download for free. It is a marvellous resource when showing children real programming and in getting them started with programming.

Simple paint program for children

I had blogged earlier about a simple program to allow children to use a computer without any supervision. That program shows alphabet and numbers and lets the child freely explore a keyboard.

A few weeks ago, my son showed an interest in using the mouse. I looked at a few programs meant for children. The best among them was TuxPaint, which can be put into full-screen mode and allows a child to draw using a mouse. However, for my two-year old, Tuxpaint was still too difficult. My son would click on the palette or the tools by accident and it was frustrating when his paintbrush went away, or the color of the pen changed accidentally. Also, the distinction between a left click and a right click was frustrating for him. It took a lot of patience to tell him the difference between the tools, the canvas, the color wells, all the while teaching him to use the left mouse button.

So I learned Qt programming and wrote a very simple program that allows a child to draw using a mouse.  It accepts no keyboard input and treats all mice buttons equally. You click to start drawing and move the mouse to make a free-formed line. The line ends when the mouse button is released. Well, it does accept very limited keyboard input that is difficult to press accidentally. There are a few hotkeys: Ctrl+Alt+t toggles the menu-bar and there you can see the other actions and their shortcuts. Changing pen width and color is supported even when the menu is not visible. You can quit the program using your platform-specific quit keystroke.

The program borrows heavily from the Scribble example in the Qt documentation. As a result, this is a good starting point into Qt programming: the code is easy to understand and modify. As a starting point, you could try changing the initial thickness of the pen.

The source code is on github. You need an environment capable of compiling Qt applications: this is possible for Mac, Windows and Linux. You can run 'qmake && make' or you could load it up directly in a program like QtCreator. I had blogged earlier about Qt Creator, it is a freely available IDE.

Precompiled Linux binaries for 32 bit and 64 bit are available. A precompiled EXE file for Windows is also available. You need to get Windows libraries which are rather big at 20Mb. These libraries have to be kept in the same directory as the EXE file. I don't update binaries frequently. If you can, the source is the best option.

And here is a screenshot of the program in action. It looks like this on every platform.

Book Review: Merle's door

Merle's Door is a fantastic book about a man's relationship with his dog, a lovely description of the outdoors, and a rethinking about man-pet relationship. Read on to find out why.

I read Merle's Door because my wife loved it, and highly recommended it. It starts out promisingly with a story of how Ted found Merle and how they had to adapt to life together. It goes on through Merle's life and passions, and how Ted and Merle became one cohesive group.

A few ideas stick out from this book. I'm not sure these are new ideas, but this is the first book I found them. The first is the remarkable camaraderie between Merle and Ted. Not only do they enjoy each others company, but they also have a more understanding relationship.  The book is written from a dog's perspective as much as it is from a human one. At times this can get laborious as numerous online reviews point out. I understand the human urge to dislike Ted foisting human feelings on his dog. There were places where I wasn't sure what Merle was feeling and it felt excessive to force his feelings on the dog. But all writing employs some amount of guesswork of others' feelings.  In total, the portrayal was delightful and refreshing.

The only part which dragged on was Merle's last few days. Ted has written it as a painfully detailed diary, which was too painful and too detailed. I wish this section was concise, but I'm sure other readers love the detail.

This book also makes you think about the life of a dog in the city. Ted's dog had a large area he could run freely in, which is very different from most domesticated dogs. Illustrating from examples, Ted shows why a dog would be miserable in a confined area like an apartment, even if it had a generous yard.

If you have ever enjoyed playing with a dog, get this book. This will give you a fresh new perspective on what a dog's life must be like.

Book Review: Revolution in the Valley

"Revolution in the Valley" is a heart-warming account of early computer engineering in the Silicon Valley. It recounts the work of the hardware and software engineers behind the original Macintosh. Read on to find out why I loved the book.

I have read over a dozen books about the original Macintosh. I never used the original Macintosh or the Apple II but I am impressed by the ideas that those computers popularized. The book "Revolution in the Valley" by Andy Hertzfeld is the first account that I identified with. Andy was a software engineer, a co-creator of the original Macintosh. I am a software engineer as well, and I got a better understanding of the project through his narrative.

The book is a collection of stories that are online at Andy's website Folklore.org. You don't need to buy the book, but I would recommend the book for two reasons. First, the book is loosely chronologically arranged. You can see the journey as it happened, all the way till the launch of the Macintosh and the break-up of the original team.  Second, the book is filled with lovely illustrations and images of the original team and the developer's notebooks.

After reading the book, I was filled with a deeper appreciation of the original Macintosh team. They worked in a very different engineering environment, and yet produced something exceptional. It is unlikely that their success can be repeated. Making a computer today requires a lot more effort, and the barrier to entry is much higher. The Mac team was a rare combination of talent, idealism and determination that is also difficult to recreate. Andy shows you some of the design decisions and the reasons behind them. As an engineer, it was a wonderful read.

I was filled with conflicting feelings at the end of the book. I doubt I would have survived Andy's experience. They had terrible management, were poorly compensated, and were overworked.

While the original Macintosh was made during a time of bravado, I'm glad that software engineering is a much more mature field now. Software management is better, co-workers are smarter and more numerous, and the general demands of the job are better understood.

(Image courtesy: Andy's wonderful Folklore.org site)

Book Review: Embedded Android

Just finished reading Embedded Android, a book with deep technical details about the Android platform. Loved it: read my review to find out why.


A few years ago, I downloaded the Android Open Source code (AOSP) to take a look. The download took a long time, and the contents had a confusing directory structure. I could see some familiar directories, but I had no idea what the remaining code did. I understand the Linux filesystem hierarchy and kernel-user space divide and daemons. But Android had none of that, so it made it very difficult for me to transfer any of my understanding. My standard Linux skills were falling short, and the system felt strange and unfamiliar.

"Embedded Android", by Karim Yaghmour covers deep technical details about Android that no other book currently covers. Most Android books give you details about Android programming: Activity/Service/BroadcastReceiver. Karim's book answers questions such as:

1. How does an activity start up?
2. How does a package get installed?
3. Who starts the ActivityManager?
4. How can you interface with the ActivityManager on the console?
5. How does the Android system boot up?
6. Which service does what?
7. How do I get busybox on there?

Frequently, I marvelled over how clearly something was explained: like the boot process and how the init.rc is structured. Or how detailed the explanation on the build process was. And I kicked myself for not having read this book three years ago -- excusable since this book was written last year.

This book is for advanced Android programmers and Android device makers. This book is for Android programmers who understand Linux and want to see where the lines between Linux and Android blur. If you have ever downloaded the AOSP, you would benefit from reading this book.

Nothing is perfect. The editing on this book could have been better. There are some winding passages and unfocussed sections of text. And some sections could do with expanded explanation. The detailed material makes up for these minor issues. The author has laboriously dug through the AOSP code to make sense of the system, and his depth of understanding makes the book a pleasure to read.

The chapter on Android Framework (chapter 7) was brilliant. The book provides documentation for components that have none. This book explains what Android really is, and how it ticks.

Worth every penny.


(I do not receive evaluation copies of books. The reviews written here are out of my own reading, done in my own time, on my own dime. I try to read the entire book before writing a review.)

(Image courtesy: O'Reilly Media)