Clearly, the acquisition of Next, positioned OpenStep and Objective-C as the immediate tool chain for Apple.
Don't get me wrong, I admire Objective-C and have enjoyed programming in it for many years, moreover, Apple has some exceptional people who are trying to drag the language into the 21st Century, kicking and screaming.
But one of the casualties of the merger, and, to be fair, other circumstances, was an alternative programming language which, at the time may have seemed a little odd, but amongst the current crop of scripting and functional languages seems positively normal, Dylan.
Dylan is effectively a LISP, with a combination of C and pascal syntax. It is an object oriented language which uses the same semantics as CLOS.
When Dylan was in its infancy it suffered many of the same problems as Java, at the time, namely, performance and resource usage; Java, however, had marketing muscle and a robust Sun Microsystems behind it. Dylan was merely another project that was not critical to the survival of Apple.
While objective-c continues to serve Apple well, one cannot help but wonder whether, now, when Apple is no longer precariously balanced on the precipice, Dylan might be considered a much more appropriate choice for the future.
Many of the modern features at are being added to objective-c are already present in Dylan and it remains to be seen if objective-c is malleable enough to have those features added in a natural seamless way.
below is a contrived example from the Dylan wiki, that serves to illustrate the sophistication of the Dylan programming language, I ask you only to review and consider how like facilities might be made available in Objective-C, my hypothesis is that you may find some significant holes.
define constant <zero> = singleton(0); //
define method factorial( n :: <zero> ) => ( n! :: <integer> )
define method factorial( n :: limited( <integer>, max: -1) )
error( "factorial: Bad Argument");
define method factorial( n :: <integer> ) => ( n! ::<integer> )
n * factorial( n - 1 )
The purpose of the above is not to hold up functional programming as the most appropriate paradigm, clearly we can be more efficient than this, but it is a concise example of how polymorphism can be used to avoid the conditional code that often plagues the behaviours attributed to objects in objecttive-c