Yeah, we've got one of those

Title linkey (which I discovered via slashdot) goes to an interview in DDJ with Paul Jansen, the creator of the TIOBE Programmer Community Index, which ranks programming languages according to their web presence (i.e. the size of the community interested in those languages). From the interview:

C and C++ are definitely losing ground. There is a simple explanation for this. Languages without automated garbage collection are getting out of fashion. The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection.

So, to those people who balked at Objective-C 2.0's garbage collection, on the basis that it "isn't a 4GL", I say who cares? Seemingly, programmers don't - or at least a useful subset of Objective-C programmers don't. I frequently meet fellow developers who believe that if you don't know which sorting algorithm to use for a particular operation, and how to implement it in C with the fewest temporary variables, you're not a programmer. Bullshit. If you don't know that, you're not a programmer who should work on a foundation framework, but given the existence of a foundation framework the majority of programmers in the world can call list.sort() and have done with it.

Memory management code is in the same bucket as sorting algorithms - you don't need for everybody to be good at it, you need for enough people to be good at it that everyone else can use their memory management code. Objective-C 2.0's introduction of a garbage collector is acknowledgement of this fact - look at the number of retain/release-related problems on the cocoa-dev list today, to realise that adding a garbage collector is a much bigger enhancement to many developers' lives than would be running in a VM, which would basically go unnoticed by many people and get in the way of the others trying to use Instruments.

Of course, Objective-C and ApPLE's developer tools have a long history of moving from instrumental programming (this is what the computer must do) to declarative programming (this is what I am trying to achieve, the computer must do it). Consider InterfaceBuilder. While Delphi programmers could add buttons to their views, they then had to override that button's onClick() method to add some behaviour. IB and the target-action approach allow the programmer to say "when this button is clicked, that happens" without having to express this in code. This is all very well, but many controls on a view are used to both display and modify the value of some model-level property, so instead of writing lots of controller code, let's just declare that this view binds to that model, and accesses it through this controller (which we won't write either). In fact, rather than a bunch of boilerplate storage/accessors/memory management model-level code, why don't we just say that this model has that property and let someone who's good at writing property-managing code do the work for us? Actually, coding the model seems a bit silly, let's just say that we're modelling this domain entity and let someone who's good at entity modelling do that work, too.

In fact, with only a little more analysis of the mutation of Objective-C and the developer tools, we could probably build a description of the hypothetical Cen Kase, the developer most likely to benefit from developing in Cocoa. I would expect a couple of facts to hold; firstly that Cen is not one of the developers who believes that stuff about sorting algorithms, and secondly that the differences between my description of Cen and the description used by Apple in their domain modelling work would fit in one screen of FileMerge on my iBook.

Tracking the invisible, moving, unpredictable target

An idea which has been creeping up on me from the side over the last couple of weeks hit me square in the face today. No matter what standards we Cocoa types use to create our user interfaces, the official Aqua HIG, the seemingly-defunct IndieHIG, or whatever, ultimately producing what is considered a usable (or humane, if you like) interface for Mac OS X is not only difficult, but certainly unrepeatable over time.

The "interface" part of a Cocoa user interface is already hard enough to define, being a mash-up of sorts, and to differing degrees, between the Platinum HIG which directs the default behaviour of some of the *Manager controls and the OpenStep HIG which describes the default behaviour of most, if not all, of the AppKit controls. If that isn't enough, there is an inexact intersection - some controls work differently in (what are loosely called, and I'm not getting into the debate) Cocoa apps than in Carbon apps. There have also been innovative additions on top of the aforementioned guides, such as sheets, unified toolbars and (the already legacy) textured interfaces. There have been subtractions from both - miniwindows still exist but nobody uses 'em, and window shading went west with Rhapsody.

But all of that is related to the user interface, not to user interaction (I'm in the middle of reading Cooper's The Inmates Are Running the Asylum, I'm going to borrow some terminology but studiously avoid discussing any of the conclusions he presents until I'm done reading it). It's possible to make HIG-compliant inspectors, or HIG-compliant master-detail views, or HIG-compliant browser views and so on. It's also possible to make non-compliant but entirely Mac HID views, coverflow views, sidebars and so on. But which is correct? Well, whichever people want to use. But how do you know which people want to use? Well, you could get them to use them, but as that's typically left until the beta phase you could ask usability gurus instead. Or you could take the reference implementation approach - what would Apple (or Omni, or Red Sweater, or whoever) do?

