The screenshot below is from our perhaps most famous application CLIX.
CLIX was originally called CLI because we like acronyms, because we don't like typing too much, and because 'command line interface' was exactly what it was. We added the 'X' as an afterthought because lots of Unix flavours end with 'IX' (PC/IX, Ultrix) and because 'CLIX' sounds like 'clicks' and clicks is what CLIX is all about.
CLIX was initially written for a very early version of Apple's OS X. It would not have been possible on any other platform.
CLIX requires more than a good programming language, but the programming language is where it all starts. And Objective-C is that programming language.
Objective-C is a thin veneer atop straight C, a compilable derivative of Alan Kay's interpretive Smalltalk. Kay coined the expression 'object orientation', and of the many OO languages that cropped up at the time - and of one such language in particular - he said:
'I invented the term object orientation and C++ was certainly not what I had in mind!'
C++ is no more object-oriented than Apple's Swift. (Swift tries to hold to some of the paradigms of Objective-C, but it misses the all-important messaging paradigm for no good reason.)
Alan's Vision
Alan Kay had previously been working with Logo in education for children. What Kay saw on a screen wasn't just a screen. He saw objects. He saw sovereign objects. Objects that interacted with one another. That sent requests or queries to each other.
An overview of typical Objective-C code confirms this. This is event-driven programming. You have instances of objects. The entry points and exit points are perfunctory. There is no traditional control flow. An object's methods are its way of responding to user requests, to requests from other objects.
The veneer of Objective-C is very thin. Unlike C++, Objective-C is totally C. It does not interfere with C or reinterpret anything with respect to C. But it adds two things.
#import instead of #include. You don't have to worry about referencing more than once. Once a header's been referenced, that's it.
Message syntax. Perhaps a bit like assembler (right to left) where MOV BX, AX would move the contents of register AX to register BX. Objective-C messaging syntax is as follows.
[target message];
All messages end with a semicolon, as in C. The message itself can be divided up into several parts.
[target message:withParam:withAnotherParam:];
That's about it. Objective-C source files usually use the extension 'm' (for method) and header files still use the extension 'h'.
Objections to Objective-C?
There have been many objections to Objective-C of late, something that can seem rather perplexing, as the learning curve for a skilled C programmer is a matter of mere hours. Perhaps a clue can be found with the author of Swift, who claims that C itself is 'just too difficult'. The objection to Objective-C seems therefore to be an objection to C - and if that's the case, then the whole industry is in deep trouble. (And it is.)
But back to CLIX. What makes CLIX impossible on other platforms? The difference is in the GUI. And to explain that, we have to go all the way back to Multiplan.
Multiplan
Multiplan is the spreadsheet application Bill Gates promised to Steve Jobs for the coming Macintosh in 1984. (Yes, the Mac was initially going to be more business-oriented.) Bill needed prototypes of Steve's Macintosh (likely without Frog Design's chassis) so his people could write the code. But write code isn't all Bill did.
The Macintosh used a menu bar. NeXT used a dynamic popup menu system that came out of the left side of the screen. For Windows, after seeing the Macintosh and starting what later became Windows, Bill put the menu smack-dab on the application window.
Oops. As if there could be only one application window.
Bill Gates and his minions missed the whole point of Alan Kay's vision, an incredible blooper that haunts Windows to this day. Unfortunately for FOSS adepts, it haunts them too - either because the designers of KDE and Gnome wanted to duplicate Windows as much as they could (bad) or because they didn't know better (more likely and even worse).
Separating code and data is essential. Code is most often reentrant, meaning the same code works no matter what data it's dealing with. Code on a Mac or a NeXT need be loaded only once. Code on Windows has to be loaded for every document instance (very wasteful if even possible). Inter-process communications are necessary, if at all possible, for otherwise trivial user requests such as 'close all and exit' or 'save all'.
Document-Modal
But the plot thickens even more. Windows and its copycats KDE and Gnome of course admit of two types of dialog windows: modal (DialogBox) and not modal (CreateDialog). But as the interface actually admits of a single document window per application, the document-modal dialog - or sheet - can't be used. And the document-modal sheet is essential to CLIX.
The sheet is document-specific and is attached to its document window. (The application itself need not have any windows at all, remember.)
Substitute User
CLIX runs standard user commands. The syntax for CLIX commands is identical to the syntax for UNIX commands at the command line, with one exception: invocations of 'sudo' must be affixed with '-S' to indicate they're not coming from an actual command line.
Otherwise they're identical.
CLIX uses your admin password to authenticate for privilege escalation. You submit this password once - and it remains resident unless your computer goes to sleep. But as anything can happen at any time, it's essential that the message pump not be blocked, and using a standard Windows-type dialog for submitting your password could prove to be a security breach.
By putting the password dialog into a sheet, this situation is avoided.
But There's More
But there's more. There's always more.
The development environment and runtime environment are - or at least were - second to none. Early estimates were that development times were 80% shorter than on other platforms. As but one example, we saw a friend put together a complete address book application in five minutes.
Central to this efficiency is the module known as Interface Builder. Interface Builder was originally called SOS Interface and was to be marketed for the Macintosh. Steve Jobs saw a demonstration of the application and immediately rushed to retail outlets in the area to buy up all available copies on the spot, then hired the developer to work for him at NeXT.
What's so special about Interface Builder? Interface Builder builds interfaces, comparable to Windows with its dialog templates, but it goes much further. The interfaces contain 'freeze-dried code', as one author described them.
Back to the language and the runtime environment. For Objective-C offers dynamic binding, as opposed to other languages. (If you've ever seen what C++ does to an object file, you'll understand - and sympathise.)
What this means is that, for example, user commands (user actions) can mean the same thing in a variety of scenarios. A command to 'copy' can apply to selected text, a selected image, selected rows in a tableview, whatever. You no longer need to define command numbers for the same command for every situation. Shaving off 80% on a project is a no-brainer.
Where Are We Going?
CLIX was part of a minor revolution for Apple users. They’d never seen a command line. But Unix without a command line? Such a thing cannot exist. Apple users had never seen anything as complex as a Unix system either. CLIX made it easier to learn and understand.
Yet most early adopters have long since moved on. Once they got their toes wet with CLIX and Unix, they wanted the real thing and moved to Linux.
Which is where we'd be too if not for two significant caveats. The Linux GUIs are seriously subpar, and the Linux kernel is not a microkernel.
Microkernel is always more stable than monolithic kernel. By definition. Yet Linus won't discuss it, or explain his resistance. But that's a minor issue compared to the other. For the Linux GUIs are not only crippled by poor programming languages, and a poor runtime environment, but also by lacking what's been described here at the outset. Red Hat persisted in supporting KDE and Gnome. IBM, even after shelling out 34 billion to acquire Red Hat, can do no better.
GNUstep, which is a shared library rather than a complete distro, has been around longer than either KDE or Gnome, incorporates these features, but today is mostly stagnant.
To the extent that desktop systems are still in demand, something has to be done. Our early attempt to unite several groups, working under the name 'NeXTbuntu', garnered considerable interest, but not a one of the 80-some who signed on was more than an admin or potential tester. Reaching Shuttleworth would have likely proved futile - he's been convinced Apple's superiority was in the quality of the graphics.
Even Shuttleworth couldn't understand why a menu has to be separate from the document windows.