Thu, 10 Apr 2008

BMW E30 Track Car For Sale

I’ve finally decided to sell my E30 track car (in action above). Please have a look at this detailed announcement with all the information you could ever want to know.

Posted at: 17:23

Path: /cars   |  permalink

Fri, 21 Dec 2007

Xmas Parking Perfection

At this time of year, pressure on parking spaces at Indooroopilly (and no doubt other shopping centres) gets pretty intense. But this morning there were a few spaces available in the reserved parking outside the post office for people to use when collecting their mail from the PO boxes there.

Even so, the hero of this story felt that the effort of parking her tiny car in a marked space was too much, so she just stopped in the roadway, locked her car and dashed across to get her mail. By the time she had the box open, both owners of the cars she had blocked had arrived at their cars and were looking a bit irritated to see they had no way out. However, everybody relaxed as the pest dashed back to her car with her mail.

This was when she discovered that she had managed to lock her keys inside the car. She had also locked her phone in there with the keys. So she then borrowed a phone from one of her victims, eventually worked out what number to call for information, got the number for RACQ, called them, waited for a bit and finally reported that they would be there—probably within an hour to an hour and a half. The trapped owners were as ecstatic as you might expect. All the cars that had to squeeze past were looking unhappy. And I had emptied my PO box by then, so I went home.

Posted at: 10:21

Path: /cars   |  permalink

Wed, 08 Aug 2007

Code Craft falls down hard

I know it’s not possible to write a big book without having any errors fall through the cracks, and I don’t make a habit of public excoriation of people for things that can be forgiven — but there are unforgiveable things.

Take Code Craft by Pete Goodliffe, published by No Starch Press as an illustration. Here we have a 580-page tome dedicated to the practice of writing excellent code and on page 13 it has an egregious example of unforgiveable content.

Before getting to the details, I would mention that neither the book nor the website give me any information that I could find in a reasonable amount of time about how to report errata. Had there been such an avenue, I’d have taken it. As it is, this seems the easiest approach.

This is in Chapter 1, On the Defensive, subtitled Defensive Programming Techniques for Robust Code. Under the heading Use Safe Data Structures, he gives the following example of some C++ code:

    char *unsafe_copy(const char *source)
    {
        char *buffer = new char[10];
        strcpy(buffer, source);
        return buffer;
    }

He then gives the correct explanation of the problem with this code when the length of the string in source exceeds 9 characters. After some discussion, he then says it’s easy to avoid this trap by using a so-called “safe operation” and offers this idiotic solution:

    char *safer_copy(const char *source)
    {
        char *buffer = new char[10];
        strncpy(buffer, source, 10);
        return buffer;
    }

In case the reader doesn’t know how the C string library (which is what is being used here, despite the otherwise C++ content) works, let me point out that strncpy is guaranteed not to solve the problem under discussion. The strncpy function will only copy at most the specified number of characters, but — in the critical case where the source string is too long — it will not add the very important NUL-terminator character. And so users of the returned buffer will still fall off the end of it and cause breakage.

Every C or C++ programmer who has been paying attention knows what is wrong with the C string library and knows how to use it correctly. So an error of substance like this should simply never have happened. It’s not a typo. It’s not a trivial error. It’s just plain wrong. And there’s no excuse for it.

I’m sure the author has many good things to say in this book and many of the sentences I have skimmed certainly do make sense. But stuff like this makes it impossible for me to suggest that it has any place on the budding programmer’s bookshelf. That’s a shame, because we need books that do what this book purports to do.

What irritates me most about this is that none of the book’s reviewers spotted this glaring error and none of the online reviews that I found noticed it either. This means that nobody with even a tiny clue has been looking at it.

Posted at: 10:52

Path: /software/discuss   |  permalink

Wed, 04 Jul 2007

Python 3000

About three years ago, I announced my plan to move away from Python for future development work. I returned to that theme twelve months ago in a couple of posts about recent experiences with Python.

It seems time to update things now. I have just been reading Guido van Rossum’s Python 3000 Status Update in an attempt to understand what the future holds for Python.

Clearly, the Python people have decided to make major changes to Python, such that software written for Python-2.x will need work if it’s to be expected to run on Python-3. Equally clearly, a great deal of work has gone into creating mechanisms to assist programmers with the necessary translations when the time comes and that’s something I applaud.

However, I have long been unhappy with Python’s continual introduction of what I see as gratuitous changes and have been looking at alternatives. Now seems like the time to jump ship. My plan now is to do some serious testing with alternative languages so that—when the time comes for me to write some new thing—I will be ready to do it in some non-Python language.

This post is just to mark the point where that decision was finally made and to link to the Python 3000 paper that marked the tipping point.

Posted at: 17:02

Path: /software/discuss   |  permalink

Wed, 30 May 2007

A new approach to spam filtering

About three years ago, I first considered DSPAM as a potential solution to the incoming tide of spam that was drowning me and that was increasingly overwhelming SpamAssassin, my then tool of choice. I wrote a couple of blog entries that discussed my research and included references to papers by Jonathan A. Zdziarski (the author of DSPAM) and Gordon Cormack (who, with Thomas Lynam, wrote an evaluation of anti-spam tools). I also mentioned some of my discussions with both Zdziarski and Cormack and said I would report more when I had more information.

Much time has passed and the spam problem has, as we all know, continued to get worse. Last December, having become completely fed up with the worsening performance of SpamAssassin, I decided to install DSPAM for testing. I elected not to bother training it, but allowed it to do its thing and contented myself with informing it of its errors. The downside was that I had to look at every incoming message, whether spam or not, to be sure of the classification. I have examined 82,931 messages in the last five months and I’m amazed at how well DSPAM works.

Overall, it has caught 98.92% of all spam and its false positive rate has been 0.02%. Most of the errors were in the first and second months while it was learning. Now, it is catching over 99.2% of spam with a false positive rate below 0.01% and there have been no false positives at all for a couple of months. For my wife, the learning was a little slower because she receives much less total email than me and her legitimate email volume is so small that it’s a bit of a challenge to get enough for training. However, even in her case, the detection rate is up to 98.90% and false positives have also disappeared.

I was going to modify qmail to reject messages that were deemed to be spam, but I’ve decided that it’s too much work, given the ickiness of the qmail code and the excellent performance of DSPAM. I also toyed with the idea of changing MTA, but I have not found an MTA that I would be willing to use that also has the ability to do what I want. I may one day decide to write my own MTA for in-house use, but for now I’m going to stick with qmail and the other modifications I had made to it in the past and—starting right now—I’m going to stop my practice of reviewing incoming spam in case any legitimate email is lurking there.