Well, what Apple would do can, I think, be summed up thus: Apple will continue doing whatever Apple were previously doing, until the Master User takes an interest in the project, then they do whatever the Master User currently thinks is the pinnacle of interaction design. The Master User acts a little like an eXtreme Programming user proxy, only with less frequent synchronisation, and without actually consulting with any of the other 26M users. The Master User is like a reference for userkind, if it all works for the Master User then at least it all works for one user, so everyone else will find it consistent, and if they don't find it painful they should enjoy that. The official job title of the Master User role is Steve.

All of this means that even inside Apple, the "ideal" usability experience is only sporadically visited, changes every time you ask and doesn't follow any obvious trend such as would be gained by normalisation over the 26M users. Maybe one day, the Master User likes inspectors. Then another day he likes multi-paned, MDI-esque interaction. On a third day he likes master-detail control, in fact so much so that he doesn't want to leave the application even when it's time to do unrelated work. Of course you don't rewrite every application on each day, so only the ones that he actually sees get the modernisation treatment.

So now we come back to the obvious, and also dangerous, usability tactics which are so prevalent on the Windows platform, and one which I consciously abhor but subconsciously employ all the time: "I'm the developer, so I'll do it my way". Luckily there are usability, QA and other rational people around to point out that I'm talking shite most of the time, but the reasoning goes like this. I'm a Mac user, and have been for a long time. In fact, I might know more about how this platform works than anyone within a couple of miles of here, therefore(?) I know what makes a good application. One problem which affects my personal decisions when trying to control the usability is that I'm only tangentially a Mac person, I'm really a very young NeXTStep person who just keeps current with software and hardware updates. That means I have a tendency to inspector my way out of any problem, and to eschew custom views and Core Animation in favour of "HIG is king" standard controls, even when other applications don't. And the great thing is that due to Moving Target reference implementation, I can find an application which does something "my" way, if that will lend credence to my irrational interface.

The trick is simply to observe that taking pride in your work and expressing humility at your capabilities are not mutually exclusive. If tens of other Mac users are telling me they don't like the way it works, and I'm saying it's right, apply Occam's razor.

And if there isn't enough fun for you in one usability experience, a bunch of us are presumably going to be providing the iPhone HIG-compliant V on top of our Ms and Cs before long.

Come back, purple button, all is forgiven!

As a great philosopher once wrote: don't it always seem to go, that you don't know what you got 'til it's gone? Previews of Mac OS X had a user interface feature, known by all who saw it as the Purple Button. Look at this screenshot from System Preferences:

The boiled sweet on the top-right of the window would go purple, hence the name. Clicking on it activated a single-window mode. All documents except the one that you were working on would be minimised into the Dock, and switching between them would minimise the earlier one before restoring the newly-focused document. Of course, the problem with this in the developer previews/public beta which rendered it unusable were performance-related. The "lickable" eye-candy in Aqua was ambitious even on the top-end G4 systems available at the time, and so time spent in the Genie or Scale effects was really noticable. Add to that the effect of applications being slow enough not to update their views in time - the System Preferences application you can see above is a Cocoa-Java app, and back then the JVM wasn't amazing for performance - and you have a really sucky single-window experience.

On the other hand, it's really bloody useful. Look at apps like WriteRoom or GLTerminal, which go out of their way to get rid of all that other clutter. Or Spaces (or CDE virtual desktops, WindowMaker virtual desktops... you get the idea), also designed to let you forget all those other apps are there. Well, spaces is quite nice (and a little more flexible than purple button was), but playing spaces ping-pong tends to make me a bit seasick. Not to mention the time it wastes being about as great as the unperformant purple button switching...so please, purple button, come back!

Some environments provided the same user experience out of a lack of choice - for instance, OZ couldn't show more than one application if it wanted to, and certainly running more than one at once was out of the question (it would simulate multi-tasking by suspending background tasks).

How exciting

