
Bringing Objective-C to the Amiga - Midar
https://heap.zone/blog/?76
======
mpweiher
Funky!

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:

[https://ekartco.com/wp-
content/uploads/2012/11/m_oop.pdf](https://ekartco.com/wp-
content/uploads/2012/11/m_oop.pdf)

As far as I could tell, it never got the fully generic objc_msgSend() running,
with only a limited number of arguments supported.

Fun times, but also valuable lessons:

\- Go tackle "crazy ambitious" projects.

\- A language that can be implemented by a kid with a C compiler is a gem.

\- An architectural approach to language is really valuable.

~~~
Midar
That all sounds too familiar. When I was still a little kid going to school, I
was using Linux and found Objective-C. Really liked the language and concepts,
but lacking a framework for Objective-C on Linux. So I started ObjFW a few
years later. Seems you had the same experience before I was even born, except
on Amiga :).

~~~
mpweiher
:-)

Not sure what you mean with "lacking a framework", though, there's at least 3:
gnustep, libFoundation and Cocotron.

------
mhd
It's interesting to see that ObjC has some heritage on the Amiga. That explain
why MorphOS (one of the Amiga ecosystem fragments) is doing something
similar[1] these days.

[1]: [http://morphos-team.net/guide/objective-c](http://morphos-
team.net/guide/objective-c)

------
bwldrbst
This looks fun, considering how much of an influence Next seems to have had on
OS 2 & 3\. And not just the colour schemes either, BOOPSI
([https://en.wikipedia.org/wiki/BOOPSI](https://en.wikipedia.org/wiki/BOOPSI))
looks like an attempt to get some ObjC features into plain old C.

------
adamnemecek
How can I run Amiga os on sometthing less exotic?

~~~
Midar
This is actually a port to the real Amiga, and not one of those new exotic
Amigas. But if you want to run AmigaOS 3, you can just use FS-UAE. In fact,
that screenshot is from FS-UAE, as always copying things over to a real Amiga
can be quite annoying during development :).

------
apple4ever
Very cool!

I ported ObjFW to the Omega2 (still have some things to clean up before
releasing it to the public).

~~~
Midar
Hm, Omega2 seems to run OpenWrt, if I see it right? In that case, it should
even just work.

Alternatively, if you want to avoid OpenWrt, there's also ObjFW on bare-metal
ARM: [https://heap.zone/blog/?68](https://heap.zone/blog/?68)

------
blackrock
Does anyone else look at Objective-C code, and just want to puke?

~~~
_diyu
I actually prefer Objective-C to Swift.

~~~
aplummer
What got me over the line was optionals and protocols + generics, the safety
and expressiveness combined will eventually (hopefully!) win you over!

~~~
LeoNatan25
I prefer to keep the dynamism over unreadable fp "expressiveness" or safety
that was not needed in the first place.

~~~
saagarjha
There's nothing stopping you from writing dynamic Swift code or functional
programming in Objective-C.

~~~
LeoNatan25
Yes, but it’s not officially “condoned”, so it feels “out of place”. This is
very individual, of course, but I don’t like bending the system to get
patterns that are not “natively” supported.

In Swift, you cannot currently create classes in code, enhance and swizzle,
implement proper proxies. You couldn’t even load a nib without the ObjC
runtime. Not even reflection. It’s telling what their priorities were with
that language. What good is the language when you cannot implement most of the
system frameworks (Cocoa, Core Data, etc.) without nasty hacks?

~~~
aplummer
Also I agree you can tell safety was the number one priority. However the
positive is basically never getting runtime errors, except when interfacing
with IB or obj-c even when people are programming in a hurry, which is nice
for me.

~~~
LeoNatan25
"Never getting runtime errors" is as far fetched as it can be. Consider Xcode
suggesting developers use force unwrap ("!"), that leads to many more crashes
with unexperienced developers than the ObjC message to nil paradigm.

Subjectively, I have seen much more crashes in third-party software written in
Swift than in ObjC (usually unwrapping or casting incorrectly), including in
Apple's software. I cannot say if this is down to more inexperienced
developers, less time allotted to experienced developers or a worse
development model. I'd say a combination of the three.

~~~
saagarjha
This might also be because Swift is more likely to crash than fail silently at
runtime.

~~~
aplummer
I don’t see how this is possible, example?

