Poetry (…) is an abstract block of words in which every one must carry meaning if the poem is to be any good. We value the poem for the beauty not only of the story or image given, but of the way in which it is constructed as well. It tends to be much denser and more compact than prose. When you read it, you must proceed carefully and consider the meaning of each word, and each group of words, and pay attention for double meanings and allusions if you are to grasp it fully.

There has been a BBC Radio show observing the anniversary. And for the historically interested, there is an interview with John Backus, the team leader developing the first version from 1979. Telepolis has an article (in German) too.

Happy 20th anniversary Perl!

Parts of the dataset of the Netflix prize have been de-anonymized. There have been other successful de-anonymizations of public datasets but most of the time it was caused by a sloppy anonymization process. This time it’s different. It is an inherent problem of the data, so even sophisticated randomization of the data would not have made a real difference: the data in the dataset of Netflix can be linked directly to user content on publicly available websites. This reveals the fundamental issue within; the data users leave willingly or unwillingly can be reassembled wether they like it or not.

The first is for minor upgrades, the second for major version changes.

Very neat thing, this freebsd-update tool, indeed. But beware, it only works for Releases and only with generic kernels, so perhaps you are in for a make && make insallkernel && make installworld routine for one last time.

The answer given by Ned Batchelder is concise and in my opinion a great starting point not just for children. The main point is that there is no single best choice and that the language would be a means to an end and not an academic pursuit in itself. This is quite close to the general definition of a sound choice of a programming language and every developer should ask himself this question for every job at hand!

But coverage testing is not so easy as it seems. One can give simplistic examples which have 100% test coverage but still are buggy. The reason is simple: branching (and combination of paths) can produce a plethora of possibilities. But once every line of code is executed once, by definition, the coverage is 100%, although not every permutation has been tried.

An introduction to this topic can be found in Ned Batchelder’s blog, more at Wikipedia and here.

Keeping the design simplicistic means risking extensibility and maintainability. Even though it’s easy now, no one will remember the ad-hoc decisions made during coding.

The opposite extreme is over-engineering, the fiddling with the design to make it even more pluggable or extensible or use the newest patterns. Especially seasoned developers are prone to this behavior.

To counteract these extremes and in particular the second there is the “Make it Work First!” motto. It helps to get a first look and feel of the program while requiring to keep an eye on the ease of refactoring since the first version will have to be modified almost surely.