Today I was pleasantly surprised by Interface Builder. Not shiny, new, where the hell have they put that buttonstreamlined IB3, but boring old IB2 which even Slowlaris users could work out how to use. I dragged a header defining a category with an IBAction onto IB, and lo, nay even behold, it did the right thing.

That may seem unexciting and even expected, but it's one of those nice cases where it's pleasing that everything just works. I thought category headers might be edge-case enough to confuse the thing; many people would put their IBAction definitions in the "regular" @interface header so that the IBOutlets are in the same place.

Broke track mounting

For some reason, CDs occasionally don't automount for me on my iMac. Luckily that's easy to work around:
kalevala:~ leeg$ diskutil list
[...]
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: CD_partition_scheme Audio CD *620.3 Mi disk3
[...]
kalevala:~ leeg$ diskutil mountDisk disk3
Volume(s) mounted successfully
Job is, as they say, a good 'un.

Nice things about ObjC

Title linkies to a post by an F-Script guy (the F-Script guy? I'm not sure, I don't really follow F-Script development) about nice things he likes about the Objective-C language. Remembering that he wrote a Smalltalk scripting environment for Cocoa, some of the list is fairly unsurprising, much is made of the dynamic runtime, multiple-level dispatch and so on. I think the article is mainly bang on, though I do disagree with the author in a few places. The next paragraph is not one of those places.

Classes are objects. ++ This is the coolest thing ever about proper object-oriented languages, and one of my strongest arguments for design patterns are not language independent. Do patterns such as Prototype need to exist in ObjC code, when the Factory Method +new will give you an unconfigured typical instance?

Dynamic typing... Optional static typing. This is one of those slippery slopes where both edges are sharp enough to give you the rope required to shoot yourself in the foot. Duck typing (i.e. if an object looks like a duck, and quacks like a duck...) is useful in some cases and damned annoying in others. To avoid runtime exceptions with duck typing you either have to [i]mentally assert correctness in your code, [ii]perform all the runtime introspection needed to ensure your messages will be handled, or [iii]eschew the duck type completely and downcast to either an instance of a class or a conformant of a protocol (or both; you could do something like GLModelObject <NSCoding> * if you really felt like it). Another issue with the ObjC implementation of duck typing is that it doesn't always work as you'd think. When it does work, it's very powerful - when it doesn't, you probably won't find out until runtime, and could be spending a long while working out what happened.

Categories. No, afraid not. Nice idea, badly implemented. The point of categories is to let you decorate a class with additional functionality by adding methods - currently not ivars - in additional code objects, not all of which need be present at launch. This lets you work around the visibility contract of the class (can't see an @private ivar? Just chuck an instance method in!), though in fairness so does KVC. But perhaps the worst crime a category can commit is killing someone else's category. Or overwriting an "undecorated" method.

I still love Objective-C, mainly because I love Cocoa and GNUstep and making code that works like them, it's definitely powerful and fun too. But it's not without its rough edges and sharp spiky bits.

My discs have been Americanised!

For some reason, even though l10n and i18n have been fashionable terms in computing for the last few years, no-one seems able to localise properly into the lingua franca of computing, English. It may surprise some readers to learn that there's more than one dialect of english, and some of these even have their own ISO codes (such as en_GB, en_US and so on...I'm ignoring the "ang" language for now). Some words in these different dialects are not spelled in the same way. I live in the United Kingdom of Great Britain and Northern Ireland (Land of hope and glory, mother of the free...) and therefore those round things are known as discs. Indeed, when I insert my Mac OS X installer disc, it is called "Mac OS X Install Disc 1". Then I launch the Firmware Password application, which tells me: "The firmware password is used to prevent others from starting your computer with a different disk." Gah!

"Patently" obvious

Due to a lack of digit extraction I'm not at FOSDEM this weekend. That's unfortunate because as well as catching up with my friends at Brainstorm and on GNUstep, I really enjoyed the weekend last year and drank plenty of great Belgian beer and ate plenty of nice moules-frites.

So I've been spiritually living the Free lifestyle by reading what RMS and Torvalds have to say. Mostly I've been going over the essays in Free Software, Free Society. I find it very easy to accept the premises RMS uses, easy to follow, comprehend and agree with the arguments he presents but then somehow (perhaps for illogical reasons on my part, his part or both) hard to agree that the conclusions he draws are inevitable.

