Twitter? Twucket.

posted by jack at 11:11 CET in / compute / programming

Just in time for WWDC '08, allow me to introduce you to Twucket.

Twucket is a new Twitter client for Mac OS X that I am releasing as freeware. I created Twucket because I wasn't happy with any of the available ways to view my Twitter page. The actual twitter website is a hugely-rendered page, and requires you to go to the browser now and then to see if anything has come in; The standalone clients I tried were either wasteful of screen real estate, or didn't fit in with the overall Mac GUI, or contained ads.

Twucket suffers from none of those problems. Its interface is minimalist and small, it behaves like a normal Mac application, and it doesn't insert ads into the display. What it does offer is a compact, simple Twitter interface with a few features that Twitter users will probably appreciate. It uses a relatively small amount of screen real estate per message, so you can leave a small window open in a corner of your screen that is still large enough to show the latest 4 or 5 messages you've received.

I do have additional plans for future versions of Twucket, but today is the day for 1.0.0. If you're a Twitter user, please give it a try and let me know what you think!

Defective C++

posted by jack at 11:12 CET in / compute / programming

At my previous job, I worked as a C++ programmer. The job, which started out primarily working with Objective-C and Objective-C++ to port a Windows application to Mac OS X, became progressively more a C++ job as time went on. I came to learn C++ fairly well, just enough to realize how much I dislike it. I haven't properly been able to summarize just why I dislike C++ so much, but fortunately someone else has: The Defective C++ page, part of the larger "C++ FQA", lays bare a number of problems inherent to the design of the C++ language.

In less than two years of C++ usage, I encountered nearly every one of these problems. Some of them can be dealt with by deciding upon and following "best practices" within the team, which we did (to give credit where credit is due, the more experienced C++ developers I was working with pretty much laid out the best practices for the rest of us to follow), but some of them are just things that you pretty much have to live with, and end up turning the development process into a real straightjacket.

(via Another Day in the Code Mines, which had picked it up from a discussion at Joel On Software; check out the comments in that discussion if you want to see some extremely blindered C++ apologists in action...)

RoR etc

posted by jack at 13:02 CET in / compute / programming

OK, i haven't posted in ages, but what can I say, life is keeping me busy. Recovering from a bit of minor surgery, followed by a long Easter break, followed by stomach flu, consumed the past few weeks.

But, more importantly than all that, I changed jobs at the end of January, and am now spending most of my work time (not to mention free time) programming with Ruby on Rails!

Ah, ruby. I've used python for a variety of side projects over the past few years, and I've long held the opinion that the two languages are largely equal, but in the short time since I started using ruby full-time, I'll admit that I've started acquiring a definite ruby bias. Things like ruby's block syntax, for instance, don't really have a corresponding language feature in python (at least, not anything quite as succinct).

Above all though, I'm mainly happy to be back in the world of dynamic languages. At my last job, I spent two years using C++, which taught me a lot: mainly that I don't like C++. In fact, I've started to get the feeling that using C++ at all, when other options are available, is in many cases a textbook example of premature optimization. You end up consuming lots more programmer-hours (which means greater expense, and later releases) chasing the chimera of an end-product which "runs faster" than a similar program written in a dynamic language would run. I put "runs faster" in quotes because in reality, most software is I/O-bound most of the time (either waiting for user input, or waiting for disk or network traffic), so the amount of time that your particular program is actually running is probably pretty small (and getting smaller as CPU speeds increase), no matter what language it's written in.

huge volumes of pointless syntax

posted by jack at 14:22 CET in / compute / programming