In other words, from now on, if anybody emails us and DSPAM thinks it’s spam, nobody will ever see the message. There will be no bounce, there will be no error message, there will be no sign that the message was lost. But it will be irretrievably lost. I have decided that the time spent on reviewing the spam is not worth the rewards, when the chances of finding a real message seem to be less than one in a million now. This is especially true when it’s also true that anybody who might need to contact us and who we would care to hear from has other methods of doing so.

I am really delighted to have got to the point where my spam load consists of hitting ‘S’ once a day to tell DSPAM about something it has missed.

Posted at: 14:46

Path: /software/discuss   |  permalink

Fri, 20 Oct 2006

Software quality

It’s hard to find examples where the two words in my title belong together. People of all kinds–users of software, software developers, and those who teach the next generation of developers–have been pontificating about both the problems with software and various approaches that might help to solve the problems for decades. But, as a general rule with almost no exceptions, software still sucks. And it’s getting worse, not better.

Anybody who happens to read this already knows that software is a problem since they have to be using quite a bit of software just to be reading a blog–and it’s my contention that just using software is enough to drive you to drink.

I’m a software developer, so I am fully aware of the difficulty of creating high quality software. It is indeed difficult to produce software with no bugs and, for most software, it’s probably impractical–or at least not worth the cost. But that’s not to say that the quantity of bugs in the stuff we all have to deal with every day is justifiable.

Here are a couple of examples from some of my appliances. I have a DVR. It has a 60G hard disk and a DVD writer. And it doesn’t have to do much. So why does it take 30 seconds to boot up? Why does it have to boot up after making a recording? Why can’t I set it to record something that starts less than five minutes after the previous item? Why can’t it sort titles alphabetically using the same rules as anybody else?

To elaborate on the last point, as it’s a classic example, consider the following list of titles:

• Apple
• Apple Tree
• Azimuth

That’s sorted in the way that any sane person would expect. Getting software to sort it that way is child’s play. The Unix sort program will sort it that way by default. So what does my DVR do? Behold:

• Apple
• Azimuth
• Apple Tree

I’ve had enough time to study its behaviour now, so I can choose titles for things that it can sort the way I want–but it’s completely crazy that I should ever have been driven to think about this. I don’t want to belabour the point about this one appliance too much, so I’ll limit myself to one other bizarre fault. It has, as I mentioned earlier, a 60G disk. So it can store quite a number of off-air programs for viewing at more convenient times. Well, it could do that if it didn’t have a limit of 7 recording slots. That’s right–seven. The first VCR I ever owned, more than 20 years ago, could be programmed for more than seven recordings.

I’m sorry, I lied. I’m going to mention one more thing about this device–because it’s faintly possible that this is a deficiency in the hardware rather than the software (not that I believe that for a minute). The advertising material and the manual for my DVR claim that it can copy between media at accelerated speed. That seems to be a reasonable capability, given what we know about other such equipment, so I expected it to work. But it doesn’t. Copy an hour of video from the hard disk to a DVD and it takes exactly one hour. Copy an hour of video from a DVD to the hard disk and that also takes exactly one hour.

And, for another instance that might be hardware but probably isn’t, consider the fact that it makes DVDs that quite likely can’t be read by at least a few of the 8 other DVD readers in the house. Sometimes, to show just how clever it is, it can make a DVD that it can’t read itself. And when that happens, the only way to get control of it again is to remove the power and physically remove the offending disk.

That device has a flotilla of other hideous bugs that make it a nightmare. My wife just leaves it to me to drive it. She is pretty smart.

Now, let’s turn to my phone. No, let’s not. At least, not beyond mentioning that it’s slow and as buggy as hell too. Having once worked as a consultant for one of the mobile phone manufacturers–where my task was to teach their programmers C and to help them with some of the interesting bits of their software–I’m not surprised to see that this phone has software that I wouldn’t spit on.

The trouble is that software is ubiquitous in our world. Even if you never touch a thing called a computer, you can’t escape it. So you’d imagine that we–the software creators of the world–would have figured out some of the basics of making software by now. But we simply haven’t come close. And nothing I see in our tertiary institutions makes me think that’s about to change all of a sudden.

One of the good things about the world of software is Free Software. (For anybody who doesn’t recognise why those two words were capitalised, have a look at this definition for some insight.) Sadly, the Free Software people are at least as bad as the rest of the software community when it comes to quality. The Free Software crowd have a bunch of silly slogans written by would-be philosophers without much insight such as the famous “Given enough eyeballs, all bugs are shallow”, usually attributed to one of the worst poseurs in the community.

The problem is that bad software is much easier to get done than good software. Of course, if you consider the subsequent investment of time by the software authors while they try to address the worst bugs, then the apparent speed of the favoured method seems less of a sure thing. And, heaven forbid, if we considered the time lost by the unfortunate users of this software, then the equation becomes ridiculous. Time spent on whatever process we can find that results in fewer bugs going into the product will be amply rewarded. And, as many people are now showing, it is almost certain that taking the time to get it right in the first place will be quicker than rushing bug-infested rubbish out the door–certainly once the developers have had time to become established in this new pattern of work.

Just as I avoided listing brand names of my appliances above, I’m not going to single out individual pieces of software for criticism here. But it’s pretty safe to say that any high-profile piece of software is almost certainly riddled with thousands of maddening bugs. And the bigger the software, the worse it will be, for reasons that will be obvious.

As a final comment on the sad state of things, I’m going to look at the state of programming languages–again without naming names. I’m not talking about the suitability of our languages for developing great software, although that is indeed an important matter. I’m just talking about the woeful state of the software in the interpreters and compilers themselves. I recently acquired a 64-bit computer, not so much because I needed the extra capabilities it had, but to use as a platform for me to use to weed out any little buglets in my own code that might be exposed by a 64-bit machine. As it happens, I have not found any. But I have been amazed at the number of languages that I wanted to use in my testing that are simply not able to run on a 64-bit platform, despite the fact that 64-bit systems have been around for years. And not to mention all the other applications that are not yet available for my 64-bit platform. This is really sad.

And it’s so bad that, in the next few weeks when my operating system comes out with its next release, I’m going to install the 32-bit version on my workstation so that I’ll be able to use all the stuff I want to use.

I’ve been working all my life at continuing to improve the way I do things. I will keep doing that. I’m happy to talk with people about ways of improving software. And I really think it’s way past time for the software development community to get off its collective butt and to start looking hard at injecting quality into software.

Posted at: 17:35

Path: /software/discuss   |  permalink

Thu, 31 Aug 2006

Another Apple recall

Shortly after I got my Powerbook, just over two years ago, Apple recalled its battery because of some fault that I no longer recall. This week, I discovered that the replacement battery is now subject to a recall. So I have to order my replacement, wait for six weeks for it to become available, respond in person within 48 hours of being informed that my new battery is ready and take care in the meantime not to leave the machine on with its battery installed unless it is under supervision. That’s a pain. It’s a bigger pain that I’m looking at a recall for the same component that has been recalled once already. I just wanted to whine on the record.

