Tag Archives: Computing

C++

Introduction

I don’t want to start off on the wrong foot again, but I’m afraid I might have to. If you read my discussion of the C programming language you may imagine that I’d like C++. After all, C++ fixes some of C’s idiosyncrasies, adds object orientation and a whole host of new features.

You’d be wrong though. In many ways I consider C++ to be a step backwards from its parent and this piece will hopefully explain why.

The big things in life

Identifying the main thing wrong with C++ is easy when you start making a list of features. I don’t mean a list trying to identify things it does badly, but a genuine feature list, stuff like object orientation, exceptions, strong-ish typing, multiple inheritance… Well I’ve only just started, but there’s a huge list.

And that is the problem. C++ has tried to incorporate just about every interesting software engineering development that has been made over the last twenty-five years. In some ways that’s a very good thing: it allows programmers to build code in the most appropriate way which ever that way might be.

The problem is that there’s more than one way to skin any particular cat. While just about any approach is fine on a small program, one with a single developer, when you have a team writing code if there’s no consistency in approach you get the situation where no-one is able to understand the whole. There is no one head big enough.

While There’s More Than One Way To Do It is a great motto for Perl, as a language it has a very different objective. Most Perl programs are ‘hacks,’ small programs designed to solve a particular problem. C++ is a hard-core software engineering language; large teams of developers are common. The same approach used for small programs just doesn’t work for bigger systems. I can build a thousand line program at the keyboard, but a ten million line system? Anyone that thinks they can are deluding themselves. Even on the off-chance that they aren’t, other people need to understand it too. No-one is ever around for ever and no-one is indispensable (except in the case of bad management, but that’s a different story).

Counter Arguments

People often cite C++’s similarity to C as a major plus. If you’ve already learned C, then C++ is easy, right? Just a few extra commands, use “class” instead of “struct” and you’re well away. Except some of the worst C++ code I’ve ever seen has come from people who think like that. Using “//” to start your comments rather than “/*” doesn’t make you a C++ programmer!

There are, however, some benefits for C programmers using C++ compilers. They tend to be less forgiving of bad code, they often give better diagnostics and error messages. But so do Java and C#, only more so. And the jump from C to Java is probably easier than moving from C to C++.

Conclusion

If we think right back to to the beginning of the development of programming languages, we remember that they were designed to simplify things; they were designed so that you could think about the problem rather than what the machine would do.

For the audience that they were aimed at, many of the earlier languages did just that. Fortran allowed scientists to write programs (in fact it’s still being used). Cobol put a greater focus on the business than had ever been the case.

And this is where C++ falls down. Its audience is software engineers, people who write very large and complex applications. Yet its complexity actually hinders development. With a large team, “write-only” code, programs that no-one can understand once they have been constructed, become not just possible but almost guaranteed. There are so many ways of doing the same thing, so many ways to shoot yourself in the foot, that the odds of it being both bug-free and maintainable are almost zero.

C++ does have its plus points, though. It is an excellent language to show how smart you are. If you can understand the entire language and write huge, complex and error-free programs in your sleep, you are clearly much more clever than I am.

Myself, I prefer to fight the problem rather than the development language.

Eight Best Computer Books

It’s been over five years since I last told you about my favourite computer and programming related books (don’t believe the date on that article. It’s been edited lightly a couple of times since I first posted it).

Having said that, some things have not changed. The vast majority of books on the shelves of your local retailer are very specific. Publishers seem to eschew broad, generally useful texts in preference for yet another beginners guide to Microsoft Word or C++ (or, more likely, Visual C++ 2005 Special Easter Edition SP2). I do not understand this. Sure, there’s a genuine need for “how to” books for specific technologies but is it not more useful to learn how to solve problems in general rather than how to solve a particular problem with a particular product?

Worse, most are not even particularly well written. Deadlines are so strict that authors have to write quickly rather than accurately or well. Ultimately the drive to be the first publisher with the definitive guide on Word 2007 (August Edition) trumps all. One that galls me is that most programming language books assume that you are learning to program from scratch. Is C++ really likely to be your first language? I think not.

