Skip to main content

Posts

Showing posts from September, 2005

Why Gorm could never be done in C++

I recently had a discussion with a friend of mine whom I work with regarding C++ vs. Objective-C. I told him about GNUstep and also showed him Gorm. I explained the dynamic features of Objective-C and compared it to smalltalk and Java.

When I showed him some images of Gorm from the GS website I told him that Gorm could not be done in C++. He took some offense to this and immediately asked me "May I ask why you believe this couldn't be done?"

I explained that, it's because Gorm uses does several things which depend on the dynamic nature of Objective-C in order to do it's job. Here is a quick summary of the features of Objective-C which Gorm uses:

1) Categories - many categories, these are used in Gorm to do the following things
a) add the name of the inspector class for each type of inspector to the class itself so that it can be looked up easily. Mainly adding the extensions from the IBObjectAdditions.h protocol.
b) Also used for editors inspectors.
2) Loadab…

The infamous "Burn-In Period"

Getting a new machine is really fun sometimes, but it can also be a royal pain in the butt. I despise the "burn-in" period (as I call it). This is the period where you need to adjust and tweek and frob every knob and adjustable piece of the machine until you get it just right.

Ironically, however, I find that this burn-in time really only happens with PCs. Particularly desktop machines. Especially expensive PCs. It seems as though the more a machine costs me, the more I have to frob with it. :/ Why is this? :) There's got to be some law of nature which makes it this way. :) Whatever the cause, there's nothing like the day when you can finally declare yourself done with all of the frobbing.

This of course, all begs the question: Why didn't I need to frob with my Mac?