Sure it was more elegant, it took its inspiration from SmallTalk after all ;)
Of course that lead to a bit of a mixed result. For one, most of the new features were syntactically isolated to the Obj-C square brackets. On the other hand, within those brackets things were considerably un-C-like. object.method(arg) seems more "native" than [object method:arg].
I actually liked this grafted-on appearance. It was a clear signal that said: Yeah, we're still C, let's not make any illusions about this.
By comparison C++ had more delusions of grandeur, almost from the start.
This is also why I'm not that fond of almost any changes to Objective-C that were made later, especially by Apple. That includes the various searches for better memory management, but also the property dot syntax.
I'm still a bit sad that the Objective-Javascript thing never took off. Way better than most of the added language features since then.
One of the best things about OS X (as it used to be called) is that the runtime was accessible not just from Objective-C, but also from ruby or python or JavaScript. It was very cool to be able to fire up a repl and go exploring in the innards of the various frameworks.
Yes, the distinction between class and instance methods in an interface with + and - characters must be one of the most elegant solutions introduced in a programming language ever.
Seriously, I could never understand this claim of "elegance" of Objective C…
Really? Whinging about syntax? You don't understand how cleanly dividing the C bits and bobs from the Smalltalk-derived object system by using distinct syntax could be considered a more elegant solution to the problem than C++'s insistence in rooting both worlds in a single hierarchy of functionality?
The Amiga 1000 was the first computer I ever LOVED, but I never could get my head around how to program back in those days. Years later, Objective-C was the first programming language that finally clicked for me and made me feel like I was truly, finally in control of my computer (Macintosh running OS X 10.2).
Now that Swift has supplanted ObjC on Mac and iOS, it feels somehow comforting to know that my ObjC love can live on in the arms of my Amiga love.
Yes, it's true that ObjC is pretty firmly entrenched after so many years driving the platforms. But it also doesn't feel like I'm doing myself many favors professionally by investing any further time into that language. For personal stuff, I can do whatever of course. I dunno, maybe I'm wrong; can't say I've researched "How in-demand are ObjC skills in the job market?" these days to speak with any authority on the matter.
Joining the Metal team is well beyond my abilities. I didn't explicitly say it, but I'm an application developer, not a graphics guru. So for me, Metal might technically be composed of some Objective-C, but from my perspective it might as well not be, because it's a project I'll never be equipped to contribute toward. But your point is taken; Objective-C isn't dead, and my choice of words didn't contain proper nuance.
Random yes, useful also yes: AmigaOS has a C-based object-oriented interface to its Intuition UI library called BOOPSI, and having ObjC available makes it much nicer to work with BOOPSI objects.
Every so often I actually consider making an ObjC library around BOOPSI and ReAction objects. One day I might actually go ahead and do it.
Apparently, MorphOS already has out of box ObjC developer support for MUI, via ObjFW. But that requires using MorphOS and MUI, which not everyone necessarily wants to do that.
"I added exceptions into the mix. Now I got the same 'Progam aborted' [...] When using m68k-amigaos-g++ rather than m68k-amigaos-gcc, it would suddenly work."
Yep, this was my thought immediately. But probably this flag is not the one needed, as it enables complete C++ exception support - which turns on a couple of other things automatically.
"-funwind-tables" enables stack unwinding
"-fasynchronous-unwind-tables" makes the stack unwinding available for debuggers
"-fno-dwarf2-cfi-asm" makes the debugger unwind table "old style", so unwinding info goes into .eh_frame and .eh_frame_hdr section (or .ARM.extab and .ARM.exidx on ARM) instead of .debug.*
I "brought" Objective-C to the Amiga sometime in ~1986/1987.
I had recently acquired one of the first Amigas in Germany, still a US NTSC model, and also seen Objective-C discussed in a BYTE article. The beautiful OO structure of the Amiga Exec kernel and the higher OS levels built on top of those abstractions (except the abomination that was AmigaDOS) was almost certainly an inspiration.
Having also recently purchased my first C compiler, Manx Aztec C, I initially had some fun with implementing OOP via some Macros and the Amiga shared library mechanism, which was essentially an array of function pointers/C++ vtable.
I don't quite remember when I got the crazy idea of actually implementing an Objective-C runtime and preprocessor, before or after getting the book. I do remember that it felt very much "here goes nothing", and it really was nothing. I was in high school, I had no CS training, didn't know about compilers, hadn't programmed in C for more than a couple of months.
So I wrote a weird lexer that used a bitmap and two counts to cover all the regex cases, a syntactic recognizer that could tell the Objective-C constructs apart most of the time (it had a hard time distinguishing a method send with a cast from indexing into the return of a function call). And a runtime and basic object library. My dictionary implementation turned out to be ordered almost by accident, I have grown very fond of ordered sets and dicts. It also had automatic serialization ("passivation" as it's called in the book), something Apple has only gotten around to just now, and only for Swift.
It worked and I never looked back. I later ported it to i386 and QNX + MS-DOS for a project, replacing the assembly-language messenger function with a pure ANSI-C one returning the function pointer of the method (a technique later rediscovered for the GNU runtime).
When NeXT came out I knew I had to have one. And ditched my implementation in a heartbeat: SEP!
Interestingly, there was another Objective-C implementation from Germany in around the same timeframe called M:OOP, which actually got a little bit of press coverage:
I remember your comment from back then :D. Great news: Since then, I actually did make it a library. The runtime has been a library for a long time now, and ObjFW itself is also almost there in the amiga-library branch.
Your comment is the reason I have a print copy of "Object-Oriented Programming: an Evolutionary Approach" on my desk. Second edition, though, not the one you worked with.