Posted at: 16:20

Path: /technology   |  permalink

Tue, 29 Aug 2006

Lying to customers is so easy

A couple of years ago, I wrote about a customer of mine who had problems with their ADSL provisioning. For much of this month, the same customer has had further problems with the same so-called service.

The trouble started around 11 August when their ISP performed some unspecified maintenance on the ADSL services in the region where my customer has their offices. In the middle of the night, their connection went down. They complained to the ISP, who promptly blamed Telstra. Neither the ISP nor Telstra wanted to do anything about the problem.

After some days, and several followup calls, the ISP stated that the problem was definitely in the customer’s ADSL modem. The customer shipped the modem to me. I plugged it in as a replacement for a different breed of ADSL modem attached to a computer running the same OS and ancillary software to connect to the same ISP and it just worked. Clearly, the problem was not the modem. To be on the safe side, I then performed a hardware reset on the modem, reconfigured it as required, and returned it to the customer. It did not solve the problem.

The customer then tried to insist on some service from the ISP, but found things difficult when the ISP made it clear that they do not do house calls under any circumstances. Eventually, the ISP told the customer that they would check the modem if the customer attached it to a Windows computer and followed instructions. The customer sourced a Windows computer, plugged things in as required, followed instructions (including another hardware reset of the modem), and then the ISP said, “There, that’s all it needed; we just had to fix the modem and now it’s fine.”

It’s clear enough to me that they did nothing to the modem (beyond getting the customer to break its configuration for our purposes) and instead finally got around to fixing whatever they had fucked up at their end. Of course, this meant that the modem still didn’t work when returned to its normal position and it was returned to me to be reconfigured a second time. When it finally arrived back at the customer premises, it was plugged in, powered up and just worked.

By then, it was the 24th. So they were off the net for two weeks. There was no apology from the ISP. There was no offer of any reduction in the exorbitant monthly service fees they charged. The ISP lied to their customer and stuck to their lies. I’m not going to name either the ISP or the customer, as the argument is between them and it’s none of my business—other than as an astonished bystander. But I will certainly recommend against that ISP if people ever ask me for my opinions about possible service providers.

Posted at: 17:26

Path: /technology   |  permalink

Sat, 15 Jul 2006

Further thoughts on Python

I posted an article recently that took a swipe at the direction of Python development. Had I realized that it would be seen by people on the Python developers list, I’d have phrased things differently—I treat this blog as a private repository of my thoughts about various things and assume it will be mostly read only by people who know me. This post is intended to explain my position a bit more clearly and to take into account some of the responses from the Python developers.

I’m going to start by outlining my position and my expectations so that those people who seemed baffled by my stance can have a better opportunity to understand this stuff. Then I’m going to discuss a small fragment of the responses on the mailing list. And I’ll finish up with my thoughts about the future.

At the outset, it would be useful to understand that there’s nothing personal in anything I say here—I’m simply stating my take on things. I know I’m far from a typical Python user, and I’m certainly not trying to suggest that everybody should do things my way or even agree with me. Although I would hope that people would agree that I’m entitled to hold my own opinions.

I’ve been developing software for commercial clients for about 25 years and some of the code I wrote twenty years ago is still in daily use in business environments. I take a lot of care to make my software into a stable and useful tool that allows its users to conduct their normal processes in the way they want—I do not believe that customers should twist themselves in knots to adapt their way of doing things to the software that somebody tosses on their lap.

Sometimes, this whole process is straightforward. The customer has a stable hardware platform and I provide stable software and their process undergoes minimal change—and their entire platform is isolated from the big bad world. In these cases, we might see the same old hardware running for 15 years or more with unchanged operating system and application software. Nothing will go wrong there.

In other circumstances, customers run their business processes on systems that are exposed to the Internet and need to keep their operating system and basic utilities up to date in order to avoid exploits. This can result in unexpected updates of things that my software might depend on—such as a new version of Python or, to take another real example, an updated Unix C compiler that introduced a gratuitous change in the format of floating point values that resulted in a database where all values were suddenly multiplied by 4.

Since I use a large number of software packages on my systems (over 500 at present), it’s completely impossible for me to keep fully informed about all the evolution that goes on in all of them. I am a contributor to a small number of free software projects and I do take seriously my responsibility to test them. But I just can’t do that for everything I use if I am also going to do my day job. So I have an expectation that my tools won’t introduce gratuitous change into my world.

What puzzled me about some of the responses on the Python developers list was that people felt entitled to take a swipe at me for expecting bug free software, despite the fact that I had clearly explained that I was not complaining about a bug—all software has bugs and I understand that they must be fixed when found. My complaint was about a change in behaviour from a function that had no bug in it.

Fortunately, Guido van Rossum (the Python benevolent dictator) is a lot smarter than the chief Perl weenie and knows how to read for the real content. He recognised that the issue I was complaining about was something that had bitten him in the past and he requested that it now be fixed. I understand that a fix is scheduled for Python-2.5 when it comes out.

I understand the desire of the Python community to continue to develop their language. (I think they’re wrong, but I’m in a tiny minority and I have no intention of trying to convert the majority to my opinion.) What I find problematical, however, is their willingness to break working code as part of this process. I complained the other day about the change in behaviour of time.strftime(). I was previously bitten by the bizarre change to the fcntl interface. Where once you had to import FCNTL, fcntl and then used a constant called FCNTL.LOCK_EX (as one example), things changed so that the FCNTL module disappeared and the constant changed to fcntl.LOCK_EX. I never bothered to discover the official reason for this change, but I stick to my view that it was completely unnecessary.

It’s one thing to extend the language and its support libraries. And I have no argument with that at all. And it’s fine to fix actual bugs in the existing code. But making changes that are guaranteed to break existing correct code is just insane, as far as I’m concerned.

As another example of inexplicable change, I would mention the change in meaning of the division operator. It doesn’t matter if, in hindsight, you see that it would have been nicer to do something differently—once people are using your language, you have to leave it alone. Or else they will do what I’m going to do. I’m going to lock my customers into Python-2.3 for now and then I’m going to migrate all my Python code to a language that doesn’t go in for this kind of breakage.

Ironically, had I used awk for the software in question, I’d have had no problems at all. But Python was new at the time and arguably nicer to write and had two minor but useful features that were missing from awk, so I decided to develop a collection of software using Python. I don’t regret doing that, but it’s definitely time for me to move on now. That’s not just because of the small number of issues that I’ve discussed here, but because of the looming arrival of Python 3000 which sounds like far too dramatic a change for me to want to keep up with it. If I have to deal with that level of change, I’m going to be far better served by choosing a more stable environment for the future work.

