Archive for April, 2010

Container Models

A long time ago a friend of mine pointed out a sign of trouble in any program: defining a new container model. If you are working in a language that provides containers in the standard library, then use them. If you need a container with specific behaviour, then make it look like the standard containers. If you come across a program which introduces a new model, beware.

I’ve recently been adding Go support to SWIG. SWIG can be used to build interfaces between various different languages and C++. SWIG is a nice program in many ways: it provides a lot of power and flexibility in defining the interface. Internally, though, big chunks are written in C++ but it uses a totally different container model. I assume this is for historical reasons dating back to a beginning in C or possibly even Python. In C++, though, it’s a mess. There is no type checking: it’s all void * pointers. Practically every type (strings, lists, hash tables) converts to everything else implicitly. It brings all the weaknesses of a pure dynamically typed language into C++, without providing any of the benefits.

Sometimes one encounters a programmer who carries a container model from program to program, rewriting it into different languages as needed. The result is a program written for one person. Don’t do that. Use a language in the idioms of the language; don’t try to make it look like a different language. Use the containers which the language provides.

Comments (4)

Elder Con

A friend (I’ll call him John) recently told me about a con that was run on his parents. The con artist called his parents home and pretended to be John. This was apparently done with a little social engineering: “Hello?” “Hi, Mom?” “Is this John?” “Yes, it’s John.” The caller excused the fact that he sounded different by saying that he had just been in a car crash, that he had been drinking at a bachelor party or something like that, and that he was now at the police station. He said he had not been able to reach his wife. He asked them to wire him some money.

Described coldly like that it doesn’t sound very plausible. But from John’s parent’s point of view, they got a call late at night, so they probably aren’t thinking completely straight, and their son is in trouble right now. You have to help your son; you don’t spend time thinking that your son might be scamming you, and you don’t think that somebody would claim to be your son when they are not. The con artist said he hadn’t been able to reach his wife, so they didn’t bother calling his house. They wired $3000 to a location in Toronto with a code word to pick it up. That money is gone.

The con artist, having succeed once, went back for a second try. He called again, saying he was now out of the police station, and needed more money to get the car fixed. This time he asked for $9000. My friend’s father dropped the money off at the wire transfer place, but on his way home realized that this didn’t sound right. He called my friend’s home, discovered the scam, and was able to get the $9000 back. The con artist made a third try a few days later, this time posing as an investigator for the money wiring company, asking for some financial details. No luck there either.

This kind of scan is particularly targeted at elderly people. As we get older we don’t think as quickly, but of course we always want to help our children. I assume that the con artist just calls numbers out of a phone book until they get a hit. On the web I found news article about the scam (my friend’s parents do not live in Tennessee).

To you, dear reader, this is just be a friend-of-a-friend story, but for me it’s just one link away. It does happen. Not only does it cost money, it makes my friend’s parents feel like idiots. You may want to mention this to your parents. The FBI has a web page listing cons aimed at elderly people, although it doesn’t seem to mention this particular one.

Comments (1)


I have no idea whether the recent SEC lawsuit against Goldman Sachs will prevail in the courts. Goldman’s defense sounds pretty good to me: the investors were presumed to be sophisticated, and they should have been able to figure out what was going on.

What ought to collapse, though, is Goldman’s reputation for putting their clients first. In this case, they permitted a hedge fund manager to select the mortgage bundles which went into the CDO, and then sold the CDO to investors, Goldman’s clients, without telling them how the mortgages were selected. That would be fine except that the hedge fund manager was betting against the clients. I can’t see any way you can spin that into saying that Goldman was looking out for their clients.

Goldman’s first business principle says “Our clients’ interests always come first.” Not in this case they didn’t.


Software Paradigms

In my youth there was a lot of support for object oriented programming. It was generally agreed that we had a software productivity problem: it was too hard to write programs. The solution was supposedly to adopt object oriented programming techniques. This was expressed in its purest form in Smalltalk, and was brought to the masses in Object Pascal (later Delphi) and C++, followed by Java.

Object oriented programming had a few different ideas, all of which centered around the notion of separating data into relatively small and independent units. Methods are defined independently of specific data, and a given method may be applied to different data units. Data units are grouped by sets of methods, and the method sets can be put into inheritance and abstraction hierarchies.

Object oriented approaches were greatly oversold, and it became clear over time that while they did have many good ideas, they were not the solution to the problems of programming. One of the problems of the object oriented approach is that it encourages you to focus on the relationship between sets of methods that apply to data, rather than focusing on the structure of the data itself. In C++ or Java terms, it’s easy to spend more time thinking about the inheritance relationships between classes than about the individual objects.

Over time, C++ shifted toward a somewhat different style of programming found in the Standard Template Library. This style is based on templates, and focuses on containers and algorithms. I’ve seen people advocate this approach to the point of saying that a good program should have no non-abstract loops: that everything should be done via an appropriate algorithm.

The issue I find with these approaches in practice is that they tend to lead to too much abstraction. Fundamentally all programs deal with data. The goal of a program is to manipulate the data in some way. The goal of abstraction and class inheritance is to permit you to write less code. The goal of data encapsulation is to make your program more maintainable over time. Abstraction beyond those points may make your program better by some artificial index, but it is not really helping you get things done.

If you find yourself asking yourself whether to introduce a new level in your class hierarchy, or you find yourself writing a new template which will only be instantiated once, then you may be falling victim to the abstraction penalty. Shake it off and return to focusing on what your program really needs to do.

Comments (3)

Oklahoma bombing

Today is the 15th anniversary of the bombing of the federal building in Oklahoma, the second worst terrorist attack in U.S. history to date. 168 people died. I’ve tried to write something about what happened and the government response, but it keeps getting more political than I really want, so I’ve given up. Terrorists are the enemy of civilization.

Comments (8)

« Previous entries Next Page » Next Page »