Thursday, December 06, 2007

Programmer's purity test

There's an enormous list of programming languages up on the Wikipedia at Alphabetical List Of Programming Languages

It occurred to me that that'd make for an interesting variation on the classic "purity test". A number of "hacker" and "geek" purity tests are out there, but I haven't seen one specifically for programming. There are way too many extremely obscure languages on that Wikipedia list, though.

If we trimmed out the truly obscure languages, we'd get something like this:

Have you ever:
  1. Programmed a computer?
  2. In ADA?
  3. In ALGOL?
  4. In APL?
  6. In Assembly?
  7. In AWK?
  8. In B, or BCPL?
  9. In BASIC?
  10. In brainf*ck?
  11. In Bourne Shell?

Nah - too boring, and we haven't even gotten out of the B's yet. Maybe we could organize it by generation:

Have you ever:

  1. Programmed a computer?
  2. With jumper wires?
  3. In machine code?
  4. ...without a coding sheet or other aid?
  5. ...with toggle switches?
  6. ...from a Hex keypad?
  7. In assembly language?
  8. On punched cards?
  9. In a language whose syntax assumes that you're still using punched cards (eg Fortran, RPG)?
  10. In COBOL?
  11. In C or Pascal?
  12. In Forth?
  13. In Lisp (Scheme, Logo)?
  14. In Smalltalk?
  15. In a 4GL?
  16. In C++?
  17. In Java or C#?
  18. With a scripting language?
  19. In a modern functional language (Haskell, etc)?
  20. In an object-oriented language without class-based inheritance?

That's a pretty good start, maybe we could add a few questions on how you used these various tools.

Have you ever...

  1. Written a program that directly controlled objects in the physical world?
  2. ...did you ever injure anyone with a bug?
  3. ...other than yourself?
  4. Written software for internal business use?
  5. Written software that was sold at retail?
  6. Written software that sends email?
  7. ...did it ever send thousands of messages due to a bug?
  8. ...outside the organization you were working at?
  9. Programmed in a language of your own design?
  10. ...did anyone else ever use your language?
  11. ...did it become a de-facto standard?
  12. ...or an ISO or ECMA standard?
  13. Written a compiler?
  14. ...not as an assignment for a class?
  15. ..."by hand" (without using lex/yacc or related tools)?
  16. Created self-modifying code?
  17. Written code that modifies some other program's binary?
  18. Written self-reproducing code?
  19. ...without it getting away from you?
  20. Changed the class of an object at runtime?
  21. a language without dynamic dispatch?
  22. Created a program that took longer to run (once) than it did to write?
  23. ...while running on a cluster of computers?
  24. ...or a conventional supercomputer?

I seem to have run out of ideas. Suggestions for additional questions would be greatly appreciated. A traditional Purity Test would have 100 questions, so you could easily generate a percentage score.

For what it's worth, I scored 32/44, or about 27% pure. I think that probably indicates that the test is a little too focused on my own experiences. Send me your questions, and I'll work up a better list...

Saturday, November 24, 2007

Fear of teaching

I gave a little presentation or lecture at work last week (on pair-wise testing and higher-level test planning) and I was reminded of one of the great tragedies of my life. I really love to help people learn new things, but actually standing up in front of a crowd and talking makes me physically ill. It's been like this for as long as I can remember, and I've learned to work around it in the work context, but if I had to do this every day I'd be pretty miserable.

Since I knew other people would want to read about it later, especially given that I gave the presentation on the Wednesday before Thanksgiving, I put my notes up on our Wiki. I have a bit of a love-hate relationship with the Wiki. While I love the idea of a single place to look for information, the usability of Wiki markup languages really stinks. It's a bit like Blogger's "plain text" format, in that if you don't care about what things come out looking like, it's alright, but I always spend more effort trying to work around the limitations of the format than I do actually writing the content.

I've learned over the years that there are about three major methods of preparing for giving a presentation. Some people actually go to the effort of writing out everything that they want to say, similar to a speech as given by politician. Some people write nothing down, and ad-lib the whole thing, and then there's the approach I've always used. I usually write an outline that contains all the topics I want to cover, and then I ad-lib the presentation around the outline, making whatever mid-course corrections might seem necessary based on the audience's reactions.

Because I wanted people to be able to get something out of my notes without having to be at the presentation, I filled in the outline with some additional explanatory text. That's very similar to the process I usually use when I write other things (for example, blog posts). I start with an outline, then I replace items in the outline with paragraphs and sentences. Even when I do something more free-form like this post, I have the outline in my head, at least. Revising an outline on the iPhone would have pretty painful...