Posted at: 12:09

Path: /software/discuss   |  permalink

Sun, 09 Jul 2006

Python loses the plot

In Python’s early days, I saw it as a fine addition to the programmer’s toolkit—it seemed to offer the good things that Perl offered, but without the gruesome syntax and other Perl perversions, and the Python benevolent dictator and community seemed to have a good plan for the future.

As a result, I began developing most new large applications in Python, with the occasional bit of heavy lifting in C as needed. This approach worked well for some years. But then the wheels slowly started falling off—and yesterday’s experience has pushed me to the point where I’ve decided not to use Python for any new development. This leaves me with a dilemma, of course, as I don’t have any suitable candidate for a replacement.

So what’s my beef? In a nutshell, it’s gratuitous changes that break code that was once correct when it’s exposed to a newer Python release. This disease has afflicted Python for some time, although I have been lucky enough to have only been bitten once before. Yesterday was my second experience with this kind of breakage and I’m going to make it my last.

For those who care, the behaviour of time.strftime() changed in Python-2.4 in a really silly manner. I have a module that asks the user for a date and then parses the elements of the provided date to ensure that we in fact have a valid day, month and year. I then used time.strftime() to format it in a specific manner. Because I only had 3 of the possible 9 elements of the argument passed to this function, I had been using what used to be the documented values as place holders. As of Python-2.4, that is suddenly no good.

Clearly, I can work around this. But then they’ll break some other standard function that I’ve been using and I’ll have to work around something else. And so on. There is no legitimate excuse for this kind of arbitrary change. It’s impossible to code in such a way that you won’t be bitten, and there’s too much new software coming out every day for developers to have the time to waste reading all the fine print just in case some idiot has broken some standard API.

My interim solution is to change the first line of all my scripts from #!/usr/bin/env python to #!/usr/bin/env python2.3 and, in the longer term, I’ll find a suitable alternative language to work with. I’m certainly finished with Python.

Posted at: 16:50

Path: /software/discuss   |  permalink

Wed, 05 Jul 2006

Consistent errors with prescription medicines

I wonder what is the cause of the consistent errors I have seen with pharmacies dispensing the wrong medication or the wrong doses of the right medication in the past nine months? I’ve never seen either kind of error until recently, but the last few months I’ve been given something wrong four times out of five—not just at the one pharmacy and not just the one person when the error has been repeated at the same pharmacy.

It’s not a result of the infamous doctor’s bad handwriting, as these prescriptions and their repeat authorities have all been nicely computer generated and printed. Whatever the cause, it’s a worrying trend.

Anyway, for what it’s worth, I strongly urge everybody to be vigilant in checking that what you receive is what you expected to receive.

Posted at: 13:58

Path: /society   |  permalink

Tue, 30 May 2006

Native driver for nVidia NIC saves the day

As distributed, FreeBSD for the AMD64 platform comes with a rather dodgy driver for the on-board nVidia nForce MCP NIC that appears on many motherboards for this CPU. In my case, the symptoms were trillions of device timeouts and weird unresponsiveness under Gnome and bizarre keyboard malfunctions—lost keystrokes and occasional cases of keys repeating hundreds or thousands of times.

Some research quickly established that these issues were well-known and that there was a revised version of if_nve.c that was supposed to address these concerns. Unfortunately, simply replacing that file with the updated version resulted in a kernel build failure, as other stuff was required. Since that other stuff was supposed to live in a directory that doesn’t even exist on my machine, I decided to try plan B.

Shigeaki Tagahira has developed a FreeBSD native driver, based on the OpenBSD driver. Today, I built that and patched my kernel with his ciphy patch for the Cicada PHY and am pleased to say that the odd behaviour I was seeing now seems to have been cured. This is great news.

And yes, this is a bit boring, but I wanted to record the essential data in case I blow away my installation and forget how to rescue it. Aren’t blogs wonderful?

Posted at: 18:28

Path: /software/discuss   |  permalink

Fri, 26 May 2006

Rewrite it or fix it?

I’ve been reading Adrian’s series of articles on XP with considerable interest. I’ve found it interesting to see how somebody I know has got involved with this approach to software development and I’ve felt that there were lots of good lessons there.

But I was a bit taken aback by something in a recent entry, Framing The XP Principles:

Netscape has all but gone out of business because of one bad technical decision to rewrite their entire browser instead of taking small steps and fixing the existing one.

Now, before I launch into my speculations here, I should point out that I’ve never worked at Netscape and I’ve never worked on any of the Mozilla products—although I have occasionally skimmed parts of their source code. So what follows is purely my guesses, based on what I can see from outside.

On the other hand, I have worked on a number of big projects where a decision was made to throw out some existing implementation in favour of a complete rewrite—and I’ve seen such projects succeed.

I am satisfied that the old Netscape code base was rubbish. I am also convinced that it would have been insane to attempt to fix it. Where I think Netscape went wrong was in failing to learn anything from the first time through. From where I stand, they seem to have embarked on another gigantic piece of junk without getting hold of the right people or developing a sensible plan. It’s clear to anybody who uses or who has the misfortune to need to build something like the current version of Firefox that this new code is pretty nearly as bad as the old code. Of course, it is better—but not significantly better. It’s much more like the old rubbish than like something that we’d all be proud to be a part of.

I have no way of proving my point, of course. And I don’t care that much about the specific case. And I certainly agree that it’s better to refine a code base as a general principle rather than to automatically throw it all away. But I think it’s important to recognise that there are real cases where it is better to discard even a huge code base than to get lost in a vain attempt to “fix” it.

Naturally, if the decision to rewrite is taken, it should only be done if there is a clear commitment to first learn the lessons from the failed implementation and to create a design and a methodology that have a reasonable likelihood of success.

Having said that, I now await Adrian’s next instalment with interest.

Posted at: 17:37

Path: /software/discuss   |  permalink

C is harder than it looks

I recently saw a nice example on a mailing list of the kind of problem dilettantes run into when they play with C. The coder naturally failed to show what he’d done, but described his problem in terms of “what’s wrong with the implementation of sockets in this operating system?” and went on to describe an impossible scenario. This led to a variety of responses from people who like to be seen to be able to help and don’t strongly feel the need to be right.

It was pretty obvious that the original coder had made a standard beginner’s mistake with C syntax and had compounded his error by failing to turn on warnings in his compiler. In essence, he claimed that the socket(2) call would return a descriptor that was already in use because, after opening his socket, data written to the descriptor would appear instead on the standard output.

Fortunately this was seen by somebody who actually knows C in time to stop too much silly speculation. This guy suggested that the coder must have done something like:

    if (sd = socket(AF_INET, SOCK_STREAM, 0) != -1) {
        /* do stuff */
    }