It's high time for the next installment in my irregular series of C++ rants. This time I'm going to talk about expressiveness (or rather, C++'s lack thereof)

Expressiveness indicates a capability to accurately and briefly express something. A human being is considered to be expressive if they are able to speak in such a way that someone listening to them can quickly understand the person's message. A computer language's expressiveness is a measure of how quickly a programmer can write code that is unambiguous and a correct reflection of the design in the programmer's mind.

Let's illustrate this with an example. Imagine we've got a class with an instance variable containing an array (or list, or vector, or what have you) of some other type. We want to give our class a method that takes another array, iterates through all the objects in it, and adds them to its own array. Obviously this is a contrived example, since nearly all container classes in all languages must include functionality for adding the contents of one array to another, but the point here is to demonstrate how a simple iteration is done.

Let's start off with the C++ version, something like this:

class ValueContainer
{
    // a vector containing Value objects
    std::vector<boost::shared_ptr<Value> > m_values;

    void addValues(std::vector<boost::shared_ptr<Value> >values)
    {
        // an iterator pointing at the first value
        std::vector<boost::shared_ptr<Value> >::const_iterator it = values.begin();
        // an iterator pointing at the special "end" value indicating we've reached the end
        std::vector<boost::shared_ptr<Value> >::const_iterator endIt = values.end();

        // step through the entire array
        for (; it != endIt; ++it)
        {
            // add the value to our array
            m_values.push_back(*it);
        }
    }
};

Some of you may be unfamiliar with the boost::shared_ptr stuff in there. The boost project is a sort of proving ground for classes that are probably destined for the standard c++ library in the future, and shared pointers are a very valuable concept that make c++ development a little more do-able, by helping you manage object ownership.

Anyway, that's quite a pile of code, isn't it? All we're doing is walking through a list of things!

Some may balk at this, saying that the boost shared pointers are overkill here. OK, fine, let's take those away, and take away the comments, and stuff all we can into the for, getting this down as tight as we can:

class ValueContainer
{
    std::vector<Value> m_values;

    void addValues(std::vector<Value> values)
    {
        for (std::vector<Value >::const_iterator it = values.begin(); it != values.end(); ++it)
        {
            m_values.push_back(*it);
        }
    }
};

Now let's see how a similar class might look in python:

class ValueContainer:
    def __init__(self):
        self.values = []

    def addValues(self, values):
        for v in values:
            self.values.append(v)

Unlike C++, Python has no free-standing declarations of instance variables--they're defined only as they're referenced inside of methods, and the best practice is typically to provide an initial definition inside the initilializer method __init__ as I've done here.

There are several nice things about Python that this highlights:

• the syntactic indicator that we're dealing with an instance variable by always prepending self.
• the more sensible method names in Python's array class compared to C++'s std::vector class (append vs push_back)
• the values parameter isn't statically typed, so it doesn't need to actually be a standard python array, but can be any class that implements the methods required for iteration

Look at the mass of ugliness in the C++ for construct. To start off with, you're forced to declare a variable with a bizarre iterator type. Why should I have to care about that? I'm not using it in any way; that type is completely irrelevant to my code. Later, to iterate I have to use it++, which may not be pointer arithmetic, but at least looks like pointer arithmetic, and that is just so 1985.

Then, take a look at the simplicity of the Python for construct. The designers of Python built iteration right into the language! You simply give for the name of the variable that should be used to hold a value from the array, and the array itself, and off it goes. Behind the scenes, iteration occurs through well-defined methods, and if you're making your own collection class you can define your own iteration scheme, but all of that is completely invisible to a user of the class.

IMHO, this sort of thing is really one of the biggest wins for languages like Python. You get to leave out all sorts of meaningless busy-work, since the language includes useful mechanisms that C-based languages don't, and you are left with the job of programming the actual functionality you're after.

class ValueContainer {
    std::vector<Value> m_values;
    void addValues(const std::vector<Value>& values) {
        std::copy (values.begin(), values.end(), std::back_inserter(m_values));
    }
};

    def addValues(self, values):
        self.values.extend(values)

        for (std::vector<Value >::const_iterator it = values.begin(); it != values.end(); ++it)

        for (auto it = values.begin(); it != values.end(); ++it)

The Horror of Compile-Time Binding

posted by jack at 20:16 CET in / compute / programming

I'm working on this C++ project, and suddenly realize how much we're using the visitor pattern. The point of the visitor pattern is to extract non-core functionality out of data-bearing classes, instead gathering that functionality into a visitor class that knows how to operate on all the data-bearing classes. You do this by making each "visitable" class implement a method that accepts a visitor object, which in turn calls a method in the visitor to do its work, along these lines:

void MyClass::accept(Visitor &v)
{
    v.visitMyClass(this);
}

That way, new visitors can be created to implement new functionality involving visitable classes, without the visitable classes needing to be changed or even recompiled. Here's where the fun kicks in. For each new "visitable" class I add, I need to add a member function for each existing visitor, which means editing dozens of .h and .cpp files, adding a small "visitXXX" member function to each.

The kicker is that most of the functionality we're implementing with visitors consists of either trivial one-liners or empty implementations for most of the visitable types. So we have visitor classes containing dozens of identical member functions. Nothing quite like the joy of editing dozens of files to insert meaningless boilerplate code!

At first I wondered what my co-workers were thinking when they set out on this path, but eventually I came to realize, much to my chagrin, that this is an inescapable reality of C++ programming in many situtations, thanks to the compile-time binding that C++ does. The compile-time binding actually precludes you from doing certain things without this sort of indirection.

To see why this is, first consider an example that demonstrates how things can work in a more full-featured OO language, such as python. Consider the following python program:

class A:
    def emit(self):
        print "Class A"

class B (A):
    def emit(self):
        print "Class B"

a = A()
b = B()
a.emit()
b.emit()
print "-----"
objects = [a, b]
objects[0].emit()
objects[1].emit()

Class A
Class B
-----
Class A
Class B

And your common sense would be right. Whe calling the emit method on the a and b objects, the correct method is triggered and the corresponding class names are output.

Now then, considering the following C++ program:

#include <iostream>
class A
{
public:
    virtual void emit() {
        std::cout << "Class A\n";
    }
};
class B : public A
{
public:
    virtual void emit() {
        std::cout << "Class B\n";
    }
};
int main (int argc, char * const argv[]) {
    A a;
    B b;
    a.emit();
    b.emit();
    std::cout << "-----\n";
    A objects[] = {a, b};
    objects[0].emit();
    objects[1].emit();
    
    return 0;
}

Does your common sense tell you this program should have the same output as the earlier python version? Think again:

Class A
Class B
-----
Class A
Class A

Say what? "But, but, but, I put an instance of B in that array, wtf?" Well, here's where C++'s compile-time binding came and shot you in the foot. Note that C++ doesn't offer any sort of generic array of objects. Whether using a C array as I've done, or a std::vector object, you must indicate the type of the object, in this case the root of our hierarchy, A. C++ then makes use of this type information when your program is compiled to match up the call to emit with the implementation in the named class, rather than the implementation in the derived class you're actually instantiating! Doh!

This has dire consequences for any situation where you've got a collection of objects of varying types. Say you've got a bunch of model classes, and you'd like each class to emit an xml string containing its values. In Objective-C, Python, Ruby, Smalltalk, and probably even Perl and Javascript, this is pretty straightforward; You just give each class a method that emits a string (and, assuming you've got an acyclic directed graph, calls the emitting method in each of its "child" objects). Then you just call the emitting method in the root object, and away you go. For example, once again consider some python:

