I can no longer keep the pace on this blog. I'm sorry. It's just not working anymore. Spare time is getting ever shorter, I find it hard to dig up interesting topics, and to top it all Yahoo 360 is going away early next year. So the next post (scheduled for the 20th of December) will be the last for a while.

My faithful readers (there are exactly three that I know of...) can rest assured that I don't intend to vanish into the night. Content that is more perennial in nature – think source code – is going to my bliki, and I'll republish some of my favorite posts on Digital Thoughts.

The final fate of the Philosophical Programmer will not be decided right away, so if there's anyone out there who wants me to go on, well, there's plenty of time to tell me. If you don't, I'll be forced to assume there is no one. Think about it.

If somebody would have told me three months ago that I will trade a full-blown palmtop computer for a portable media player I would have laughed in their face. Now, a few weeks after doing just that, I'm congratulating myself for my decision. I find it hard to explain, though. Bear with me.

So, what's a Palm good for? Theoretically, a lot of things, since it's essentially a complete computer. On-board compilers and interpreters? Check. Database software? Check. Office applications? No problem! There's even a Web browser, just in case you manage to establish a network connection via Bluetooth or infrared. I couldn't. It does have a number of good games which I played. Until, inevitably, I got bored. Nobody has written any new Palm software in over 2 years...

In all honesty, I did use the Tungsten E2 quite a lot, albeit in very limited ways. I did take notes with it – my reason for buying the device in the first place – but it wasn't suitable for heavy writing, and when the screen wore down it left me with no alternative. The thing doesn't even have a microphone. I did watch photos on it, but juggling them between the internal memory and the SD card was a pain. Besides, using the latter significantly reduces autonomy, which is painfully visible now that the battery has worn down as well. I did read e-books on it, especially as of late, but converting them to a format the Palm would understand was always a bit of a chore, unless they were already in Plucker format. Which, in turn, is totally unreadable on a desktop machine, so I had to download every title twice anyway.

A portable media player, on the other hand, seems much more limited at first sight. My iRiver Clix2 can play music in all major formats (OGG Vorbis included... take that, Palm!), display JPEG pictures (why no other format?) and text files. It can also play video, receive FM radio and record sound, either from the latter or a built-in microphone. It even supports Flash Lite games, but that's about it.

I was worried at first about the small size of the device, and especially of the screen. But auto-scrolling makes reading surprisingly pleasant. The default speed is perfect, and so are all the other default settings. I still can't believe the amount of calculated elegance built into this tiny machine. Fitting in the palm of my hand (no pun intended), light as a feather and entirely key-driven, this player is a pleasure to use. Even tranferring gigabytes of music wasn't a problem, as the device behaves like an USB drive. And yes, it minds my directory structure – I don't even need the desktop software that came with the package. Why, oh why, couldn't the Palm be as easy to manage?

And now I'm getting to the player's limitations and why they are actually a good thing. You see, engineering is the art of compromise. You can either do a few things well, or a lot of them very poorly. The Korean designers went the former way. The Clix2 needs an USB port to recharge, but this means it's smaller, lighter and more reliable. It lacks file management, but navigation couldn't be easier. And then, what would be the point of being able to delete a file when the device is unplugged? It's not like you can add new content while you are far from a computer. Oh wait, you can: the sound recorder does just that. Reasonably enough, recorded sound files are the only content you can delete form the player's interface. As for the supported file formats, they are at least standard stuff you can read and write with common desktop software.

All in all, it's a matter of using each tool where it's best suited. A mobile device is good for playing content, so it should focus on that. A laptop, on the other hand, is good for authoring precisely because it's not like a handheld. (Hint: UMPCs and tablets are forever doomed to fail.) As for taking notes wherever you may find yourself, nothing can beat pen and paper as yet.

After over two years of intensive usage, it's finally time for my faithful Palm to go into retirement. As you might expect, I really wanted a replacement device. Naturally, my first option was another PDA. But in the end I settled on something different, and here's why.

The first reason is the OS. You see, Garnet just isn't made for power usage; there are no folders, file transfer is quirky, as for the file formats... let's just say I want a device that can read large text files whit no need for special conversion software. Windows on a mobile device is something I'd never trust – not after years of trouble on the desktop – as for Symbian, I received too many warnings against it. That would leave Linux, but no mobile Linux device is to be found on the Romanian market. And don't even get me started about MacOS X and swapping a monopoly for another.

The second reason is writing. My original motivation for buying a Palm was that I could write documents on it, which seemed convenient in many ways. And it was... except that for writing I need to see a lot of context, much more than I can get on a tiny hand-sized display, and then there's a little issue with wear-out. Specifically, the touchscreen is so badly scratched now that it hardly responds to the stylus anymore. PDAs and heavy-duty use don't mix. Take my word for it.

(As an aside, I'll bet that's why tablet PCs never caught on, either. Keyboards are simply irreplaceable as input devices.)

I was just about to buy a full-keyboard smartphone when the thought hit me: I wasn't going to use that. I would put lots of e-books on it, my photos, maybe some music and that would be all. Mobile internet access would be nice, but I'm not sure it's worth hundreds of extra dollars. As for writing on the go, I find myself missing my old paper notebooks...

Until next time, I'll let you guess what I ended up buying and how it turned out.

OK, back to my favorite pastime of dismantling software developer myths. Today's topic: relational databases versus flat files.

You see, not long ago I had a lenghty argument with a fellow programmer who claimed that using flat-file storage would make a Web application such as Fcp.Commentator much slower than, say, a MySQL back-end. Yes, I've seen this opinion expressed before, and yes, I understand why he would think that, so I decided to explore the issue a little.

No, don't rush to make a benchmark. This is common sense stuff. Let's make an approximate list of the things MySQL has to do while processing a single page load on your garden-variety dynamic website:

1. hit the system database once to check whether you're authorized to connect at all;
   
2. hit the system database again to see if you have access rights to the database you asked for;
   
3. hit the system database a third time (this is becoming a habit...) to see whether the tables/columns referred in your query actually exist, and whether you are authorized to access them;
   
4. hit the tables involved (i.e. one big file apiece) and possibly several indices (even more files...) to fetch the data;
   
5. (optionally) create and use several temporary files to summarize and sort the data before finally returning it to your script.

Did I mention parsing your query and making a query plan? Which, incidentally, involves yet more hits to the filesystem to check record counts and index availability? And I'm purposefully ignoring extras like expensive algorithms or network communication overhead.

You get my drift now? Do you honestly think the above sequence of operations can be faster than slurping in a dozen (or even a few dozen) text files from the disk? Note, I'm not talking about data mining millions of records; I expect a relational database to be optimized for such applications. Certainly much more so than the naive code I'd write myself. But for simple operations such as those performed by Fcp.Commentator, using a RDBMS would be like taking a jet plane to the nearest grocery. For buying one bread.

Until next time, consider what happens behind the scenes. See ya.