That code will always assign the value 1 to sd, except for the rare case where it’s not possible to open a socket (in which case the reader, having been alerted to the error, will now know what value it will get). Had our coder turned on compiler warnings in gcc, he would have been told, “warning: suggest parentheses around assignment used as truth value” which might not have been enough, but would have suggested that he needed to get help.

Real C programmers have that extra set of parentheses burned into their fingertips and don’t need to think about them—and, on the rare occasions when they do forget them, know instantly what that warning means. And real C programmers always run their compilers with all warnings turned on.

Unfortunately, too many people take a quick look at C, see something quite simple, and decide that they can safely work with it. It is indeed a simple language, but it’s also a demanding language that provides no training wheels for learners. It takes time to really understand it and it takes regular practice to make good use of it. It’s my opinion that the time required is well spent because you then have a very powerful tool at your disposal—but, like all powerful tools, it can hurt the unskilled operator.

Posted at: 17:00

Path: /software/discuss   |  permalink

Thu, 18 May 2006

The joy of supermarket queues

There’s something about queues in supermarkets that seems to bring out gloriously aberrant behaviour in what otherwise appear to be normal people.

Read the entire post ...

Posted at: 11:44

Path: /society   |  permalink

Wed, 17 May 2006

AMD experiment

I thought I should mark this blog’s arrival at the ripe old age of two years by writing something. The last couple of weeks have been filled with computer hardware dramas—ranging from the ongoing flakiness of my Powerbook (now revealed as largely the result of a dead disk) to the sudden catatonia of my main workstation.

I’ve been thinking about moving to a 64-bit platform for a while, not so much because I need the performance but because it seems like a good idea to expose my own software to any possible bugs that might be revealed by the change. And since FreeBSD, my preferred operating system, now treats the AMD 64-bit platform as a tier 1 (i.e., fully supported) platform, it seems like a good chance to try out some new gear in the form of an AMD Athlon 64 X2 Dual Core 3800+ CPU.

Somewhat to my surprise, after a simple and very fast system install, I ran into trouble with ported applications—normally one of the strengths of FreeBSD. For a large number of things I wanted to install, my attempts were met by messages chiding me for trying to build something that was i386-only on an AMD platform. This list includes big things like OpenOffice (apparently because it depends on Java, which is also i386-only) and small things like the Darcs revision control system. That was all pretty irritating.

There are claims that one can run i386 binaries on the FreeBSD AMD64 platform, but my early attempts to do that with pretty trivial programs have not met with any success so far. So I don’t hold out much hope for monsters like OpenOffice.

Since the software issues looked like being slow to resolve, I thought I should at least get as much as possible of what I had already installed going. And that led to an attempt to start X11. What a mess that turned out to be.

I stupidly thought I could use the Xorg server’s -configure option to create an initial xorg.conf file. It created the file OK. But any attempt to run it with that config file resulted in a machine that was so badly locked up that it even ignored the reset button and required a power cycle before it returned to service. And this all happened so fast that it didn’t write anything in any log files, so there was no clue about a solution.

Having proved that this behaviour was completely repeatable, I then tried the old text-mode xorgconfig program. I gave the obvious answers to all the questions, created the xorg.conf file, started X and all was fine. Why this was the only way to get there is beyond me.

In the next few days, I expect to get most of the software I use all the time running on the Athlon box and to start using it for my work. I’d be surprised if that all turns out to be plain sailing, and expect to revisit this topic over the next few weeks.

Posted at: 14:07

Path: /technology   |  permalink

Thu, 27 Apr 2006

Customers can drive you to distraction

Everybody who deals with customers knows that my title is a truism, but sometimes it can be interesting to examine a case.

Recently, I told the story of a customer who was in a state because the power went out suddenly and they had been seriously inconvenienced as a result of lying to me about having finally got all their equipment protected by UPSes. Yesterday, they arranged for the electricians to come back to do properly what had been arranged so long ago. As instructed, they shut down everything while the electricians were on the premises.

Late this afternoon, they finally rang me to ask what I was doing about getting everything going again. I was waiting to be told the electrical work had been done. They said they had emailed me yesterday. I asked why they had not followed up, or at least checked that the email had left their systems. This upset them, so I let it go, beyond telling them that they knew how to do these things and that they also knew how to check that their ADSL modem was functioning—which it wasn’t.

To cut a very long story short, they said they were desperate to have all their machines running now that the UPS stuff was in hand. (I had told them that I’d only sanction one machine running until the work was done, because that one machine was indeed on its UPS.)

So I said that we now needed to get a lamp or something else that didn’t draw too much current and go around to check that the new outlets were really connected to the UPS. At this point the customer went ballistic, saying that they’d already spent three days with most of their computers unavailable and they just couldn’t spare the time to do this silly checking. Of course, the sole reason they had a problem was their earlier refusal to follow the agreed plans and get all the machines protected by the various UPSes that sit there in their building for that purpose.

I then said, “OK, if you really want to power up the machines without us first checking the electrical work, all you need to do is to sit down for a minute and write me a quick email stating that you are happy with the electrical work and that you take full responsibility for anything that may happen in future if it turns out that the work was not done right.”

“But that’s not fair,” protested the customer. So I explained that what wasn’t fair was the fact that they expected me to drop everything and jump through all kinds of hoops because they refused to follow my advice. I said that they could get the machines running in a couple of minutes if they sent me the email.

And then, surprise! They decided that I’d better step one of their staff through the process of testing the wiring after all. This time the job had been done right, so now all their machines are humming away and I can be comfortable that the next power outage won’t result in me having to spend hours solving problems that should never happen.

Of course, the owners of the business have gone home in a snit and they will be even more cranky tomorrow when they tell their staff to chase me up about other things that were put on hold while the crisis was fixed—as I told the staff who stayed behind to sort out the UPS testing, tomorrow is my wedding anniversary and I just won’t be willing to take their calls.

Posted at: 17:18

Path: /software/discuss   |  permalink

Fri, 21 Apr 2006

That went well

Got a call in the car this afternoon, with a customer in a panic and Friday peak hour traffic buzzing about me. Their building managers had announced they’d be “working on the power” over the weekend and gave them twenty minutes to prepare. According to the customer, they then immediately cut the power. (Based on what happened later, I think they probably got the twenty minutes and failed to act promptly.)

But not to worry, since they had finally got around to doing the necessary wiring and now all their equipment was protected by their UPS devices. So I commented on their good fortune. And then discovered that they’d lied. Perhaps the wiring was done but they hadn’t moved the machines over, or perhaps I’m going to find out next week that the wiring wasn’t done at all. In any case, the machines were not protected by the UPS boxes that are sitting there humming away in their offices.