class RootElement:
    def emitXml(self):
        print "<root>"
        for child in self.children:
            child.emitXml()
        print "</root>"
class SomethingElement:
    def emitXml(self):
        print '<something value="', self.value, '"/>'
class SomeoneElement:
    def emitXml(self):
        print '<someone value="', self.value, '"/>'

r = RootElement()
c1 = SomethingElement()
c2 = SomeoneElement()
c1.value = "first child"
c2.value = "second child"
r.children = [c1, c2]
r.emitXml()

Now then, that code outputs about what you might expect:

<root>
<something value=" first child "/>
<someone value=" second child "/>
</root>

Simple, right? Well, if you try to do something similar in C++ (or Java for that matter), you'll run into trouble. You can start by giving your element classes a common parent declaring emitXml (don't need to bother with such a thing in python, where method calls aren't bound to implementations until runtime), but as soon as you have something like RootElement maintaining a list of child elements, you'll hit the same snag in our earlier example; the relevant implementations of emitXml will be passed over in favor of the generic implementation in the parent class.

Which is where the visitor pattern comes in. It's basically a kludge to work around the compile-time binding limitation of C++. Even when there are times you'd want to use it in order to extract responsibilities out of a data-bearing class, you still end up with this ridiculous double-dispatch syntax (compare with Objective-C, where you can actually add methods to an existing class by using a category, so you can accomplish the same design feat of grouping functionally-related methods together, yet outside the classes they operate on, without the artifices of the visitor pattern).

The moral of this story is that the visitor pattern is a necessary evil for statically-bound languages like C++. And that if you want to avoid this evil thing, start by avoiding C++. Really, pick up python or ruby or Objective-C or whatever. Really!

[update] fixed some typos, thanks weinholt

class ValueContainer {
    std::vector<Value> m_values;
    void addValues(const std::vector<Value>& values) {
        std::copy (values.begin(), values.end(), std::back_inserter(m_values));
    }
};

    def addValues(self, values):
        self.values.extend(values)

        for (std::vector<Value >::const_iterator it = values.begin(); it != values.end(); ++it)

        for (auto it = values.begin(); it != values.end(); ++it)

Your Comment