When I finished the presentation, I got some very positive feedback from the audience, including at least one actual pat on the back, something I had thought of as a metaphor before. Afterwards, I thought a little bit about what I thought was good about that presentation, especially compared to other presentations I've seen lately, and I think it's all about not over-planning or under-planning it. The worst presentations I've been subjected to are of the "guy reading directly from his Powerpoint slides" style. Second worst are the "guy who is totally not prepared or sure what he wants to say" variety. Once again, the happy medium wins out.

Sunday, October 28, 2007

The C++ FQA (frequently questioned answers)

No updates for 6 months, then two in a day...
Via a discussion on Joel On Software, I got directed to this:
The C++ FQA

It's a response, of sorts, to the C++ FAQ. You can read moreabout it on the site, but he basically goes through the questions in the C++ FAQ, and explores what it is about C++ that makes those questions "frequently asked". There is some sarcasm, and some rather insightful commentary on why C++ is so very hard to develop real expertise in.

It would be neat to see something like this done for Java and C#. I think the idea of looking at a language from the standpoint of "why are these areas confusing to so many users?" is an interesting approach.

I have always felt that my resistance to really learning C++ was a failure on my part, but after reading "Effective C++", and with the backing of the C++ FQA, I feel a little better about taking the position that C++ is really far too complex for the good of the people who need to work with it.

Wednesday, October 24, 2007

You're probably using "unsigned" incorrectly

You're probably using "unsigned" incorrectly, and that makes me sad.

