aporem.net

Data can be interpreted in unforeseen ways: imagine to hide a picture in the histogram of another!

The idea is great and so is the online tool to generate those.

Ovid wants a new perl book. What he really points out is that with the freedom perl gives the programmer, one needs to really grasp the concept of OO if one wants to avoid the pitfalls he mentions. The topics he suggest are essential for any book on OO, not just for perl:

Responsibility-driven design.

The difference between class and instance data/methods.

How inheritance breaks encapsulation.

When to throw exceptions.

Composition via delegation.

Class consumers versus class cooperators.

Why the Liskov Substitution Principle is important.

Polymorphism and allomorphism.

In theory, programmers always knew that creating monolithical software creates problems on the long run. But the short time gains were so alluring and sometimes one got lucky and the increases in hardware speed concealed the bad design decisions.

But now this is no more. Switching to a distributed system architecture has become inevitable once the amount of data or computation requirements reach a certain limit.

For this, programmers need to accept that they have painted themselves into a corner.

I’m still very skeptical that KDE 4 will be released as scheduled. But apparently the developers have not curbed their ambitions and are planning to release 4.0.0 by December 20.
My bet is that if they keep the timeline KDE 4.0.0 will not be a complete product.

I do not know why one would need a personal portable super computer, but sure it is a cool thing: the Microwulf 26Gflops cluster build for only USD 1,256.

Here is a list of almost dead but once popular programming languages. — Something different than the usual “currently most popular (read: hyped) languages” rankings.

Programming a multi-threaded application becomes more and more a common challenge since the dawn of multi-core processors. The problem programmers have to confront in this area are manyfold. First, one can not longer automatically benefit from Moore’s Law (i.e. the doubling of transistors on a chip every 12 to 18 months) since more cores mean more power but only if every core can be put to work. Second, the redesign needed to make use of more than one core often raises the issue of a complete rewrite — with all its dangers and implications. And there are the problems arising from the lack of tools and libraries. How does one implement locking of shared ressources? What about all the variables?
This is where Transacional Memory comes in. It tries to solve the problem of multiple threads running in a shared memory environment. While locking would work too, it does not scale well and is a real pain to take care of, since it has to be re-done for every variable introduced (or locking gets painfully slow). So putting everything into atomic transactions should help the programmer to get better results quicker.

You can read about Transacional Memory here and here.

Putting up the question whether to rewrite huge projects or not sounds like trying to start a flame-war, but surprisingly, the comments are quite sensible and lack absolute conviction.

If only all big questions in programming would be discussed in such humble ways!

The concept of Code Katas eluded me until now. But it is very intriguing, given one is able to practice on a regular basis.

For the record:

A Coding Dojo is a coding session centered around a programming challenge. The challenge is small in scope and often patterned after pragmatic Dave Thomas’ idea of Coding Kata. It is a regular programming class where programmers of varying skill levels meet as equals.

For all those, who like me looked up SOA in a dictionary and still didn’t get wise, there is a litte roundup of when to care about it and when not.

Personally, I’m sold on SOA as a concept but still wait to see it in action.