Goldenseal Pro has a new, single-window appearance. To move between different functions, you click on on tabs rather than separate windows. We’ve used it enough now to really like the change.
Unfortunately, the tab view has had a serious bug: crashing after a few tab switches. It started about a year ago, when we updated to Apple’s newest memory management system. About once a month, we’ve spent a day or two trying to fix it, without success.
Our staff spent most of the past week attacking it again. We finally cracked it Wednesday, with help from folks on the Cocoa Developer Forum. The root cause was some unexpected behavior in Apple’s NSTabViewController class, complicated by the fact that we can’t see Cocoa source code.
We have been using Apple’s Cocoa framework for 2.5 years now. It is probably the most difficult programming environment our staff has ever used. Unfortunately, there are no viable alternatives for building software that runs on future versions of Macintosh OS. We are getting there, but it has been a real struggle.
As an attempt to quantify the difficulty of programming environments, I’ve decided to invent the Serius Scale. It’s a measure of programmer pain.
0 on the Serius Scale is an absolute joy for programmers. Productive days that create useful code, quickly. 10 on the scale is a tool that causes maximum frustration, and never results in anything useable. Right now, I’d rate Cocoa at about a 6, maybe a 7. Apple really could do better.
The scale is based on Serius Developer, a software development tool that came out in 1989. It had an amazing demo that included a built-in spreadsheet. We were desperate for a better platform for our construction estimating and accounting software, so we plunked down $2000 for it.
Unfortunately, we soon discovered that their spreadsheet tool was hard-coded to run the demo, and nothing else. Other features were similar. There was no way to get it to do what we wanted. Serius was a totally useless black box. Its developer later moved on to start a Ponzi-like Internet company, then got into space aliens. So, I’ll rate his software a 10 on the eponymous Serius Scale.
Before that, TurtleSoft started out in 1987 with simple construction estimating templates for Excel. They took less than a year to develop, and sold like hotcakes. That was a fantastic time to be in software.
I’d give early versions of Excel a 1 or 2 on the Serius scale. The macro language had its quirks, but it was pretty decent for its day. Things improved in Excel 2.2 and 3.0, but then went seriously downhill. Excel 4.0 added a bug that randomly changed our code. Then the macro language was replaced with Visual Basic. That’s why we were so desperate to find a better way to produce software.
Back then, we also shipped a few products based on Apple’s HyperCard. It was a fun app that could whip up something functional, very quickly. At the beginning, I probably would have given it a pain-free 0 or 1. Unfortunately, after using it to build real software, we discovered race conditions. HyperCard worked by passing messages around, and they weren’t always received in the same order. It made hard-to-find, intermittent bugs. Apple never fixed them. Instead, HyperCard languished, and was never updated for OS X. I guess the net result is a high Serius number. It just never lived up to its potential.
After fiddling with FileMaker, Omnis, Double Helix and a half-dozen other platforms, we finally decided to use plain old C++ for Goldenseal. It was built upon the PowerPlant framework that came with Metrowerks CodeWarrior. Basic, but easy to understand. About a 2 on the Serius scale. They were a small, competent company. Very pleasant to work with. Life was good again, for a while.
Unfortunately, Metrowerks was bought and strip-mined by Motorola. They sold off the Intel version of CodeWarrior a month before Apple switched from Motorola chips to Intel. A quick end for CodeWarrior and PowerPlant.
Unfortunately, this post has been using “unfortunately” a lot. We would like to spend our time writing code for estimating, accounting, payroll, and other functions that users need. But, looking back, at least 75% or 80% of our programmer days have been spent on OS and hardware issues Too much time struggling with tools that are high on the Serius Scale.
The good news is, we are making progress. It’s hard, but not impossible.