Since it was Friday and since the building’s power will be on and off over the weekend, I told them to run around the offices immediately and yank the power cords from every bit of equipment and then call me back. I stressed the “immediate” bit several times.

When they called back, about fifteen minutes later, they asked if they should keep pulling the cords now that the power was back on. Clearly, “immediate” had a different meaning for them than it has for me. Eventually, as the power went out again, and the machines all went down again in the middle of starting up, they got around to pulling the power cords.

I told them we’d sort things out on Monday morning. Fortunately, they’re in the same time zone as me. But they have a shock coming. We’re going to get one machine, their main server, running and we’re going to prove that it’s connected to its UPS. And that’s all we’re going to do.

I’m going to explain that none of the others will go back into service until they are connected to a UPS. And I’ll make it clear that I will be able to verify this and that the deal is absolutely non-negotiable. We have stuffed about for years over this issue and I’m just not going to be the idiot who runs around in a panic because they are too lazy or too pig-headed or too stubborn about what they imagine are their own priorities to manage something so simple and so essential to their own well-being.

They are going to be angry with me on Monday. That’s OK with me. But this time I’ve been handed a lever to use to make them do the only sane thing and I’d be remiss if I failed to get something done.

Posted at: 21:08

Path: /software/discuss   |  permalink

Face Time and Free Stuff

I am frequently asked questions by other software developers about the issues one faces in the process of moving away from a job into the scary world of running one’s own business.

Today I saw a nice post by Christopher Hawkins of Cogeian Systems entitled Face Time and Free Stuff. You’ll have to scroll down a bit to get to it, as he seems to have combined two posts in one permalink for some reason. I think he has a lot of good ideas there and I recommend it to all the people who have been asking me questions.

Posted at: 11:27

Path: /software/discuss   |  permalink

Bunnies and glitter

Was it the pink Playboy bunny or the glittering earrings that first got my attention?

Read the entire post ...

Posted at: 09:59

Path: /cars   |  permalink

Fri, 31 Mar 2006

An unsent letter

As he did so often in life, my father thwarted me in death. Of course, that was not his objective and I suspect he would be surprised if he could hear me make that claim. Our 47 shared years involved, on my side at least, a great deal of pain followed by a significant period of estrangement and ended in a rather drawn out truce.

Read the entire post ...

Posted at: 16:24

Path: /family   |  permalink

Tue, 28 Mar 2006

Lakeside revisited

I had finally got used to the idea that I’d never get another chance to drive on the Lakeside circuit, but yesterday brought a wonderful opportunity to go out and play—for the first time since 1999.

Read the entire post ...

Posted at: 17:06

Path: /cars   |  permalink

Fri, 24 Mar 2006

Full feed without the seemore plugin

Somewhat to my surprise, some people don’t want to be saved from having to see the full text of my posts in their RSS feed by the graces of the seemore plugin.

Read the entire post ...

Posted at: 16:40

Path: /meta   |  permalink

Respect must be earned

I offended a customer today by failing to show respect for some really appalling software.

Read the entire post ...

Posted at: 16:26

Path: /software/discuss   |  permalink

A change of heart

I was going to write a detailed post explaining how Leon Brooks was completely wrong in his rant in response to my brief post about Muslim Australia.

Read the entire post ...

Posted at: 16:26

Path: /society   |  permalink

Goodbye to Technorati

Nothing like being interrupted at exactly the wrong moment to give me a nice opportunity to look like an idiot. Here is the content that was supposed to be attached to this post when it first appeared.

Read the entire post ...

Posted at: 16:26

Path: /meta   |  permalink

Tue, 21 Mar 2006

An atheistic manifesto

While I’m at it, here’s a link to an interesting essay by Sam Harris. I’d recommend skipping the comments. They are, as far as I could see from a very quick scan, the usual level of rubbish that you’d expect.

Posted at: 17:49

Path: /society   |  permalink

Wed, 01 Mar 2006

Somebody please kill all the Perl weenies

If ever there was a day when it was going to become unambiguously clear to me that all the “Perl programmers” need to be taken out and shot, today was that day.

Sure, go ahead and use Perl if it’s the only hammer in your toolbox and you just need to whip up a quick personal script and can’t be bothered learning how to do things properly and haven’t got the time or money to get somebody else to do it properly. But please, all of you, just stop writing big programs in Perl and passing them off as serious software.

My specific beef today is with the complete barking idiots who are responsible for SpamAssassin. Not only do they introduce command line incompatibilities for no good reason, but they make it barf over no-longer-supported options in such a way that a message gets delivered containing only the contents of the SMTP MAIL FROM and RCPT TO commands. No headers, no body, and no sign that there’s a problem. How utterly stupid.

And then, when the command line is fixed, it barfs because the new version uses some alternate database storage for its Bayes stuff. And this barfage is even more brilliant. It spams the MTA’s logs with lengthy messages, but exits with a success code and this time outputs an entirely empty message.

Even a child could work out the appropriate failure modes for such a tool. But not those idiots.

After missing out on a chance to find out what was in the 350-odd messages that arrived while I upgraded my workstation, I can tell you that I was mightily pissed off. And it’s nice to see the Apache crowd have indeed brought something else into their fold that seems to match their approach to software. Be a shame if something good had wandered into that hole by mistake.

Posted at: 22:51

Path: /software/discuss   |  permalink

Sun, 26 Feb 2006

Do we need big brother?

The behaviour of political leaders in recent years with respect to dealing with large scale crises flies in the face of common sense and historical data. There seems to be a certainty that people are too stupid to help themselves and that we need top-down control. One recent major failure of this model was seen in the pitiful response to the hurricane that devastated New Orleans.

While catching up on some of my reading today, I came across an interesting article in the New Scientist of 8 May 2004 entitled Heroes of the hour. It was written before Katrina, but the lessons in it are clear.

Minor update: the URL above takes you to the article summary. You need either to be a subscriber or to pay to read the whole thing.

Posted at: 11:20

Path: /society   |  permalink

Fri, 24 Feb 2006

Alisa Camplin, role model

Very nice post on Larvatus Prodeo suggesting that Alisa Camplin might be a good role model for boys. Go and read it.

Posted at: 12:45

Path: /society   |  permalink

Wed, 15 Feb 2006

Battery charging problem solved

I have previously reported on my search for a solar-powered battery charger and its installation in an attempt to get more than the usual seven months out of the expensive batteries in my little-used BMW.

About eight and a half months later, I reported on the lessons from that experiment. In brief, the solar charger might have given me a tiny extension of life on that battery—but if so it was too small to measure meaningfully. As a result of that unfortunate experience, I then found an alternative kind of charger which, in an almost miraculous achievement, resuscitated the dead battery.