For instance, I agree that copyright law exists directly to benefit the public, and indirectly to benefit the authors (by providing incentives for authors in the shape of limited term monopoly over their authored content) and not at all to benefit Industry Associations. It even says that here, in the first ever copyright law: ...for the Encouragement of Learned Men to Compose and Write useful Books; May it please Your Majesty, that it may be Enacted... certainly doesn't seem to mention greedy lawyers or management.

Letters patent were never created for the same reason, of course. But because it became clear that patents from the Crown were obtained uppon Misinformacions and untrue pretences of publique good, many such Graunts have bene undulie obteyned and unlawfullie putt in execucion, to the greate Greevance and Inconvenience of your Majesties Subjects, contrary to the Lawes of this your Realme, and contrary to your Majesties royall and blessed Intencion soe published, so the whole system was rebooted so that patents were only grantable ... to the true and first Inventor and Inventors of such Manufactures, [...] soe as alsoe they be not contrary to the Lawe nor mischievous to the State, by raisinge prices of Commodities at home, or hurt of Trade, or generallie inconvenient....

The situation we find ourselves in now is that industries claim copyrights and inventions from the authors and inventors and lobby for more and more restrictive variants of the above laws, ignoring the previously-granted rights of the public at large and extending the previously-ungranted rights of the rights-owners, simultaneously removing those rights from the people granted the rights in the first place. So why in the case of copyright do the FSF assume copyright, but in the case of patents they refuse to deal with them? That inconsistency I don't understand.

Don't go there

From the title linky: " Mobility is only available for Windows and Linux." Good job no-one bases their mobile appliances on Mac OS X ;-)

Mach-OFS: aforementioned polish and functionality

It's getting there, now has the ability to display load commands (though it only reports useful information for LC_SEGMENT and LC_SEGMENT_64 commands):

Again the screenshot depicts the OmniDazzle binary for no reason other than it's a nontrivial file. The directions in which to take the filesystem are now numerous: I can add info about the remaining load commands (v. useful), the raw data for each segment (somewhat useful), and the sections in each segment (v. useful). Whether the filesystem will eventually get to the level of symbol resolution, I'm not sure :-).

Well, you could have told me

When looking through some of the configuration options on my laptop (well, it's either that or go to the pub and socialise with humans) I came across something I couldn't account — pardon the pun — for. A new user account on the system, short name messagebus, full name "Message\ Bus" user id 506. Now messagebus looks like the name of a system daemon user, but that full name looks like some clueless skiddie made a mistake creating the user account, especially as the uid is that of a regular user. That's the kind of mistake no self-respecting installer would make.

So, what had this phantom user done? Well, thankfully, nothing. Neither the shell nor home directory was real, and wtmp/utmp showed no activity. Neither did the ssh logs - but in looking for them I realised that I don't actually use ssh on the box, so turned it off.

Anyway, it turned out to be an innocuous issue - the MacPorts installer for dbus creates this bogus user, which I've since deleted. This Apple forums discussion explains more.

Mach-O FS (no really, MacFUSE does rule)

It needs some polishing and more functionality before I'd call it useful, then I have to find out whether I'm allowed to do anything with the source code ;-). But this is at least quite a cool hack; exploring a Mach-O file (thin or fat - in this case, I used the OmniDazzle executable which is a fat file) as if it's a file system. FUSE of course makes it easy, so thanks to Amit Singh for the port!

MacFUSE rules

One reason that microkernels win over everything else (piss off, Linus) is that stability is better, because less stuff is running in the dangerous and all-powerful kernel environment. MacFUSE, like FUSE implementations on other UNIX-like operating systems, takes the microkernel approach to filesystems, hooking requests for information out of the kernel and passing them to user-space processes to handle. Here's the worst that can happen when screwing up a FUSE filesystem:

