Labels: HUD, new order

Forget Bjarne. Forget Cox. Forget Meyer. Possibly the most eloquent writer in the software world pitches CLOS (common LISP object system) and writes in detail about various related subjects. His website.

This is the followup quote from the world of evolutionary biology I was researching for my prior post about all the "newfangled stuff in OSX not being a compelling reason for the business world to change to OSX.":

Only things that are relatively worthless change rapidly and dramatically.

Itanium tells the story of selling drastic technological change best of all.

Woz 6502 Floating Point routines.

If you've been covering my Apple vs. Microsoft articles, here's the reprieve. My personal belief is that Microsoft is making a huge mistake by trying to make a big technological break from XP. Firstly, the history of unix tells us that if the primitives are right, an OS foundation is as good for as long as you want it to be. Secondly, geeks and nerds always overestimate how important geeky new technology is to the average person, and business. There are a whole generation of new computer users who would be completely happy with a turnkey computer that had a state of the art web browser (for access to all their communication apps), instant messaging and Photoshop. They could give a damn about whether it's the Dock or the Windows taskbar. But I'm sure they would appreciate it if it fits in their pockets. Because of this, I believe the Winning strategy for Microsoft/Windows is a 20 year plan of incremental improvements in stability and performance. A hybrid 32/64 bit OS will be fine. Windows 3.1 proved that. So did DOS extenders. Computer users care little, or nothing about how many bits are used to achieve functionality. It's amazing how nerds can look on while "next-gen" Itanium tanks and not see the writing on the wall.

Computer operating systems are not gizmos like iPods or cellphones. It's a huge mistake to take this approach to building and marketing them. Operating systems are more like the power grid, railroad or freeway systems. Once you get the basic design right, you could spend a century just making extremely small improvements that accrue, over time, toward increased profitability and customer satisfaction. For instance, as far as Leopard goes, I could do without the gratituous OpenGL "time travel" backup and have a laundry list of items from Jaguar, Panther and Tiger that I would rather have, exactly the same, but work twice as good (like amazon.com). Take spotlight for instance. The longer you own your machine, the worse Spotlight becomes. Eventually it gets to the point where it would be faster to upload your harddrive to the internet, let google index it, and then use Google to find things on your local drive. This one aspect of OSX, without ANY new features, could be systematically improved for 30 years. If the nerds at Apple and Microsoft were allowed to design automobiles, every year we would have a new "steering wheel replacement". Advanced technology! Makes the old steering wheel obsolete! Steer faster than ever before! Steer by thinking about it! Steer by talking to your car! Steer by the smell of your armpits! Ad infinitum.

Personally, I will know that one of Apple and Microsoft have actually deployed an "advanced" operating system when the "crash log reporter" programs can be left at home in the labs. It's unfortunate that the adverts from Apple are promoting the "crash-free" nature of OSX, because clearly, as ~/Library/Logs/CrashReporter will tell you, Apple is not really any better in this department than Microsoft.

Anyway, this NYtimes headline quote simply cracks me up. It might as well read: "Is unix near the end of it's run? It's been almost 40 years now, it's time to retire C and unix (taking down the entire world's computing infrastructure in the process), and we think it's a little tired."

Is Windows near the End of it's Run?

Q. What was the lesson learned in Windows Vista? After all, it wasn’t supposed to ship more than five years after Windows XP.

A. No. No, it wasn’t. We tried to re-engineer every piece of Windows in one big bang. That was the original post-Windows XP design philosophy. And it wasn’t misshapen. It wasn’t executed, but it wasn’t misshapen. We said, let’s try to give them a new file system and a new presentation system and a new user interface all at the same time. It’s not like we had them and were just trying to integrate them. We were trying to develop and integrate at the same time. And that was beyond the state of the art.

Following right behind my previous post about why Microsoft's platform evangelism is rocking the world, here's a fairly exclusive 8 or 10 month old story about Apple's reign of terror on their own ISVs.

Before I get into the facts, the first thing we need to be reminded of is some marketing fundamentals. Before anybody except Apple legal starts writing their counterpoint, we first need to establish that there is absolutely no such thing as "trademark dilution". In fact, it's been demonstrated that the activities which lead to so-called brand dilution, are actually the most desirable consequences one can ever have for a brand.

Nevertheless, even though Apple claims to be a "marketing company", it is clear that they still don't know the first thing about brand marketing.

Let's rewind the clock a bit.

I like iPods. I have a collection of them. I, like many, made a pilgrimmage to an Apple Retail store during the week of the video iPod's introduction to pick one up. I did the same with the original Nano. My favorite is the chewing gum pack shuffle, but I digress.