The other continuing trend is the size of them. Is it necessary for every book to be a thousand pages long and be stuffed with screen-shots? None of my favourites are like this.

As with the last list, I have not just focused on your typical “computer science” text, if anything I have shied away from them. Hopefully if you go pick up a copy of all these books you’ll find them all to be both useful and entertaining to read.

Additionally, I find most of them to be books that are worth returning to, if not as a reference guide then as something that increased experience make each read make more sense.

So, let’s get to the point. What are my favourite computer books, and why?

  1. Code Complete. If you’re writing or designing software you need this book. As I said last time, it ‘is one of those books that does the job so well it has no obvious competition. It describes the complete coding process right from low level design through to unit testing and, while most people would have been very prescriptive, McConnell outlines the pros and cons of each approach.’ Now on its second edition, it is still, as far as I know, without peer.
  2. The Mythical Man Month. People never seem to learn. Managers still seem to add more staff to already late projects. Brookes said all this, and a lot more, in this book way back in the seventies.
  3. Accidental Empires. Robert X Cringely’s history of the early PC industry is a fascinating and entertainingly written anecdote-fest. He claims neither to be complete nor objective, yet seems to cover all the bases. Since most people these days deal predominantly with x86 architecture machines I think everyone should know the heritage and how we got from Bletchley Park to an iMac. (But without the iMac as it was written years before Apple returned to form.)
  4. Professional Software Development. When I first bought this I was a little annoyed. It’s actually the second edition of McConnell’s ‘After the Goldrush,’ just coming with a different name! I’m not sure that I would have bought it had I known, but I would have missed out. This is the only book of the eight here that talks about the industry as a whole, and how we should move away from the typical, and surprisingly common, “code and fix” development. He talks about certifications; architects; heavyweight methodologies; personality types; and a whole lot more. I can’t say that I agree with every last sentence, but it’s well worth reading just to get a perspective.
  5. Peopleware. It’s amazing to think that it took until the 1980’s before the human elements of writing software were seriously considered. Even now most Computer Science seems to concentrate on the more technical aspects. This book was probably the first to discuss the “human factors” of software development and is still the best that I’ve read.
  6. Programming Perl1. I include this book at least partially because I wanted to show that it was possible to have a densely technical book that was also well thought out and entertaining. The structure is superb and I can’t think of any other programming tomes that have made me laugh out loud.
  7. In the beginning was the command line…2 I think that this is an interesting book for two reasons. Firstly it describes the reason why Unix is as it is better than any other. Secondly, it explains the various major operating systems (and some minor or — now — non-existent ones) in approachable analogies rather than dense jargon.
  8. Conceptual Blockbusting. There are few other professions where your output is almost entirely brainpower. A computer program is really little more than a slightly less ephemeral rendition of pure thought. So if you can’t think your way out of a particular problem you’re in trouble! This book makes you more aware of your own intellectual processes and outlines different ways of approaching problems. Invaluable.

As you may have noticed, many of these books are the same as last time! Does this indicate that I’ve been reading less? A little perhaps, but I’d like to think that it’s because by picking books not related to specific versions of particular technologies I’m increasing my odds of finding the classics.

What do you think? Any other good choices that I missed?

  1. This link is to the third edition. I currently only have the second. []
  2. You can also download it from Neal Stephenson’s website. []

Competitive Threat

As many readers know by now I am in the late stages of developing and releasing an iPhone application. This is the first time I’ve ever really been involved in the launch of a consumer product and while there’s nothing here that is likely to surprise any marketing guru’s, I’m finding it an interesting process.

I talked about pricing previously, but today I want to talk about the competition.

I downloaded the SDK1 shortly after the original announcement. The first version was fairly primitive, with little to no support for the drag-and-drop style of development used for parts of Mac OS X programs. I played around a bit, compiled a few demo applications but didn’t really get very far. Too hard, I though.

The beta’s came and I started having ideas for programs that I might want. Initially I thought they were too easy for a professional developer and certainly something that other people would be working on.

