Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Industry Watch » The Technological

Damage Control


Get It

Try It

A wise old programmer who'd done his masters degree on the NeXTSTEP operating system and who was personal friends with Dan Gillmor, Andrew Stone, and Avie Tevanian, once cautioned a group of his fellow engineers about how to approach the new owners of NeXTSTEP about what they'd done.

It's no secret that Apple's HI group have always been partial to 'MacOS' and to the 'Mac' way of doing things. When tasked with the challenge of 'making over' NeXTSTEP not for its 'best of us' but for Apple's 'rest of us', they decimated the functions and features of the classic NeXT platform, to the dismay of engineers everywhere.

And of course these dedicated engineers wanted those functions and features returned. But there's a right way and a wrong way to go about it, cautioned the programmer. A successful way and an unsuccessful way.

The unsuccessful way is to write to Apple and ask them what the F they're doing. Ask them how in the name of all that is good in computing science they can make such a mess and atrocity out of an environment that was nearly perfect for developer and user alike.

Apple and their HI group are allergic to all things NeXT, cautioned the programmer. That's just the way things are. Take them to task in that manner and they'll not only ignore you, they'll grow hostile towards you. Such is the atmosphere inside corporate headquarters at One Infinite Loop.

By even intimating you're a NeXT engineer going way back you'll turn them off, he cautioned further. They regard NeXT as their archenemy. Let them in any way suspect you come from that school and that background and they'll still turn on you.

No, the only way to approach them is to dissemble, said the programmer. Write to them from an anonymous address, and really give the impression you're a typical clueless enduser who on a sunny bright day can't find the trackpad. Mention in obtuse and somewhat confusing terms that you'd like to see them implement a few new features. Sneak in obtuse descriptions of NeXT features in your letter. Make sure they do not see the connection twixt the one and the other.

Only then will you have a chance, said the programmer. They see it as their holy mission to dumb down the fantastic NeXT interface and programming environment so even the likes of John Gruber feel safe. And if we all write letters like this, then maybe some day soon things will change.

Wil Shipley of Omni fame is taking just such an approach. Wil's been in on the NeXT phenomenon from the get-go. The company he cofounded was one of the first to produce software for the platform. Wil knows the score - but evidently he also knows how futile it is to pursue the 'unsuccessful' approach.

In an article with a title with an obvious reference to the filmography of George Lucas, Shipley on 5 October 2006 makes an attempt to urge wide sweeping changes in the way Apple's version of NeXTSTEP works.

http://wilshipley.com/blog/2006/10/pimp-my-code-part-12-frozen-in.html

'Carbon, briefly defined, is a compatibility library that ships with Mac OS X that enables older applications, written for Mac OS 9 and before, to run under Mac OS X with minimal changes (and a recompile)', writes Shipley. 'Carbon is descended from the original Mac Toolbox written in the early 1980s, and still shows signs of its Pascal and machine language origins, even though it is now primarily accessed through and written in the C language.'

Right here the software engineer can see the issue: Carbon has nothing to do with NeXTSTEP (thankfully) and worse, it's procedural. There's no chance to reuse code and build things up in the admirable way NeXT engineers did. Worst of all, it's a legacy that should never have been. NeXTSTEP (or OpenStep) is the operating system of OS X and none other.

'What's distressing to Cocoa programmers is that there are still critically important Apple APIs that are only available through the incredibly byzantine and ill-documented Carbon libraries, and some groups at Apple are still generating Carbon code under the guise of Core', Shipley goes on.

Certainly this is not news for NeXT engineers: Apple took a ridiculous five years to drag solid NeXTSTEP code out of the NeXTSTEP frameworks and put it in 'core' modules so wobbly Carbon programmers could get somewhat like the same functionality for their wobbly Carbon programs. One speaks of 'toll free bridged' classes and the like.

NSString is no longer NSString but instead NSCFString ('NeXTSTEP CoreFoundation string') and the class code previously in NSString has been migrated into NSCFString and a procedural interface. This makes it possible for Carbon code to access similar functionality, but it also makes the operating system twice as slow - and worst of all, from a design standpoint, it's just a bloody mess, what Anandtech called a 'hodgepodge'.

NSArray becomes NSCFArray; NSData becomes NSCFData; and so forth. All told nearly two dozen critical Foundation classes had to be ripped to shreds to create new underlying logic so Carbon, an API that has no justification for existence, can access things it has no right to.

The full list of toll free bridged NeXTSTEP classes can be found here.

And don't forget: anytime you do something dumb like this, your code is going to look messier too, with all its explicit type conversions. [All you fanboys take note.]

Shipley now launches into a list of reasons why it's not good to still have Carbon around - to not have people working on the Carbon API - but he does it correctly according to the advice of the wise programmer mentioned earlier. He lists tangible reasons Carbon is no good. This in theory has a chance of being heard by the HI group. Shipley's not stating the obvious - he's skirting around it.

And after listing half a dozen general reasons Carbon is not practical, he launches into an extensive example in QuickTime. Eighty lines of code will never make it to the HI group or anyone else at One Infinite Loop who can make decisions about this, leaving only the programmers there to try to make it understood to their higher ups. Which of course is unreasonable. But what the heck - give it your best shot, Wil!