The first thing we notice about the video iPod is the lack of means to get non-iTunes-Music-Store content on the device. Not to worry, seemingly hundreds of Cocoa developers jump immediately on the task of converting video for the iPod. Myself, I'm always looking for that flawless, free Mac application that works exactly the way I want it to. It's an endless quest, a quixotic journey, but hey, it's a life. Because the video iPod is my new favorite gadget, I'm spending way too much time on the Apple downloads site looking for new Mactoys for the newest member of my iPod family. The Apple downloads site has a list of the top downloads in each category, including iPod. Sure enough, during the few months after the video iPod release, the top-10 list is filled with video iPod tools, including some of my favorites.

One day, I notice that one popular item, Podner, has suddenly disappeared from the Top-10 list. A further inspection of the Apple download site indicates that Podner no longer has a listing. I'm thinking something weird is up, so I go over to versiontracker.com and check out the scene there. Nope, Podner is alive and well at versiontracker. Next is MacUpdate - over at MacUpdate, Podner is flying high.

Putting 2+2 together, I start looking around Apple downloads for other iPod products that use the wordstem "Pod" in their name. Curiously (at the time), products containing the word Pod have been removed, but products containing the word "Podcast" remain.

A short time passes on the Internet. Suddenly, Podner is reborn as ViddyUp! I start asking around and learn that Apple is waging a silent war against it's own ISVs who are using the word Pod in their product names, systematically removing software listings from apple.com which include the forbidden word (We are the knights who say POD!). The Apple faithful, however, are like an abused wife. They live clinging to the dream that one day, Apple will requit their love and devotion in kind. Naturally, once Splasm has bent over and received the long hard

1

from Cupertino's Infinite Loop, ViddyUp! is once again restored to the Apple downloads site. Needless to say, from that point on I preferred to search on the independent software tracking sites.

The absolutely best part of this story is the word POD itself. Apple does not even have a trademark on the word POD as it APPLIES to portable MUSIC devices. If you follow that link to line6.com, you will find the ® symbol adorning their product name, POD®. The ® symbol indicates that the trademark has gone all the way through the US trademark chain and been granted by those whose job it is to officially bless trademark names. Between the POD and the iPod, which one is doing a better job of helping ordinary people be creative? The iPod, which turns people into rote consumers of mass media, or the POD®, which helps people achieve their dreams of writing the next "Smoke on the Water" or "Purple Haze".

In the early 90s, Microsoft, after untold millions in soft campaign money, bribes, and lobbying, was successful in it's bid to trademark the word "Windows". Microsoft, as well, decided to pull heavy on some of it's ISVs, but they did so with class and honor. I was close with some Windows tool vendors who had a Windows-based development platform that used the name "Windows" as part of the product name. When asking them about why they later changed the product name, removing the word Windows from the name, they told me that Microsoft had requested it. This was a small company, less than $1M a year in gross sales, and what Microsoft did was send one of their main VPs to have a private conversation about the change. The trademark had been granted, Microsoft was putting it into use. The request came from Microsoft with class, honor, even "a please", no particular rush. Unlike Apple, Microsoft actually appreciates the ISVs who get behind the company's strategic direction.

Apparently, since nobody protested or said anything about it, they've expanded the scope of their terror campaign to other kinds of Apple enthusiasts.

I think about Apple, the iPod, and the POD® anytime I need to blow my nose and ask people in the vicinity for Kleenex.

While I'm on the subject of Apple's doomed proprietary mix of C and smalltalk:

"In Objective-C 2.0, did Apple bother to elicit feedback from the language community? Or is it all Apple?"

Way back, in 1998, this guy, David Stes, wrote a very compelling paper about updating Objective-C to include smalltalk blocks. This would be a far more useful language feature than most of the garbage that they keep heaping into gnuobj-c.

GCC already has peculiar local function definitions (functions defined within functions). I'm sure since the compiler backend is already there, writing the parse tree should be a "no-brainer" for the rocket scientists who gave the Apple developer community a new Objective-C compiler when what they really need is a commercial-grade C++ compiler. Even Intel, a company which designs and fabricates silicon, is smart enough to own a state of the art commercial C++ compiler. Which begs the question: if GCC is so great and standards compliant, why would Intel bother releasing ICC for Macintosh? Or IBM, for that matter? Borland might make a good acquisition. Their C++ compiler technology is strong even if Microsoft showed them the door in WIN32. There's probably a reason that hardcore gamers (performance heads), continue to keep the Open Watcom dream alive. It's not like BSD doesn't have GCC available.