Turns out that I was wrong. Not only were most of the applications available on launch day very simple — tip calculators, currency converters — but no-one had thought to implement my idea.

Partly as an “itch to scratch” and partly because I had no competition, I set to work. This time rather than doodling around I had a goal. Well, a vague goal. My first attempts were too ambitious for my limited experience of the SDK and didn’t go very far.

I really gained some traction when I switched to my current scheme. All was going well until a couple of weeks ago when I saw a headline announcing my first competitor.

My first reaction was panic.

My second reaction was also panic.

It was a big deal. I’d got used to having no competition, to dictating myself exactly what features it needed to have and to thinking entirely in abstract terms about pricing. Reality intruding was hard.

I eventually calmed down enough to download a copy. Fortunately reality wasn’t nearly as bad as the simple idea of a competitor. Although unfinished, my application was already more sophisticated. It worked in a slightly different way but mine had more features, more closely conformed to Apple’s user interface guidelines and provided better feedback to users.

It did mean that I had to refine my thinking about pricing. But most importantly I had to start considering when to release it. Should I trim a few features so I could release it early? Or keep going, be a bit later but have something unique? In the end I just decided to keep going. Another “me too” product wouldn’t have managed to overcome their first-mover advantage, but extra features might.

If there’s a lesson here it’s that making the best product you can is a better use of your time than examining the competition. Happy users is the key to success and improving your software is the best way to achieve that.

  1. Software Development Kit, the program you use to write other software. []

What Price?

This originally started as a question on Apple’s support boards:

With the current AppStore model (which seems to be a money machine for developers) I do not understand why anyone would give away their applications. At least charge $0.99 and get something back for your hard work.

So, why do you give away your apps?

With the caveat that I have not actually submitted anything yet…

My motivation in writing an application was entirely for the pleasure of doing it. If I never do anything with it once it’s “finished” my goals have been achieved. So my only objective in pushing it to the AppStore is for other people to get some benefit from using it too. There is little incremental cost in doing so and zero cost means that it gets the widest possible distribution.

There are also disadvantages to charging for it. Firstly, by paying something for software users expect more. They want support and bug fixes and enhancements. Maybe they want those same things with free software but there’s less obligation. Also as a non-US citizen there are complications in getting paid the full amount due.

That’s not to say that I won’t charge for it. At the very least I would like to be able to cover my costs. By which I mean the iPhone Developer Program fee, the $99 they charge you for the privilege of deploying your own software on your own phone.

But there are complications in pricing any iPhone program.

The first obstacle is that pricing has not stabilised yet. Disregarding the loss-leaders such as the NYT reader and the Facebook program, there is still a wide variation in cost. Consider something as trivial as a tip calculator. I only had a quick look, but I found half a dozen and they ranged from free to £1.19 with most at the 59p level. I found significant variations in costs for pretty much every category I looked in.

Now the app that I’m writing is a good deal more sophisticated than a tip calculator. My initial assumption was that people would be loathe to pay for it but if others can sell a tip calculator — something you can do using the built-in calculator program — for £1.19 and still garner good reviews then surely I am undercutting myself?

But it’s also easy to price too high. As Daniel Jalkut said, “We hope to hit ‘pretty much on target’ from the start, to avoid embarrassment and second-guessing. If you price too low, you?ll have a hard time imposing a major increase.”

Another popular option is to have a paid-for version and a more limited, free version. The problem I have with that is you have to decide which features would be worth paying for without making the free version so limited that people just bin straight away. I’m not sure that there is an obvious dividing line with my application. Plus I like the simplicity of having a single version. I think it makes the “message” easier to explain — think the single version Mac OS X versus the half-dozen versions of Windows Vista — and, as an added bonus, is much easier for me to administer. I don’t have an economics background, but Joel Spolsky tells me that this is called segmentation.

There also seem to be a few cases where people are offering advert supported free versions. This is not a solution that I am entertaining. As a user I object to precious screen real-estate being taken up by an advert. As a developer I object to the extra work, uncertain income stream and the likelihood of introducing new bugs in a non-critical area of code.

