So when I wrote that post yesterday, to my surprise I found three other draft posts of varying ages. I know myself well enough to know that I probably won't go back and revisit them, so here's what they were about:
Salling Clicker
That's all that was in this one - just the title. I know what I was going to say though. I was going to heap praise on this tiny but personally very useful app.
I have a beautiful (expensive) Sony LCD TV in my living room with a very handy VGA port. My computer is right nearby so it's permanently connected. What Salling Clicker does is provide a way to control my computer from my mobile phone via Bluetooth or Wifi. This is amazingly useful when watching movies from the couch.
The interface is solid and deployment is very easy. Best of all, it's cheap.
Understanding threading is more important than ever
This was a post I was going to write about a now old Ars Technica article. The article was about the future of processors according to Intel where they suggested there'd be many many cores, not just two or four. I didn't get too far on my post:
We were taught threading in the very first programming subject I took at uni. Initially, it can be difficult to get your head around. Eventually I got there. I was convinced though that plenty of people passed that course without any firm idea of how threading worked.With the announcement from Intel that they're heading down the track of many, many CPU cores, understanding threading is more important than ever for a budding software developer.
What I was going to get to was that developers will have to start thinking about parallel processing. If we're stuck on 3GHz per core and you want to do some crazy-complex stuff, it better be able to be spread across the cores or it will be S.L.O.W.
Will the compiler/OS/processor be able to handle this for you? Well, yeah, possibly to an extent, but writing your software to take advantage of new processor capabilities will be a necessity for performance.
At the very least, you'll have to have a detailed knowledge of how threading works. It's the future, man.
Religious Coding
The oldest draft of the lot was also the closest to being finished. Here's what I wrote, minus the half-written final sentence (seriously, I stopped halfway through a sentence):
I stumbled across this article called "The Narcissism of Small Code Differences" via Reddit. Basically, it presents an allegorical scenario where programmers with different ideologies replace each other's code with their version of how it should be done.The point is that these hypothetical programmers - each idealists in their own particular way - are more concerned with the "best" way of doing something than they are with the intended purpose.
Firstly, let me say that I think the story is slightly flawed - a suggestion backed up by many of the comments below the article. This is mainly because the "good" agnostic programmer who wrote the original working code doesn't seem to have included any inline comments that would have prevented the errors that were introduced later.
That said, I definitely agree with the tacit suggestion that sometimes it's not necessary to work out the most pure way to write some code. This is particularly true when the behaviour of the component or method you're writing has a very limited and well-defined scope such as the one in the example.
I've got to admit that my immediate thought when I read the snippet of code at the top was that it wasn't particularly elegant and that it could probably be done in a more concise way (a la the Librarian in the code).
I think what I was going to get to was a comment about comments. Who cares how the code is written (within reason) as long as it does what's intended. The problem was that the intention was never documented in the code.
Now, for such a simple method, the thinking is that you don't really need comments - it's pretty plain what it does - it pads a number with zeros to make it five digits long. The problem is that nowhere is it written that a two-digit input is invalid, and that's where the my-code-is-better-than-your-code comes in.
I'm sure I've said this before, and so have others, but comments should be used to explain why you're doing something, not how. Other programmers can see how you've done it, but they don't know what you were thinking.
Anyway, that's it - drafts cleaned up. Feel free to leave comments about any of them!