Speaking of Cocoa and Objective-C, I've updated cocoa.0x00000000.net with a sample that illustrates encapsulating new instance variables (private data) with informal protocols and categories. Source is included.

Of all the arguments that could be posed against Cocoa as a compelling framework, NSString illustrates almost all of them. One of the key axioms of object-oriented programming as it was expressed by Alan Kay's Smalltalk could be summarized as "many, many small classes, each with it's own purpose, highly organized into a taxonomy". Between the seemingly inscrutable collection of objects and the class browser, it's a wonder anyone came to grok it at all.

As far as I am concerned, there is only one framework designer who has elevated object-oriented design to the level of art. And his name is Greg Dow. Greg also has roots in class-framework design stretching back into the 80s. Flip open the front cover of the circa 1989 Think-C reference manual (yet another C/OOP hybrid - that's 3, count 'em: Objective-C, C++ and ThinkC), and you'll find Greg Dow's name on the cover. Both Symantec's language business and proprietary mix of OOP/C is long gone, but Greg went on to design the original PowerPlant framework for Metrowerks and later, PowerPlantX (which I have not yet used). But I'm referring here to his work on PowerPlant, which is splendid.

Designing an effective OOP framework is no easy task. It's hard to do, and it's even harder to do well. And I think I could make the case that it is nearly impossible to do by committee. Usually, the best frameworks come from the minds of one, or perhaps two people, who share a design philosophy and are passionate about getting extremely small details right.

If I were Greg Dow I'd be pondering the lyrics to "what a long strange journey it's been". And for solace, I'd go to kinkos and have the following excerpt from the NSString class made into a poster for my wall:

- stringByDeletingLastPathComponent
– stringByDeletingPathExtension
– stringByAppendingPathComponent:
– pathExtension
– stringByDeletingLastPathComponent
- stringByExpandingTildeInPath
– stringByAbbreviatingWithTildeInPath

NSString is so full of garbage it is hard to believe. It's almost as if, during the hard years, NSString maintainance was done by the marketing interns, rather than the computer science interns.

I think they missed one. What about:
+(id) stringContainingContentsOfHTTPURLViaPostThroughAnonymizerDotCom:(NSString*)withURL;

It doesn't take a genius to figure out why CoreFoundation is spare where Cocoa is verbose. Everybody learns from experience.

It's unfortunate, but NSString is going to look like this forever. Perhaps, like myspace.com URLs, which are another collision-happy namespace, NSFileSystemPath was cybersquatted by another Objective-C framework designer.

