Archive for January, 2010

Kinda Like Assert


In 1983 my math teacher wrote on the blackboard: P{Q}R. Ever since, my code is loaded with assertions. Assertions should be used to document logically impossible situations and discover programming errors […] This is distinct from error handling: most error conditions are possible, although some may be extremely unlikely. (Wikipedia) [Assertion] We all have seen, but never produced, anti-code like:

  assert(buf = malloc(128));

However, I have produced code like:

  assert(!"Sorry, PNG routines not implemented yet.");

Fix-me-later-code like this might get shipped (with or without NDEBUG)… and some user might try a PNG file… after six hours of typing… without saving… We have all been there. You balance a todo-list of 20 items in your head, and it won’t survive deep thought on some unlikely potential problem. Put in an quick assert() and you can continue to work on your todo-list of, now, 19. The problem is not in using the assert(), but in forgetting to replace it with real code, eventually. So here is how I make them stick out:

#define NOT_HANDLED_YET(b) \
  (void)(!(b) || exit_error("Error '"#b"' not handled yet!"))
  (void)exit_error("Sorry, "s" not implemented yet!")

The examples above would read:

  buf = malloc(128);


And remember, no commits on trunk unless grep -c NOT_ *.[ch] returns 2.

Pointer To Pointer


Some hold that pointers in a language like C are dangerous and hard to master. Both maybe true, but so are scalpels. Since you are reading this, you know that pointer practice makes pointer perfect. The same goes for pointers to pointers. I remember vividly when I first saw some elegant code that used a pointer to a pointer (I was working on Amoeba). It was a coding changing event. Before I would write like:
Picture 2
After I would write:
Picture 3
I’ve even used that last bit of code in job interviews. If some self proclaimed hardcore C coder could not explain those lines of code I would know they were no experts. Now that this trick is out of the bag, I will have to use an other one, next time we meet.

Nice Language for Testing GUI Apps

1 Comment »

Sikuli is a research project developed by User Interface Design Group at the MIT […] Sikuli Script automates anything you see on the screen without internal API’s support. You can programmatically control a web page, a desktop application running on Windows/Linux/Mac OS X, or even an iphone application running in an emulator. [Project SIKULI homepage]
From the paper, it shows that Sikuli Script is motivated by the desire to address the limitations of current automation scripting languages like: AppleScript, Windows Scripting, DocWizards, Chickenfoot, CoScripter, and macro recorders like Jitbit9 and QuicKeys. On Slashdot it is promoted as quite a bit more. See [MIT Offers Picture-Centric Programming To the Masses With Sikuli]. Personally, I think, picture-centric programming for the masses will have to wait, but Sikuli is perfect for writing test programs for GUI applications. Thank you MIT for a scripting language that is reasonable indifferent to GUI element alignment changes.

Windowcitis Can Be Contagious

servet8In 2004 I had to make a set of napkins and tablecloths of a unique design. The theme was fallen leaves of the fern-leaved beech (Fagus sylvatica ‘Asplenifolia’). I decided to use PostScript (Ghostscript actually). It has instructions like infill to test collisions, it shrugs at using an aspect-ratio of 28×36 threads per cm and it is very intuitive. I could preview (in the after-shrink aspect-ratio) on screen and paper. I used a very naive algorithm. 1) Generate a unique leaf 2) pick a random position and direction for it and 3) shift it along until it did not collide with anything. It worked wonders. I could generate a napkin of 81×81 cm with 555 leaves in a few minutes. However doing the 2000 leaves of the tablecloth took much longer. About 32 hours. Since I had to send the CD to the weavery in two days, I started it on my wife’s computer and let it run. About 31 hours later my, than, 10 year old son came to me for some help with a computer game… You guessed it, he had rebooted the computer because it was acting “funny.” (It was running FreeBSD.) I could not blame him, rebooting is normal behavior for a Windows user. With the deadline four hours away, I had no choice but optimizing the code for three hours so I could generated the table cloth in minutes.
There are two lessons I learned. First, you can be hit by someone else’s windowcitis, and second sometimes optimizing can lower the risk of failure in unexpected ways. Speaking of lowering failure risk, nowadays all my family members run OS X.

Random Ordering

No Comments »

bugReplies to problems posted on are ordered by vote. So if you put up a question like “What are your best programmer/computer science/programming jokes?” you end up with an randomly ordered list of nerd-jokes. For example: An SQL query goes into a bar, walks up to two tables and asks, ”Can I join you?” is rewarded close to 900 points. Where When your hammer is C++, everything begins to look like a thumb. scores significantly lower. And If you put a million monkeys at a million keyboards, one of them will eventually write a Java program. The rest of them will write Perl programs. even lower. Pure random. To make it more complex some responses all most out-score the “answers” they comment on like: Jesus saves, but only Buddha makes incremental backups. Wanna read more? Go a head, lose your day.

Definitely Worth a Cat

No Comments »

microwave-cdA few months ago we bought a new digital camera, […] it came bundled with a CD of software. So [my wife] innocently ejected the DVD tray, and dropped the CD in. I happened to notice out of the corner of my eye […] screamed “noooooooooooo,” and frantically launched myself across the room in a desperate attempt to keep that CD from launching […] I nearly took out a cat in the process. […] Nobody hates software more than software developers. (Jeff Atwood) [Nobody Hates Software More Than Software Developers]

If Coders Made Ads

No Comments »


Laziness, Impatience, and Hubris


larrywallLaziness, impatience, and hubris: the three qualities that make a programmer. If you are lazy you look for shortcuts. If you are impatient you want your program to be done now. And as for the hubris, that makes the programs easier to distribute. […] We use natural language—most people think COBOL—and that’s not how we think about it. Rather, the principles of natural language are that everything is context sensitive and there is more than one way to say it. You are free to learn it as you go. […] We don’t expect a five-year-old to speak with the same diction as a 50 year-old. The language is built to evolve over time by the participation of the whole community. Natural languages use inflection and pauses and tone to carry meanings. These carry over to punctuation in written language, so we’re not afraid to use punctuation either. […] Do you have a release date for this yet? […] Sure, It’s Christmas Day—we just don’t say which one. […] We’re certainly well into the second 80 percent. (Larry Wall) [The A-Z of Programming Languages: Perl]

State a good design principle and people mock you. Look for example at a snippet form The Reg:
Larry said: “Similar things should look similar but similar things should also look different, and how you trade those things off is an interesting design principle.” It’s very Zen, but this is standard issue for Perl developers: the way you understand a Perl program depends on how you read it. Those seeking the path to enlightenment should probably start with Perl 6 interpreters. (Ted Dziuba) [Larry Wall on the Zen of Perl 6]

I have to wonder if Ted Dziuba lacks the intelligence and/or relevant experience, or if he tries to insult my relevant experience.

Disgrunted IT Employees Everywhere

1 Comment »

In 2007, about 12% of the IT employees fit in category of “highly engaged” workers, but that has since fallen to 4%. “These […] most critical employees,” […] [are] 2.5 times more likely than the average employee to be looking for new opportunities. […] “The folks at Apple Computer […] are unlikly to be looking elsewhere. […] Employees elsewhere “are going to be shopping for […] purposefulness,” […] A Dice survey of 360 people in August found that over a third were planning to change jobs once the job market improves. (Patrick Thibodeau) [Surveys: IT job satisfaction plummets to all-time low]

So what is the point? Go else where or stay because it is no fun else where either? Or is it, maybe, change jobs often?