In summary: the more I think about this, the more I get confused.

Just for Fun

I’ve not done much programming in the last few years. When I first started working my job was mainly to “cut code” but I’ve done less and less as time has gone by. I now tend to concentrate on high level modelling and writing small utility scripts. I have not been doing much at home either, just minor tweaks to pre-existing software to “scratch an itch” or programs to automate tedious tasks.

For something that I claim to enjoy, why have I been doing so little of it? In short, it’s hard. Writing something useful that does not already exist is an increasingly challenging task. Even if the act is fun, what’s the point of making an inferior version of a pre-existing product?1

It hasn’t always been like that.

In the olden days it was possible for one person to write a whole, useful application alone. Steve Wozniak wrote the original Apple Basic before they licenced Microsoft’s version. Matthew Smith single-handedly wrote the classic game Jet Set Willy. Even I managed to write a database application for my GCSE in Computer Studies and a graphical adventure game on my Sinclair Spectrum that at least one friend was quite impressed with.

But by the end of the eighties, software was getting more sophisticated and typically required a team. Programmers, designers and “architects” were required to make commercial quality programs. The lone, enthusiast programmer was effectively squeezed out of the market.

Fast-forward ten years and a new generation of developers were given their opportunity. Early web applications could be quickly slung together using a few lines of Perl, a rudimentary understanding of HTML and a commodity PC running Linux. I guess if I’d attended Stanford I would have been a dotcom millionaire by now2 but here in the UK I missed the boat. Just like programs on home computers had done before, useful applications quickly got far too complex for one person to build alone.

And now here we are in 2008. A few months ago Apple released the SDK for the iPhone and the possibilities are there again. If you go to the App Store you’ll see that many of the available programs play Sudoku or are thin front-ends to web-apps like Twitter or Facebook. The more sophisticated games — such as Super Monkey Ball — have tended to be ports from other platforms and so while originally written by many people were ported by a much smaller number. Sure, many applications are tiny and frivolous or just plain poor, but the barrier to entry is much lower than it has been for quite some time.

Undoubtedly the complexity level will rise over time — probably fairly quickly — but until then programming is actually fun again. I am, indeed, writing an application for my iPhone and, who knows, I might actually have something to announce in a few weeks. Watch this space.

  1. I know that for many developers the challenge is enough. I’m awkward in that I also want to be useful. []
  2. I do have a t-shirt that says, “I got £80 million for my dot com idea but now all I have left is this lousy t-shirt.” []

WordPress for iPhone

When they first announced the App Store and the iPhone SDK I thought that a blogging tool might be something worth downloading. On the first day TypePad had their application but we had to wait until this week for the WordPress equivalent. On the plus side, WordPress for iPhone is both free and Open Source.

First impressions: it’s nice. Setting up a new blog is simple. Writing a new post is straightforward too, just press the “new” button, fill in the fields much as you would in the web interface and get typing. You can also add photos — either directly from the camera or from your photo library — but only to the end of your post.

So far so good.

I’ve found four real problems so far, mostly things outside the control of Automattic, the authors.

First is that I have not found a way to view drafts that have already been saved on the server. iPhone side drafts are visible — making it possible to work without cell tower reception — but I often have a dozen unfinished articles sitting on the server. I don’t want to write everything on the phone.

Secondly, if you use anything other than the standard picture uploader, you’re on your own. I usually use Photopress.

Next, I found that the “Preview” — useful feature incidentally — and “Photos” buttons at the bottom the screen occasionally go missing.

Finally, well, best to to by example. Go back to the start of this post and count the number of links.

Back? Presumably you found no links, not even to WordPress for iPhone itself. And that’s because there’s no way to get a URL from Safari into WordPress other than by remembering it or writing it down.

Of course, Apple failing to include cut and paste in their operating system is hardly Automattics fault.

Overall I like it. It’s failings are not great enough to put me off, especially considering the types of post I am most likely to write on the move. It’s certainly earnt a spot on my home screen.