Chances are that if you write code in C (or related languages like Java, C#, or C++), then you've come across the "unsigned" type, and its relatives "unsigned long" and "unsigned short". If you've written code that uses unsigned types, it's also quite likely that you've used them incorrectly, at least by my standards.

Misuse of "unsigned" in C is one of those things that I keep seeing over and over, with different developers, even folks who really ought to know better. I find it immensely frustrating. If I had to pick one aspect of C that was responsible for more stupid bugs than anything else, this'd be one of the top candidates. Probably not the top candidate - the string-handling functions in the standard library probably win that handily.

Here are my simple rules for the use of unsigned integer types:
  • Don't use unsigned just because "that value should never be less than zero"
  • Always compile your code with all warnings enabled
  • Avoid mixing the use of signed and unsigned integers in the same calculation
  • Do use unsigned when modelling hardware registers that hold unsigned values
  • Do used unsigned when performing bit-wise arithmetic
Okay, back to the subject at hand, and let's take a look at those rules, shall we?

Don't use unsigned just because "that value should never be less than zero"

This is by far the most common abuse of unsigned types that I see on a regular basis. It's not even a bad idea, as far as it goes. A majority of the values in a typical program are going to be non-negative by design - sizes, screen coordinates, loop counters, etc, etc. The problem really isn't unsigned values per se, it's how unsigned and signed values interact.

Part of the problem is that constant values in C are signed by default, which means that signed values will creep into your program unless you make a concerted attempt to avoid them. When you compare signed and unsigned values, the results will often not be what you expect. For example:
unsigned four = 4; 
int neg_one = -1;
if (neg_one < four)
Looking at this code, it's pretty obvious what the programmer intended, but in fact the comparison "neg_one < four" evaluates to false in this case. This is because the signed value will be "promoted" to unsigned, turning it from a small negative number to a very large positive number, before the comparison is made.

In actual cases of this problem in the wild, the declarations will typically be a long way away from the comparison, and it won't be at all obvious what the cause of the problem actually is. I've seen experienced programmers stare at the debugger in disbelief when it seems to be showing them that their program thinks that -1 is greater than 4. An additional complication is that constants in C are signed by default, so you can replace the "neg_one" variable in the example with the constant "-1", and you'll get the same behavior.

A related problem comes with the handling of sizes and lengths. A size is typically going to bea non-zero value, so it "makes sense" to use unsigned variables. The problem is that sizes are often calculated by subtracting one value from another. If you accidentally subtract a larger value from a smaller one with signed variables, you get a negative size, which you can at least detect and handle (with an assert(), if nothing else). If you're using unsigned math, you just get a huge bogus "size", which may or may not be immediately obvious.

Always compile your code with all warnings enabled

Admittedly, this rule is more general, rather than specifically tied to problems with using "unsigned" correctly. Most C and C++ compilers have an option to warn on comparisons between signed and unsigned values, when there's a chance the comparison will be interpreted incorrectly. It's even more frustrating to debug one of these issues when compiling with warnings enabled would have produced a warning message that points to exactly where the problem is, but some yutz has that particular warning disabled.

Of course, they have it disabled because enabling warnings on comparisons between signed and unsigned tends to generate zillions of bogus warnings. That's just a good reason to avoid using unsigned variable, where possible - it obscures the actual problem areas with bogus warnings.

Avoid mixing the use of signed and unsigned integers in the same calculation

Given the example above of a simple comparison going wrong, it ought to be obvious that anything more complex is at least as likely to go subtly wrong in some way. Again, the real problem arises because the declarations of the variables (and constants) will be far far away from the point of the errant calculation.

So, when is it okay to used unsigned types?

Do use unsigned when modelling hardware registers that hold unsigned values

This is most likely how unsigned types got into C in the first place. If you're writing low-level OS or driver code that talks to the hardware, you'll often find that the unsigned int type exactly matches what the hardware is using. This also segues nicely into the next rule...

Do used unsigned when performing bit-wise arithmetic

If you're doing something with fancy binary arithmetic, like an encryption algorithm, or something else where you're using an integer as a sollection of bits, unsigned types are probably what you want. I'd put something in here about using "unsigned" with bitfields, but the bitfield construct in C is pretty useless (and a topic for another rant), so I'll just mention that it's worth thinking about whether you want an unsigned or signed bitfield, if you ever use them.

Unfortunately, you actually can't avoid "unsigned" values

As it turns out, there are types that the standard library uses that are usually unsigned, for example size_t. So, your inteactions with the standard library will occsionally force unsigned values to creep into your program. Still, that's no reason for you to make it any harder on yourself.

Monday, May 28, 2007

New Blender!

Last week, we got a new blender - a Blendtec Total Blender. Since Yvette started her weight loss program, we've gone through 4 blenders or so. Making multiple shakes every morning wears out your typical bargain basement blender in 6 months or less. We're hoping that the new blender lasts us a whole lot longer. It had better last a long time, it was nearly 10 times as expensive as the last blender we bought.

The Total Blender is based on Blendtec's commercial blenders (my local Starbucks uses Blendtec blenders). It's got a 1500 watt motor, as compared to the 300-600 watt motors in a typical home blender. It's got a very solid square blender jar, and a scary-looking set of ultra-sharp blades. Instead of a set of speed buttons that are labeled with wacky labels like "frappe" and "fold", it's got buttons naming what food you're making - "milkshake", "soup", "smoothie". Each button initiates an automatic program which speeds up or slows down as necessary to perfectly mix whatever you're making. It even stops automatically at the end of the program. Nifty!

So how well does it work? It's incredibly powerful - it crushes ice without even slowing down. It's also very loud at full speed. The instructions that came with the blender were minimal, but it did come with a pretty big cookbook. Apparently, the motor is strong enough to actually grind flour, make peanut butter from whole nuts, etc. On the "soup" setting, the friction of the blending actually makes the soup hot! For simple stuff, like the aforementioned diet shakes, it does the job about twice as fast as our old blender. The jar is super easy to clean, and doesn't seem like it'll get food stuck under the blades like our old blender tended to.

There is one downside that I've identified so far. Have you ever had a blender accident, where an overloaded blender popped the top off and splashed stuff everywhere? Try to imagine what it looks like when that happens with a blender that's 4 times as powerful. This is particularly problematic with hot liquids - the fast start of the blender throws the hot liquid up in the jar, which causes the air in the jar to expand and jet out the top. I think of it as Mount Blendtec erupting. Cleaning shake mix off the ceiling isn't very much fun.

I think I've got the technique dialed in now. I do wish they'd implement a slightly softer start for the low-speed settings, though. All in all, it's definitely a massive improvement over our old, tired blender. I'm going to try some of the recipes from the cookbook. That should help familiarize me with the various cycles. Besides, it's just plain fun to use - it'll blend darn near anything. Speaking of which, if you haven't seen it, check out Blendtec's Will It Blend? for amusing demos of the blender in action.

Wednesday, May 02, 2007

They're running a contest over at Worse Than Failure

Worse Than Failure (formerly The Daily WTF) is having a programming contest, with either a MacBook Pro or Sony VAIO laptop as first prize.

For those not familiar with the site, their theme is Curious Perversions in Information Technology. People submit particularly awful pieces of code, or database schemas, or business practices, and the readers of the site make various insightful, witty, outraged, or just plain misguided, comments on them.

The contest: Implement a four-function calculator program (for Windows, or UNIX/GTK). Your program must pass the specified test cases, have a GUI driveable using a mouse, and should cause people who read the code to shake their heads sadly in disgust.

There's much more detail on the contest website, but I thought the idea of the contest was interesting enough to mention. The contest discussion forum is hilarious, as well. Check out this comment:

Mine's too slow right now. It's taking about 45 minutes to add 9876 and 1234, when I was hoping for about three seconds. I knew it was O(n^2), but I was expecting the constant to be a bit smaller. I may need to replace the Mersenne twister with a faster random-number generator.

I have what I think is a pretty good set of ideas for a submission, I'm just not sure that I'll be able to finish in the time remaining (12 days left). I'll probably submit whatever I have by then, even though I almost certainly won't win. I'm looking forward to seeing the other entries, though.


Looks like somebody at accidentally merged two entries in the product database.

Tuesday, April 10, 2007

Slashdot really irritates me sometimes...

There's a story on Slashdot about a new idea for a way to enable patching complex microprocessors to work around design defects, or "errata", as they're called in the industry. The basic concept is to include a small amount of configurable logic on a chip, and use it to detect conditions that would otherwise trigger a known errata, and automatically work around it.

This would allow manufacturers to fix design defects in already-manufactured chips, rather than fixing the defects in subsequent revisions of the chips, and leaving earlier customers with the buggy chips they bought (which is what they do now).

Unfortunately, the article that's linked in the Slashdot submission is a little light on details, and the summary is just plain misleading, so the Slashdot comments are completely swamped in responses like: "this is an old idea!", "what's so novel about an FPGA?", "FPGA's are expensive, slow, and inefficient!", and other nonsense.

I actually read the article and tried to understand what it was about. When I posted that it sounded like a good idea, and it'd be interesting to read more about the design, an unregistered Slashdot user provided me with a link to the original paper, which made it much more clear what the whole thing was about.

But nobody else can see that link, because Slashdot's moderation system assumes that unregistered users are less trustworthy, so the comment with the link to the original paper is invisible to the idiots that keep ranting back and forth to each other about what a dumb idea this is, without having any idea what they're talking about.

So, go here, and read the original paper, especially if you've ever had the experience of running into one of these errata before. Hopefully, the folks at AMD, Intel, and IBM will see this, and it'll make it's way into newer designs.

Monday, March 12, 2007

Daylight Saving Time is here...

[edit: changed the title of this entry, since the old one wasn't quite relevant anymore]

Daylight Saving Time is here again in the good 'ole US of A. This year, the dates for the switch to and from summer time have changed. Naturally, despite the fact that this change has been known about for nearly two years, there was a last-minute scramble by various companies to get "patches" for their software out in time for the new Daylight Saving switchover.

And some of them didn't, in fact, get ready on time. Despite the fact that I (and the rest of my company) installed Microsoft's patches for Windows, this morning all of our meetings in our Outlook calendars are shifted by one hour. And we're not the only ones - I see in the news that this is causing problems all over. If someone's late for an appointment with you today, cut them some slack - it's probably Microsoft's fault.

Tuesday, February 27, 2007

What was that?

When I was a young lad I had, shall we say, a more "carefree" attitude towards software development. This is the story of how I learned to be a bit more methodical in my approach to certain types of issues.

The project I was working on was the motion control system for a robot. Now, I should probably clarify that, so you don't get the wrong idea - we're not talking about C3PO or R2D2, here. This was an industrial robot, used for 3-d imaging. The robot itself was made out of slabs of cast iron bolted together, was probably 8 feet tall, 4 feet wide, and ten feet long, and weighed in the neighborhood of 4 tons.

The problem I was having was that the motion control was somewhat unresponsive - you'd move the joystick, and the translation table or the optical head would slowly start to move, and when you got to where you wanted to go, it'd keep on moving for a little while before coming to a stop.

As I was looking at the code, I found what I thought was the problem - I had simply put the wrong coefficient in for one of the control equations, so we weren't getting the proper exponential factor applied to the requested motion. A quick edit and recompile, and I was ready to test the new code.

I started the system up, and very slightly moved the joystick. The translation table started to creep forward. I then pushed the stick over a little farther, and the table accellerated. So far so good.

And then, something very bad happened. When I put the stick back to the rest position, the table didn't slow down. In fact, it kept speeding up. I tried pulling back on the stick, but that didn't seem to have any effect. I managed to turn off the power to the motors just before the table hit the hard stops at the end of its travel.

So this 600 pound cast-iron table slams into the rubber bumpers at the back of the machine, going something like 30 feet per second. The whole machine rings like a gong, and all work in the entire shop grinds to a halt as everybody looks over to see this multi-ton machine gently rocking back and forth. I was really worried that I'd wrecked at least part of a very expensive machine, but a later calibration run showed that the mechanical parts of the robot were just fine.

It turns out that there were two problems in the system - the incorrect exponential on the input side that I'd corrected, and an additional incorrect damping factor on the output side. The upshot of all this is that once the system was up to speed, it took a very long time to slow down, but the bug on the input side ensured that it never got up to more than a tiny fraction of the maximum speed.

The next time I needed to make a change in those calculations, I did a "dry run" with the motors disconnected first...

Monday, February 12, 2007

Just barely better than no backup at all...

So, the hard drive on my Mac died. Disk Utility won't fix it, Techtool pro just throws up its hands at the 2,000 bad blocks on the drive, etc, etc.

That kind of sucks, but at least I have relatively recent backups to restore from. Or, maybe I actually don't. I've been using the .Mac Backup program to do backups for the last year or so - prior to that, I was just bulk-copying stuff by hand to an external hard drive. The Backup program is a lot more convenient, and makes much better use of the space on the external drive.

I figured that surely, now that Backup is at version 3.1, it'll be rock-solid reliable, right? I mean, once they fixed that awful crashing bug I reported back in the 1.0 days, I hadn't noticed any problems, so everything is OK, right? Well, as it turns out, Backup 3.1 is no more reliable than the old Backup - it just has different bugs. Now, instead of crashing on backing up large numbers of files, it crashes when trying to restore them. If I was given a choice between these two behaviors, which do you think I would have chosen?

The one saving grace is that inside the broken Backup file package is a more-or-less standard Mac OS X disk image file. So, I can mount those files (one from the last full backup, and one from each of the incrementals), and hand-copy the files over from them. Let's hear it for unreliable backup software...

Tuesday, January 16, 2007

Language matters

My non-programmer friends and relatives sometimes ask me:
Why are there are so many different computer languages?

My co-workers sometimes ask me:
Why are there so many reference books for obscure languages on your bookshelf?

The answer in both cases turns out to be the same: Language matters. The language you use affects how you think about a problem. Psychologists and Linguists (and Politicians and Salesmen) have known about this for years as it applies to human languages, and it turns out to be true for computer languages as well, of course.

I was reminded of this fact just today, as I was explaning some concepts in Object Oriented Programming to a co-worker who's just coming up to speed on C#, after using mostly C and Perl for several years.

My own first exposure to Object Oriented Programming was back in the (very) early 90's, with Borland and Microsoft's C++ compilers. I'm not sure I ever really "got" OOP in C++, and neither did most (all?) of the people I worked with. We mostly just used C++ as a better version of C.

Fortunately for me, I managed to snag a copy of Digitalk's Smalltalk for Windows not long after that. And suddenly, it all made sense!. Because the Object-Oriented nature of Smalltalk is so "in your face", you can't help but start thinking about things in a new way. The version I got came with pretty decent tutorial info as well, which was also a big help.

I never actually produced any large-scale software in Smalltalk (it was impractical for work projects in terms of performance), but the new way of looking at things stuck with me as I continued to write low-level bit-banging code in C. When I came out to California and worked for NeXT, my Smalltalk experience translated, more or less directly, to Objective-C.

Anyway, back to the discussion with my co-worker. There are a couple of different ways of thinking about "using objects" that I'm familiar with, and I tend to think of them as "The C++ way" and "The Smalltalk way". In some sense, this isn't entirely a fair characterization, but in my experience, the two views are more-or-less endemic in their respective programmer communities, so that's how I think of them.

The C++ view:
An object is a combination of some data, and functions that operate on that data. To perform some action, you call a member function of the object instance that has the data you need to work on.

The Smalltalk view:
An object is a model of some part of your problem domain, and each object has its own set of responsibilities and capabilities. To cause something to happen in your program, you send a message to an object, which may in turn send messages to other objects.

Now, it turns out that these two definitions are actually equivalent, or at least compatible, despite the fact that the C++ definition is entirely focused on the implementation detail, and the Smalltalk definition is entirely focused on the semantics.

When you get right down to the low-level implementation details, "sending a messsage" and "calling a member function" are really the same thing. A couple of CPU registers get loaded with a couple of addresses, and then you jump to a subroutine. Yes, I know it's more complicated than that in the real world, where you've got vTables, and dynamically-compiled methods, etc, etc. Work with me here...

The C++ programmers that I've met usually come to C++ from a background writing software in C. Because C is such a very low-level language, it encourages (or maybe I should say requires) that you understand the low-level details of how stuff works under the hood - memory management, how structures are laid out in memory, that sort of thing. When these folks start using C++, they apply the same low-level filter to things, and they see a class as just a data structure with some functions attached to it. This is in fact technically true, but kind of misses the point.

As I was trying to explain to my co-worker what I didn't like about some code of his that I was reviewing, I ran into a bit of a wall. I knew that something wasn't quite right, but I wasn't able to articulate the problems well enough. I think I finally figured out that it was at least partly a result of the difference in perspective due to our different backgrounds. Once I figured that out, I was able to take the discussion out of the tactical questions like "should I use a Regular Expression here?", and into the more theoretical territory of "is this an appropriate way to model the problem you're trying to solve?", and I think we made better progress after that.

It'll be interesting to see whether my co-worker has the same kind of epiphany that I did, or if he'll pick stuff up more gradually. Given that we're mostly using C# and C++ at ZING, I suspect it'll be the latter. You can write code in C# that looks just like C, with the minimal amount of "classiness" wrapped around it to compile. I suspect it would be easier for most folks to learn a new concept in a language where their old habits are obviously not going to do the trick.

Which reminds me of something else I wanted to write...

Monday, January 15, 2007

So, how was CES, anyway?

For those who don't recognize the name, "CES" is the Consumer Electronics Show, a yearly trade show for the Consumer Electronics industry.

ZING did really well at CES this year. In addition to the usual behind the scenes deal-making and partner development, we had a couple of high-profile announcements, and one of the products we're helping to bring to market won an award!

SanDisk's Sansa Connect got a "best of show" award from CNET.

What does that have to do with ZING, you ask? We designed the hardware, software, and service infrastructure that makes the Sansa Connect work.

ZING also announced a deal with FON that will allow ZING-enabled players to connect to the FON network. This is great because FON is the fastest-growing WiFi hotspot network out there. They've got an interesting business model, too - share your WiFi bandwidth at home, and get free access to WiFi when you're not at home. Check them out at

For a while there, an at-CES interview with our CEO Tim Bucher was linked from the front page of It's a little harder to find today, but here's a link.

Friday, January 12, 2007

So that's what it feels like...

It was an interesting experience watching a MacWorld keynote address with a feeling of dread, rather than one of anticipation. Fortunately, Apple didn't announce anything that makes the product I'm currently working on irrelevant, but it was interesting feeling that cold prickle of fear.

The iPhone is very expensive by my standards, but that's always true for Apple hardware. When I worked there, I never really felt like I belonged, in some sense. I never would have bought an iPod when they came out, but the market certainly ate them up. I'll most likely take a pass on the iPhone as well, not least because it's not a clamshell phone. I'm not really a fan of phones that are designed such that I can't sit down with them in my pocket.

The more surprising thing (and frankly worrying, as a competitor) is Jobs' claim that the iPhone is running Mac OS X. Now, we all know that that's not *quite* true - presumably it's been stripped down a bit for the environment. But the key thing is that it's actually got a rational software architecture. One of the things that was a constant drain on the iPod team when I was there was that there wasn't any OS as such on the iPods, and they weren't really built on any kind of common platform.

This made adding new features to the product line, or even fixing minor bugs, a major hassle - between making the changes in 3 or 4 gradually diverging code bases, and retesting absolutely everything anytime we changed anything (no memory protection or preemptive multitasking on those old iPods), we had a hell of a time just getting anything done.

When Apple needs to add a new feature to the iPhone, they'll just have any one of Apple's developers crank out a widget in DashCode, and they can then just make it available for download. If you're any kind of Consumer Electronics company, you really ought to see this as a shot across the bow. Maybe you're not in the mobile phone business, and you don't see how a $500 cell phone is relevant to you.

First, don't expect that the price is going to stay that high for long. Second, think about what's the actual difference between an iPhone and a new wide-screen iPod, or an Apple portable game machine, or whatever? That's right - a couple of minor board changes, and some new application software, and it's whatever Apple wants it to be. They've got an actual PLATFORM for high-end (currently) Consumer Electronics, and the game as we've known it is changing.