Now that might sound not only like a recipe for lower-quality code, but also like I'm extolling the capability to create lower-quality code. Well no it isn't, and yes I am. The advantage is that now the develop-debug-fix cycle for filesystems is just as short as it is for other userland applications (and HURD translators and the like). This provides a lower barrier to entry (meaning that it's more likely that interesting and innovative filesystems can be created), but also a faster turnaround on bugfixes (no panic, restart, try to salvage panic log... no two-machine debugging with kdb...) so ultimately higher-quality filesystems.

Non-subscription updates means charged?

The justification for the iPod Touch upgrade fee (to enable the new apps, which are actually deployed-but-disabled by a free firmware upgrade) is the same as the justification given for the MacBook wireless upgrade fee last year - that adding new features to a product that isn't sold as a subscription service needs to be charged for. That in itself is odd - it means that the regulators in the States get to set a price (if not the price) for hitherto free products offered by companies. But it raises a more interesting question - what constitutes a new feature? If a bugfix renders a previously-unusable feature usable, is that charged for? If a security fix makes it possible to use a system in a different environment, should that be charged for?

From the no-man's-land of the format wars

About nine and a half years ago, a sixteen-year-old gadget boy in Weymouth made a simple mistake. Given the already near-complete shift of the music industry from the cassette tape to the Philips compact disc, and the superior portability and resilience of the Sony MiniDisc format, this boy decided that it was obvious the world was going to adopt this format. So our protagonist went out and bought a MZ-R35 walkman. Three years later, and although the writing was by now on the wall for the storage format, he added an MD-M3 to his collection.

I now believe I own all five pre-recorded MiniDisc albums ever made (though I don't remember when I bought Hours by Bowie, and can only think that I bought Recurring Dream because at the time I fancied a girl who liked Crowded House), and have swathes of my vinyl and tape collection "backed up" to recordable MDs. But the rest of the world forgot to catch up with me! Where are the Hi-MD drives built in to laptops? Even Sony don't offer that... Come to that, why do we still put up with crappy scratchable CDs? iPods may be a damn sight more convenient than my MD walkman is, but the bandwidth of an amazon package containing MiniDiscs is still far higher than the connection between my laptop and iTunes.

I still intend to find the required cable and port the rest of my LPs to the format though, as MDs are definitely more portable and resilient than is vinyl. And I haven't actually listened to Bauhaus' 1979-1983 in years.

We! Haven't! Thought! This! Through!

So almost the entire world has exploded with news that Microsoft haven't bought Yahoo!, but are at least waving ridiculous amounts of TEH CAHS under the noses of the shareholders. But what would be the outcome of such a takeover? Microsoft and Yahoo! are in pretty much the same position, they both have technologically acceptable "online presence" services which are marketed really badly such that a competitor virtually owns the market. The only example of a service between them I can think of which is vaguely market-leading is Flickr, although Yahoo! Groups (which was eGroups) might still be popular, I expect that Facebook and Google groups are at least comparable, if not larger than it. Hotmail and Yahoo! Mail are both familiar names, but then online mail is now a free and worthless commodity, and everyone has been playing catchup with Gmail for the last couple of years. People don't "Windows Live Search" a thing, they "Google" it. People don't "Yahoo! Video" their dogs on skateboards, they "Youtube" them.

So the post-acquisition world would go from two implementations to one, but one that's still being marketed into the ground and with a few fewer workers. And all the transitional pain that Microsoft will impose on Yahoo! services, when someone remembers that FreeBSD isn't a Microsoft solution. M$ seem to be of the opinion that with a market they don't lead and $45Bn, the best approach is to lose the $45Bn and hire some other people who don't lead the market. Not, like, take that $45Bn and make their stuff better.

Permissions whee!

As in any good mystery, the question is who done it? MacNN reports a flaw in Tiger, Leopard in which an authenticated copy operation gives the destination files (the copies) the ownership of the logged-in user, not of the name they used to authenticate. The question is, which user did the copy?

Let's say there's a system with Alice Administrator and Richard Regular-User. Richard downloads a new application from the intarwebs, and wants to put it in /Applications (though why? Why can't he just put it in ~/Applications like a good little user? Never mind). The thing is, he doesn't have the right to do that. Finder presents him with an authentication dialogue, and no matter how many times he enters his username and password correctly, he can't acquire that right. However, he sees Alice walking past in the corridor and asks her to enter her admin credentials. For whatever reason, she agrees - now Alice has authenticated and Alice has acquired the right to copy the files. So even though Richard requested the copy, it was actually Alice who performed it. Therefore Alice created the files at the destination, so they should be owned by Alice.

The only thing which muddies the waters (and leads to the conflict of convenience vs. security which is described in that article) is that in many, or indeed most, cases on OS X where this will arise, Alice and Richard are actually the same person - Sammy the Single (Security-conscious, hence separating their use of the system into regular and admin accounts) User. It's a convenience that as Richard wanted the files copied, Richard now owns the copy - but this defeats the point of Richard existing, which is that Sammy doesn't want to be able to change /Applications without being warned.

Interestingly the same question doesn't get asked of the sudo command - it's clear that if I type sudo ditto Foobar.app /Applications/Foobar.app it's the super-user who does the work.

Side-by-side

A frequently-heard rider on the statement that Mac OS X "is more secure than Windows" is that fewer people are prodding its weak spots, because it has fewer users. Well, Windows Vista has a market share comparative to Mac OS X (all versions), and this report describes the security statistics as being somewhat comparable, too. So there we go.

How to solve every problem in Cocoa

Yes, really, every problem. Don't think of Cocoa as "simple things simple, complex things possible" (actually, was it Cocoapenextstepsody or Perl who started with that tagline? Or someone else? I digress) but "simple things simple, complex things simple but you're looking at it wrong". With Objective-C 2.0 (particularly properties), Core Data, Cocoa Bindings and Cocoa Scripting, almost every "it doesn't work" moment comes down to getting something wrong with KVC or with KVO - either observing the wrong key, or typoing a method name such that you aren't KVC-compliant for a key you need to be, getting validation wrong or unexpectedly going down the -setNilValueForKey: path. So do yourself a favour:

#define GLInstanceMethodEntryLog(format, ...) NSLog(@"-[%@(%p) %@] entry: %@", NSStringFromClass([self class]), self, NSStringFromSelector(_cmd), [NSString stringWithFormat: format, ##__VA_ARGS__])

Now because all of the retain count bugs disappeared when you turned the garbage collector on, the remaining issues are with that bit of code the PHBs are paying for ;-)

Project: Autonomous Revolutionary Goldfish

I was going to write, am still going to write, about how silly project names get bandied about in the software industry. But in researching this post (sorry blogosphere, I've let you down) I found that the Software-generated Gannt chart was patented by Fujitsu in the US in 1998, which to me just explains everything that is wrong with the way the US patent system is applied to software. For reference, Microsoft Project was written in 1987 (although is not strictly prior art for the patent. Project does everything in its power to prevent the user from creating a Gannt chart, in my experience).

Anyway, why is it that people care more about the fact that they're going to be using Leopard, Longhorn, Cairo, Barcelona or Niagara than about what any one of those is? As discussed in [1], naming software projects (though really I'm talking about projects in the general sense of collections of tasks in order to complete a particular goal) in the same way you might name your pet leads to an unhealthy psychological attachment to the project, causing it to develop its own (perceived) personality and vitality which can cause the project to continue long after it ought to have been killed. For every Cheetah, there's a Star Trek that didn't quite make it. And why should open source projects like Firefox or Ubuntu GNU/Linux need "code names" if their innards are supposed to be on public display?

I've decided that I know best, of course. My opinion is that, despite what people may say about project names being convenient shorthand to assist discussion, naming your project in an obtuse way splits us into the two groups which humanity adores: those of us who know, and those of you who don't. The circumstance I use to justify this is simple: if project names are mnemonics, why aren't the projects named in a mnemonic fashion? In what way does Rhapsody describe "port of OPENSTEP/Mach to PowerPC with the Platinum look and feel"? Such cultish behaviour of course leads directly to the point made in the citation; because we don't want to be the people in the know of something not worth knowing, we tend to keep our dubiously-named workflow in existence for far longer than could be dispassionately justified.

Of course, if I told you the name of the project I'm working on, you wouldn't have any idea what I'm working on ;-).

[1]Pulling the Plug: Software Project Management and the Problem of Project Escalation, Mark Keil. MIS Quarterly, Vol. 19, No. 4 (Dec., 1995), pp. 421-447