I declined to offer more details at the time, as I wanted to see if the new charger might have potential in the longer term. The battery I bought in November 2004 is now more than 15 months old, despite having being so badly mistreated in mid-life, and is still working just fine. Even if it dies totally tomorrow, I’m now ahead—having more than doubled the lifetime from the battery. So now it’s time to give credit where it’s due.

I bought mine from Supercheap Auto because they are local and have a decent range. Since then, however, they have completely fucked up their website and made it impossible for me to find anything. So, I’ll illustrate from the Jaycar Electronics catalogue. The one to avoid is the Smart Solar Battery Charger which was a complete failure in my application. The unit I am now using, which I highly recommend, is the Battery Fighter Super Smart 12V SLA Battery Charger. It’s a steal at under $80.

Bear in mind that my car gets started once every four to eight weeks, is abused for a day and then parked again. I’ve been leaving the charger plugged in permanently and every time I go to start the car, it just starts and all is well. If you have a similar problem, this solution is well worth a try. There are other Battery Fighter models—for lighter duty applications, as I recall. I have no experience with them, but would expect them to perform satisfactorily if used correctly, based on my experience with my charger.

Posted at: 17:17

Path: /cars   |  permalink

Muslim Australia

I see the unspeakable Danna Vale is concerned Australia will become dominated by Muslims. I’m concerned about that too. But I’m far more worried that Australia might still be dominated by christians in another 50 years.

For those who care—and to provide me with a useful URL for future use, my stance on the value of all religions is nicely described by biologist PZ Myers. By the way, I recommend Myers’s blog to all intelligent readers.

Posted at: 07:33

Path: /society   |  permalink

Thu, 09 Feb 2006

Short sentences

I’ve just finished reading Lily Brett’s Just Like That. It took me a little while to get into it and I wasn’t quite sure why that was. Now that I’ve had time to reflect on it a bit, I can see several factors.

For one thing, I was a bit disinclined to be dragged back into all the horrors of the Holocaust. My visit to Auschwitz and the time I’ve spent with survivors and their children has been harrowing enough and I’m not strongly inclined to revisit. (Of course, it was far more harrowing for the victims; I’m talking about it as something that one might choose to be interested in, not as something that was forced by tragic circumstances.)

And, from past experience with her, I knew Lily Brett was pretty strong on the subject—and with very good reason. In the end, I got through the horrible bits of the book; they were only a small part of it and they were balanced by some hysterically funny material.

The other thing that made it hard for me to engage was more of a style thing. She writes succinctly. Most of her sentences are very short. And she piles them up. As a rule, I think short sentences that give a clear picture are admirable. And I’m certainly not the best person to be giving advice about sentence length, especially in view of one of my memorable experiences as a school kid (of which more below). But there was something too staccato and jarring, to my ears at least, in the early pages of this book. In time, as I got further into it and became interested in the story and the characters, I forgot my concerns with the language. And, once I realised that it was largely autobiographical, I just went with the story. At the end, I felt that it had been a really good book and I’m glad I read it.

My school story involved an English assignment which required a small piece of writing. We handed in our work, it was marked and handed back to us. Mine was not marked, but the teacher asked me to stand and read out the first sentence to the class. Being an idiot, I stood up and began reading. After a while, kids began to laugh. I kept reading, by now desperately searching for the full stop that would end my misery. I got to the bottom of the page, still on the first sentence. Finally, about halfway down page two, I found the beautiful full stop. I stopped and sat.

The teacher did admit that it was a well-constructed sentence, as was shown by the fact that I managed to read it out and make sense. But he was very clear that such long sentences were invariably a huge mistake. His final words were, “You’ll never be a writer, Joe Bloggs.” (Well, he didn’t really call me Joe Bloggs, but the name he used isn’t important now.)

I was mortified. I spent years trying to prove him wrong, in itself a strange thing to do since he was probably dead and would not have recognised any of the names I’ve used since then anyway. Perhaps that’s why I became a programmer.

Posted at: 18:11

Path: /writing   |  permalink

Dealing with the copyright vigilantes

Recently, Anthony recounted a story of being harassed by some idiot who responded privately to something on a public list and then got excited when his precious private words were subsequently quoted in public. For what it’s worth, I think the idiot is wrong and Anthony is right.

But that’s not the real point of this post. I’ve been following my own policy about this kind of thing for a while now, but I haven’t published that policy. So, for the benefit of people who might be inclined to write privately to me in response to something I’ve written in a public forum, here’s how I will handle things.

If I respond at all, it will be a brief reply that points them here. I won’t read their email. I will delete their email as soon as I send the brief reply (or without even sending the brief reply if it’s somebody to whom I’ve previously given the brief reply). And when they get here, they’ll learn that the only way to get me to respond to anything they have to say about something that I posted in a public forum is to do the same (and without any of those silly statements about copyright and restricted rights and the other nonsense that certain excessively legalistic types seem so keen to inflict on the rest of us). In other words, if the conversation started as a public conversation, then the only way it can continue is in public.

The upside for me is that I get to avoid the kind of thing that just happened to Anthony and I get to have a published policy that explains what happened to all the vitriolic private messages that so many people seem to feel entitled to send my way. Yes, that’s right, they go straight to /dev/null where they belong.

Posted at: 17:34

Path: /society   |  permalink

Sat, 04 Feb 2006

Seven Secrets of Successful Programmers

In a recent blog post, Lars Wirzenius took a swipe at a post entitled Seven Secrets of Successful Programmers by Duncan Merrion. Lars “found it to be simplistic enough to be inane” and I certainly agree with that assessment. And I mostly agree with his other criticisms of the original article.

But then Lars goes on to give his own list and that’s always going to lead to people wanting to disagree—something I’m about to do.

His fourth point is to develop debugging muscles. Lars suggests that this is difficult, since nobody teaches it and that does seem to be true, to some degree at least. But then he says “you’ll be spending most of your time doing it.” And that’s where we diverge. In my view, if you’re a “successful programmer”, then you’ll spend most of your time programming. It’s the unsuccessful programmers who spend most of their time debugging.

So, if you’re one of the people who knows your debugger better than your editor, you really need to learn more about the practice of programming—from books like The Practice of Programming by Kernighan and Pike, or Bentley’s Programming Pearls or even a classic like The Elements of Programming Style by Kernighan and Plauger.

That’s not intended to be an exhaustive list, of course. You need a more complete grounding than that and you need domain-specific knowledge as well. But, regardless of where you go to learn your craft, you need to develop your skills to a level where you hardly know how to drive the debugger because it’s so long since you last used it.

Posted at: 14:36

Path: /software/discuss   |  permalink

Thu, 02 Feb 2006

Technorati

