Where did they keep it in the meantime? They implanted it in his abdomen.

That's both "ewwww" and "cool" at the same time.

1:03:29 PM    comments ()  trackback []  

Most everybody stores graphic object definitions outside the source. (The Amiga didn't, you declared instances of UI objects, and filled out all the fields by hand.) Most made you explicitly code the event loop and decode your own events.

That always bugged me. Most event loops looked the same. Examine the event, and then go through some elaborate switch depending on the type of the event. That never made sense to me. Why do I have to create an event loop for each program? The vast majority of the time, they all worked the same way. And when they didn't it quite often led to some strange error that took me weeks to track down.

I love the way Cocoa works. You use Interface Builder to create the UI objects, define all the connections, and then save the object network. In your code, the only things you have to worry about are those bits of code that make your application unique.

I started thinking about this when I was perusing the documentation for PyObjC, and they made mention of the fact that PyObjC programs tend to look smaller than equivalent Tkintr or wxPython programs, because the only code that's there is the code that directly concerns your application's unique behavior. There is none (or very little) of the standard UI boilerplate in there.

Another common UI toolkit activity is coming up with unique event codes for each menu item or button. Why do I need to concern myself with that? Why can't I just tell the system to call this code when this menu item is selected or this other button is pushed? Why do I have to remember that event codes lower than 1000 are reserved for the system (or something like that)? I don't care. The only thing I really care about is that my code gets run when the UI gets frobbed in a certain way. I don't really care about how it's handled under the covers (unless it's done in some egregiously horrible way).

Every time I start writing boilerplate code, I feel like I'm engaging in some activity designed to weed out the less-worthy. Real Programmers would put up with it! Real Programmers would use a programming language that forces you to care about the endian-ness of the underlying system! Real Programmers want to rewrite the standard library functions because they thnk they can do it better!

Bah. I'm not writing operating systems anymore. I don't need to prove that I can.

Okay, so I got a little more ranty than I expected.

11:11:03 AM    comments ()  trackback []  

I'm impressed. You have several options for creating applications -- Completely standalone, Mostly standalone (but requires a pre-existing python installation), or an application that requires a pre-existing PyObjC installation as well as a pre-existing python installation (which comes with OS X by default).

I've played with it before, and while I was amazed at what the PyObjC team has accomplished (my hat is off to you, guys), I was a little surprised at how long it took an application to start up. In the 1.0 version, startup time has drastically improved, and you can create an entire standalone application without ever starting Project Builder (although you'll need to use Interface Builder to create your NIB files).

The examples provided with the installation are quite impressive, and the Python Object Browser example (using multi-column tree views) was breathtaking, in that it demonstrates something that I've wanted very badly. I love it when I see something that causes me to coalesce a number of ideas into a project plan, and I think exactly that is happening. I expect to soon begin coding quite a bit, and I hope to have something to demonstrate eventually. There is a project that has been taking shape in my head for years, and I think I finally have all the pieces I need to make it come together.

By the David Brown "How much excitement does it generate" 1-10 scale of coolness, PyObjC gets a 9. (If it was cross-platform, it would be a 10.)

Download it, check it out, build something cool. I'll be right there with you.

10:09:26 AM    comments ()  trackback []  

And now the Cubs are done. There's something very anticlimactic about the way most baseball games end -- it's usually a quick groundball somewhere, or a pop fly. The ball goes into a glove, and that's it. Game over. One quick play and an entire season ends.

If the Yankees beat the Red Sox today, I won't be watching the World Series at all.

This year, I watched fewer games, but I feel like I was in better touch because I discovered this mailing list called "Around the Majors" (otherwise known as ATMREPORT, as the emails are captioned). You can find out how to join it at http://baseball-encyclopedia.com -- it comes out once or twice a day, and when big events happen, like when a major trade occurs or when a championship series is concluded. Give it a try, it's quite interesting, if you like baseball.

8:52:38 AM    comments ()  trackback []