I don’t think it was every one or the other. Ruby wa/ hot around 2005 and Apple experimented with language bindings for AppKit (and osascript?). I did a bunch of prototyping using MacRuby and then would rewrite in Objective-C.
Ruby’s object model is relatively similar to objc - no direct member access outside the object, everything is loosely coupled messages with dynamic runtime, you could get away with duck typing in some cases in objc using `id` types (at the expense of getting type checks from the compiler).
I don’t think it was ever intended at the next system language, though. It was just a convenient binding and optimized runtime (many of its core types were Core Foundation types - NSString, etc. IIRC).
There was a brief window when it was possible to do some really cool stuff with MacRuby, such as inspecting and even monkey patching core OS X classes. Probably one major reason why Apple killed the project in the first place. Being able to interact with the operating system on a low level through macirb was an absolutely mind blowing experience.
Sadly, those days are long gone, and I just don’t think Swift brings the same kind of flexibility or joy that MacRuby did.
This seems wild. Ruby and Swift couldn't be any further from each other. I struggle to believe that Apple ever seriously believed that Ruby was their ideal language for app development on their platforms.
That’s what MacRuby was. There was a time when you could develop native, compiled Mac applications using Ruby as a first-class language. For a while, MacRuby was looking to be the lightweight alternative to Objective-C. Unfortunately, the project was killed around the same time Apple released and started promoting Swift. I don’t know that there was any definite reason given (not that there ever is) but my understanding at the time was that Apple wanted a language developed in-house rather than adopting something developed somewhere else.
Ruby’s object model is relatively similar to objc - no direct member access outside the object, everything is loosely coupled messages with dynamic runtime, you could get away with duck typing in some cases in objc using `id` types (at the expense of getting type checks from the compiler).
I don’t think it was ever intended at the next system language, though. It was just a convenient binding and optimized runtime (many of its core types were Core Foundation types - NSString, etc. IIRC).