I’ve been aimed at Technorati by various people, and I have to embed something in my blog so that I can “claim my blog” there. This post is just to allow me to do that.

Posted at: 17:01

Path: /meta   |  permalink

Sat, 28 Jan 2006

Hard to be good

Late last year, while reflecting on the things I had accomplished (as well as the things I had not accomplished), I saw that most of the stuff I’ve written here has had a distinctly critical tone. So I decided that I’d make an effort this year to write at least some pieces with a positive pitch. Here we are, at the end of January, and I still haven’t found anything to fit this goal.

Today, however, I came across two items of interest in my reading and one of them seemed to fit the good news theme I’d been hoping for.

While waiting for my spouse to finish her business in the shopping centre, I picked up a book about C++ programming. This is not a subject dear to my heart, but the book had a cover that promised good things and the author was somebody with a genuine depth of experience in both the C++ world and the technical writing world. And, as far as I could tell from a 10-minute read, it was a pretty good book and encouraged what I’d probably describe as good practices for people unfortunate enough to have to work with C++.

The thing that was most apparent from the book, however, was what a bizarre dog’s breakfast C++ is. The entire book seemed to be aimed at providing guidance to the hapless programmer on the critical task of avoiding self-inflicted damage. Since nobody seems to be taught the important basics these days, junk like C++ is even more of an affront to sanity than it might once have been. Just Say No.

Now for the good news. I have had reasons in the past to visit Tim Bray’s blog. Something I read this morning sent me there again, and I took the time to look around beyond the original article. And I found three little gems, entitled Truth, Biz and Tech. They are great. And they come close to expressing my thoughts on those topics. Recommended reading.

Posted at: 14:30

Path: /random   |  permalink

Sat, 31 Dec 2005

Technical writing is harder than people think

I’m always on the lookout for good technical writing—whether it be in books, magazines or online. I have several motivators for this:

• my own continuing education;
• source material I can use in teaching;
• reference material to quote in my writing;
• staying in touch with potential publishers for my writing.

It won’t surprise anybody that I find plenty of technical writing that fails to impress. I don’t write about everything I find that I don’t like—I’d rather be spending my time on things that interest and challenge me. And I have previously written about flawed technical papers and about the stupidity of treating C and C++ as interchangeable. But those items were written nearly 16 months ago, so it seems reasonable to revisit the themes again now.

Right now, I’m particularly interested in looking at the technical book publishers—I have a couple of books planned [1] and I’m thinking about how to pitch them to the publishers. So I was pleased to see an article in Linux Journal entitled The Arnold Robbins Book Series: A Review. The review covers the recent Open Source Development Series, edited by Arnold Robbins and published by Prentice Hall. It incorporates an interview with Arnold Robbins and reviews of two books in the series. My interest is in the series as a whole and one of the books, Linux Programming by Example: The Fundamentals, also written by Arnold Robbins.

After skimming the interview and the review, I was sufficiently interested to have a look at the book. Although the Prentice Hall link above claims the book is available on Safari Books Online, it was not available via any of my Safari subscriptions. However, Prentice Hall do offer a sample chapter online. Since that chapter covers memory management, one of the three basics that almost all books covering C programming get wrong, I thought I’d have a look.

Memory management is not only one of the big three for technical errors, but it is also frequently associated with another of the big three—imagining that it’s possible to write usefully about both C and C++ in the same place. And so it is here. As so often happens, Robbins recommends unwarranted casts in his discussion of malloc(3). Oddly enough, he incorporates some sample code from Geoff Collyer that eschews the cast and comments unfavourably on that, rather than learning from it.

This is not the place for a detailed explanation of the reasons why a cast is useless and potentially harmful, but it is worth mentioning that in C—as distinct from C++, a quite different and arguably significantly inferior language—use of the cast operator is almost always a sign of programmer ignorance. It is rarely needed in correct code, and the circumstances where it is needed are clearly understood by competent practitioners.

Part of the problem is caused by people who dabble in both C and C++ and who have fallen for the strange propaganda from the C++ zealots that C++ is an “improved C”. It’s not. As a wild guess, I’m willing to bet that the reason for the requirement for all the casts in C++ is another consequence of fact that Stroustrup, despite purporting to write a successor to C, never managed to master that simple and elegant language. (Last time I speculated on something like that, the interested party wrote to me and put me straight; expect a correction here if that happens this time around.)

Of course, Arnold Robbins is not the only person who has made this mistake of thinking it’s a good idea to cast every pointer returned by malloc. The mistake was most famously made in the second edition of the C bible, known to all as K&R2. When I first pointed out the error to Dennis Ritchie, he defended the book; but, in the face of my persistent nagging, he re-thought it and eventually decided that the book was wrong. This is now documented in the Errata for The C Programming Language, Second Edition. (Search for the references to malloc on pages 142 and 167 for the details.)

Returning to the book, the other concerns I had were that the author spent a lot of time discussing things that he suggested (quite rightly, in general) that you should not do, even with some lengthy and detailed example code. This seems pointless to me. And he failed to explain reasons for other things he recommended. For instance, he suggests that it’s always a good idea to zero newly allocated memory. (In fact, I don’t agree with the “always” part, but it is often true.) But he fails to explain either of the fundamental reasons why it’s sometimes a good idea. That seems unforgiveable.

The final issue from the sample chapter is more difficult to be sure about, because it’s impossible for me to read this book with the same state of mind as its intended audience. But, from my reading, it lacked bite. I think I’d have wanted something that stated its goals clearly, tackled the useful issues head on, explained good practice and equally explained the reasons for the possible pitfalls. This chapter seemed weak in those areas—and the specific failings I described certainly leave me disinclined to recommend the book or the series (although I’d have to look at some of the other books before I came out strongly against the whole series).

[1] As a renowned procrastinator, I may well never get around to completing these books; but I like to prepare for things in case I do go on to finish them.

Posted at: 12:42

Path: /software/discuss   |  permalink

Fri, 02 Dec 2005

Barbarism has its day

Singapore has conducted another barbaric and degrading killing of a human being with the execution of the unfortunate Van Nguyen.

I have no reliable information about his guilt or innocence and am not at all concerned with that.

The death penalty is always wrong. It is always cold-blooded murder and a society that uses it is demeaned by that.

I will certainly not set foot in Singapore while it maintains its policy of killing people.

Posted at: 15:59

Path: /society   |  permalink

Thu, 24 Nov 2005

November 25 is White Ribbon Day

This campaign seems important to me. November 25 is the International Day for the Elimination of Violence Against Women. The white ribbons are worn by people who support this cause.

Learn more about it, including how you can participate, at the Amnesty International website, in particular on the White Ribbon Day page.

Posted at: 13:38

Path: /society   |  permalink