All of which seems innocuous enough but for one thing. Daring Fireball has been bashing people left and right for years for merely suggesting Carbon was not a fully equivalent API, Cocoa is native, NeXTSTEP is more modern, and so forth.

John 'Daring Fireball' Gruber is the Bill O'Reilly of the Mac community. He tells stories precisely how Fox News in the US do. When any of these weirdos are proven wrong, do they care? Not on your life! Look how Gruber recovered from the licking he suffered at the hands of Jon Ellch and HD Moore - he just ignored it. As with the Fox audience, the Daring Fireball visitors aren't interested in the truth - they wouldn't be able to understand it even if they got it - they're only interested in being soothed by the words of John Gruber. If Gruber just goes back to the same old lies, who cares? Certainly not Daring Fireball.

But Daring Fireball is now in trouble and it's necessary to control the damage. The name Wil Shipley is well known in the Mac community and word of this new essay of his will spread. And although the essay's intended purpose in this context is irrelevant, its side effect for John Gruber means everything.

Wil Shipley has all the chops in the world to be expounding as he does; John Gruber has no chops at all. As with the Ellch/Maynor story where he made himself an utter fool, Gruber is in trouble for previously speaking about things about which he doesn't have a clue, for fanboy after fanboy might notice that Wil Shipley is in essence saying 'John Gruber is full of it'.

What to do in a situation like this? Watch Fox News and see what they do. When they're trumped, they come out and say they've been saying the same as the trumpers all along - or at the very most modify - clarify - their story a bit so (Fox viewers / Gruber site visitors) are led to believe they've misunderstood (Fox / Gruber) all along.

Piece of cake.

Gruber starts by in essence admitting everything and by coming on 'friendly'. But Gruber can never resist: he has to sneak in a casual subtle bash in the first graf. Always.

http://daringfireball.net/2006/10/some_assembly_required

'Wil Shipley posted an interesting essay, wherein he complains about Mac OS X APIs that are only available using Carbon. At the heart of his argument is the real difference between Carbon and Cocoa - Cocoa APIs make things a lot easier for developers, and require a lot fewer lines of code. I think Shipley loses track of this main point, though.'

Friends, Romans, countrymen: Wil Shipley never loses track of any point. Shipley is a professional and has been so longer than John Gruber's been able to move a mouse. Shipley has a disciplined mind and people like him don't lose track.

But John Gruber does. Or at least he never finds it. There's a new theory that Gruber is trying to get into Guinness for the biggest foot ever in a human mouth. The following graf is convincing evidence of that theory.

'For one thing, he starts by calling Carbon a 'compatibility library' for 'older applications', and Cocoa a 'new application environment', even though both date from the 1980s.'

This is utter nonsense, and if Gruber doesn't know it he should. And if he can't understand it then he should go back to his postman route and make an honest living instead.

Carbon IS a compatibility library - or framework as it's properly called here. It's a bloody mess of a framework made because legacy Apple ISVs put up a stink about having to port their code to a new operating system once Copland had folded ignominiously. That's the price you pay, wee ones. Carbon is the reason Apple have only a 2% market share today: while Apple struggled with this stupid task, Microsoft released a full half dozen additional operating systems on the market. NeXTSTEP had no bloody Carbon API. Get serious. NeXTSTEP didn't need utter crap like that. Only John Gruber's friends did.

Gruber now goes and makes an even bigger ass out of himself.

'Yes, the original Mac OS Toolbox APIs are a bit older than the original NextStep object system, but only by a few years.'

Who the FUCK cares how old they are in years, you imbecile? This is about old and new technologies, you wart, and NeXTSTEP's technology, in case you haven't heard, is the newest on the planet, the one Steve Jobs rolls his eyes about, while Carbon is based in a programming language devised by an anal retentive professor in Switzerland who came out and apologised for it and insisted he'd never expected people to use it professionally.

At this point there's no point in pursuing Gruber's garbage logic anymore. He gets sillier by the byte, and only the idiotic totally clueless fanboys who have nowhere else to go on a sunny afternoon would suck it up. Things like 'in fact, it's fair to argue that Cocoa, today in 2006, is older than Carbon was back in 2000' are so unfuckingbelievably stupid that it's not funny. And again, not only is this wrong but WHO THE FUCK CARES?

So Gruber smooths everything out with a mismanaged quote from Larry Wall who wrote a scripting language Gruber's heard about. In Gruber's new rendition the quote goes like this.

'So I think Shipley's argument could be summarized thusly: Making hard things possible is good, but making hard things easy is even better.'

Gruber has no business summarising Shipley's article and he knows it. If people want to digest what Shipley wrote, THEY CAN READ THE ARTICLE FOR THEMSELVES. They certainly don't need Bill O'Reilly to summarise it for them. After all, that's what the new era of culture sharing is all about: not having demagogues before you.

But Gruber has to summarise Shipley's article, for what he's really saying is 'see - Shipley's saying what I've been saying all along - more or less that is'. If Gruber can convince his intellectually and emotionally challenged fanboys of this untruth, he can stay squeaky clean.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.