If I had a say in Apple's strategic direction, considering the fact that C++ is well on it's way to becoming the defacto winner in the OOP language wars - (I'm talking about actual standards efforts here, not "standards" that one company invents and says "look it's a standard") - I'd hire Greg Dow and give him a wing of 1 Infinite loop, with an indoor tennis court, personal maid, and whatever else he wanted and tell him: make us a state of the art C++ application framework that will make C++ programmers everywhere WET and HARD. Put Apple at the top of the C++ charts. Make C++ programmers lust after Macintosh. Keep it more secret than MacIntel and iPod. Even if it's 3 years away it will still be early in C++ years. C++ and C89 are going to be around forever. They get more work done and they're the only technologies up to the most difficult software engineering tasks - like supporting cross-platform development. I'm sure many people will disagree with me, but that's OK because blogger only takes 1 minute to join. Make your own blog and disagree.

Look, Trolltech is succeeding at selling $3000 C++ application framework seats. I seem to recall NeXT being largely unable to do this. There must be a reason. Think about it. Garbage collection indeed.

In keeping with our theme of debating the "moderne" nature of Cocoa, today we pit the venerable, 30yr old Unix ASCII pathname, updated in the mid-90s with UTF-8 for the non-english speaking world, against the 10 year old, Carbon, FSRef opaque data type. Wirth would call it an Abstract Data Type. Unix paths are used in OSX and Cocoa (primarily) to represent just about everything. Until the advent of the URL (another ASCII bitch-slap), unix paths were all powerful. Unix was designed to allow everything to be addressed through the hierarchical database which was/is the file system. Everything was a file, even things like SCSI devices. And because everything is a file, the unix pathname could be used to address any resource in the OS.

Despite the fact that Mr. Jobs took some of his best engineers with him to start NeXT, clearly there were and are plenty of good minds at Apple, both during the split and after. Today's Finder is hardly related to the NeXT workspace manager, and it ain't no descendent of the Mac OS 9 Finder either. Despite the fact that the OS9 Finder was running on something of a weak (by everyone's reckoning at this point) OS foundation, it was chock-full of the best UI design principles. I'm not talking about eye-candy here, but things that really matter.

Cocoa developers who have never written an application against the MacOS toolbox will be forever impoverished by their lack of experience. FSRefs are relatives to the unix path. They are used by Carbon programmers to address objects in the file system. Hence File System Reference. They can address any existing object in the file system. If an object does not yet exist, it can be addressed using a FSRef parent (ie. containing folder/directory) in combination with a UTF-16 pathname which represents the latent part of the name.

Yawn says the Cocoa/unix programmer. Yawn on little doggie, says I.

Today I have a bunch of digital photos sitting on my desktop. A variety of sources. Internet, digital camera, my favorite porn site, afew underage golden retrievers I'm stalking on dogster.com - the usual stuff. I decide I want to add them to iPhoto. So, I drag select the bunch of them and drag them to the iPhoto icon in the dock. Cocoa iPhoto isn't open, and so the icon starts bouncing as /usr/bin/ld attempts to map seven thousand megabytes of unused frameworks into the iPhoto address space. Since it's a new CoreDuo machine, it takes at most, 5 minutes for this sleek application to load thumbnails for my entire photo collection into RAM, forcing this beefy unix box to swap/thrash like crazy.

Meanwhile...

As the iPhoto application continues to load, I decide my desktop is messy. Foremost amongst the mess is the bewildering assortment of JPEG visual candy. Since the iPhoto dock icon is still pogo-sticking up and down (it's like the girls on myspace with 100,000 friends - she's the star here), I've got plenty of time to freshen up my desktop. I drag select all my desktop photos/clutter and drop them into a brand new folder called 'Desktop Clutter'.

No sooner have I accomplished this when, lo and behold, iPhoto is now open and running on my machine. I click on the iPhoto icon to see how my Desktop photo import is going, and take in some more beachball/spinning progress activity before receiving this message. "Unreadable Files: 2 - The following files could not be imported (they may be an unrecognized file type or the files may not contain valid data". There's your highly advanced 1989 Cocoa for you.

In MacOS 9, with the "archaic" Finder and a run-o-the-mill Carbon application, there would be absolutely no problem with my desktop cleaning activity. In fact, if iPhoto was an OS9 Carbon application (god forbid) I could have pre-emptively thrown my JPEGs into the trash, anticipating their safe voyage into the iPhoto library. Trash, wherever. The filesystem knows where there are, and the FSRefs continue to point to them. Because my Carbon 'apple event' serves me a list of dragged files as an opaque array of FSRef objects. Unlike a path, I have no idea what the contents of these data structures are. Computer science and software engineering 101. I'm on a need to know basis, and frankly, I don't need to know.

In fact, while the file is open, I can move it around, rename it etc. and my software never needs to know. If I truly want to know where in the file system hierarchy a file system object is, I simply query for its UTF-8 path using an opaque API. Or I can traverse the chain of nested FSRefs back up to the root of the file system. At some point in the future, after Earth has joined the galactic federation and we here on Terra have upgraded to UTF-1024 (there's a lot of languages and unique glyphs in the milky way), my Carbon application will continue to work with them because the opaque C89 API keeps me from making assumptions about the nature of the file system objects, how they are represented. The FSRef opaque data type, mysteriously, contains just 80 bytes of data. Yet it can unambiguously keep track of any object in the file system, even something with 1024 byte Unicode pathname.

Some of the functionality I describe is available to all Mac OS X applications. For instance, Preview.app is able to determine where a PDF is located, even if you move it about while it's open.

I'm not exactly sure when FSRef's entered the lexicon of Carbon programming. I do know they were introduced to accomodate Unicode path names, probably during the System 9 era. The most compelling aspect of FSRef's are that they allow you, the developer, to write software that works the way a "user" expects it to work. User's don't care about pathnames. They don't care about FSRefs. They've been shown a promise of a direct-manipulation desktop and they get really confused when it doesn't work that way.

I understand URLs. I understand Win32 UNC pathnames. I understand DOSFILE.NMS. But in all my experience writing software, the only OS API to provide the right kind of function calls (procedural or otherwise) for working with files on disk is the Carbon FSRef API set. FSSpec's didn't do it for me. Unix path's are fine, in a char[1024] way. FSRef's I found weird and disconcerting at first, but over time, I came to appreciate them greatly.

I can't possibly expect a Cocoa developer to bend their minds toward the idea that Carbon, the so-called 'out-of-date' API is, in reality, quite possibly as much as 10 years more advanced than anything else around. One can only realize the truth: There is no spoon.