6 ms·

Objective-C Internals

96 points by ingve 3y ago

atorodius 3y ago
I learned to program in Objective C, it was fun. Spent many hours digging behind the scenes, but the only fun fact I remember is that it’s a strict superset of C, so any C program is a valid Objective C program. Always found this fascinating. Are people still using it today? I thought Swift took over.
- TazeTSchnitzel 3y ago
  Can't speak to personal experience, but my understanding is Objective-C++ (which is most of C++ plus all of Objective-C) is still popular for bridging the Objective-C/Swift and C++ worlds. Though apparently Swift is getting a C++ interop system, so that might become less common!
- lapcat 3y ago
  > Are people still using it today? Yes, I am. Apple is too: https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/ https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-... In my estimation, these are the primary reasons why some developers continue to use Objective-C: 1) Rewriting an existing code base is almost always massively expensive and dangerous. 2) 9 years later, the Swift tooling is still atrocious. Compile times are much longer, the compiler still crashes, the debugger still doesn't work reliably. It's a major step down from the mature Objective-C tooling. 3) There are still land mines with interoperability between Swift code and Apple's underlying Objective-C frameworks. Performance bottlenecks, unexpected object bridging issues, erroneous nullability annotations, etc. 4) C and C++ compatibility, as mentioned by another commenter.
  - MichaelZuo 3y ago
    Since Apple now controls the entire hardware stack for all their products (except the mac pro), they could conceivably design their own assembly language ('Apple Assembly'?) optimized for, and only for, Apple silicon and bypass the problem.
    - lapcat 3y ago
      Apple has already done this to some extent, though I don't have the references offhand. In any case, there's only so much that hardware can to do compensate for crappy software. It's not inherently a hardware problem.
      - MichaelZuo 3y ago
        It's possible, if they were motivated to really invest in it, to introduce some innovations. For example, it could warn about badly designed software, major flaws, etc... at the assembler level. And since they mostly control software distribution, to then block anything that receives such warnings.
        saagarjha 3y ago
        There’s no need to do something like that. They just don’t optimize for certain code patterns.
    - AceJohnny2 3y ago
      Bypass the problem?? They'd only create more. There's millions of man-hours invested in optimizing software and hardware for the ARM64 ISA. Abandoning that for a nebulous "we can optimize for our stack" is not a worthwhile tradeoff.
      - vaxman 3y ago
        Nebulous? When TSMC can no longer economically cram more transistors onto the dye, Apple will need other ways of increasing performance to keep the upgrade cash coming in. Apple previously co-developed PowerPC with Motorola (and IBM) for this very reason. At this time, Apple has all but kicked its third-party developers out of kernel space on its operating systems which will make for easy transition to future architectures. I would go so far as to speculate Apple is already designing proprietary RISC-V extensions and even their own FABs to produce them. One would expect such extensions to help Apple's systems execute Swift and ObjC better (faster and more securely) than general purpose processors and to optimize shared memory and fabric access between CPU, NPU and GPU cores.
  - catiopatio 3y ago
    Almost no new projects within Apple are written using Objective-C, and old code is actively rewritten for many reasons, with security being a large one.
    - lapcat 3y ago
      Citation needed. I've already provided a citation: https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/ https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-...
      - catiopatio 3y ago
        I cannot provide a citation for my evidence. Your citation shows the clear trend, however. Swift usage is only increasing, and Objective-C is discouraged (not deprecated, discouraged) for new projects.
        lapcat 3y ago
        I find it interesting that Objective-C would need to be discouraged, which suggests that Apple engineers don't independently prefer Swift. ;-)
        catiopatio 3y ago
        I hope you won’t mind me saying so, but I’m most reminded of NeXT’s reverse-acquisition of Apple. It’s not quite as stark, but the same pattern is emerging — folks that couldn’t or wouldn’t adapt found themselves working on ever-shrinking islands — the blue box, ported userspace libraries, drivers, file systems, etc. I’ve written a lot of C and ObjC over the years, and I get where you’re coming from, but there are good reasons to move past C/ObjC for systems and application programming. Swift has some serious warts and is hardly my favorite language, but it brings a lot to the table relative to ObjC, and there’s still room to resolve many of its issues.
        lapcat 3y ago
  - jamil7 3y ago
    > 9 years later, the Swift tooling is still atrocious. Compile times are much longer To be fair you can’t really compare them since the Swift compiler is giving you a lot more guarantees than Objective-C which gives you basically zero. Rust is also atrociously slow to compile.
    - vbezhenar 3y ago
      If you can write the same program with Objective C or Swift, you definitely can compare tooling. Who cares about guarantees? People care about result. I actually feel that recently iOS and macOS programs became more buggy and unreliable compared to old versions. Not sure if that could be attributed to Swift.
      - saagarjha 3y ago
        People care about guarantees when their device gets hacked, for example.
      - user-the-name 3y ago
        [dead]
      - dagmx 3y ago
        Users care that their app doesn’t crash and doesn’t corrupt their data, or allows for RCE. ObjC gives you very few guarantees that your runtime data is correct. Swift makes for more resilient programs all around.
    - lapcat 3y ago
      > Objective-C which gives you basically zero Untrue. In fact, more and more compiler warnings have been added for Objective-C over the years. Moreover, there's the static analyzer, as well as runtime checkers and sanitizers.
      - dagmx 3y ago
        History has shown time and time again that static analysis is an appeal to unrealized perfect humans and not pragmatic realities of developers doing the least possible or hubris
- zffr 3y ago
  Most new code is probably written in Swift, but there’s still lots of ObjC code out there and people are still writing it to maintain/extend those code bases.
- flohofwoe 3y ago
  I use ObjC as a thin layer to talk to macOS/iOS frameworks with the rest of the code being mostly C and some C++. Swift would not only be complete overkill for that but also a lot more hassle with build system integration (don't even know if cmake supports mixed C/C++/Swift projects out of the box)
  - dagmx 3y ago
    FWIW , Cmake does support mixed language projects with Swift.
- miramba 3y ago
  I do. Not only because I don‘t want to rewrite my apps but because for me Objective-C is beautiful and better to read than any other language I tried. I never saw the point of learning a new language to implement the same things. The only benefit I could see was for Apple, pushing me a bit farther into their ecosystem which is incompatible with anything else. When it became obvious that Swift was the way to go I switched to js / hybrid app development for new projects. This seems to also die out now, but I‘m still sticking to it.
- mrbombastic 3y ago
  The bridging layer for react native apps is written in Objective-C for most native iOS things, so most react native libraries and apps will have a fair amount. Older apps and Apple also ensure it will stay alive for some time to come.
- vbezhenar 3y ago
  I prefer Objective C to Swift. I'm not professional Apple developer, though, just write code for fun in my spare time, so I have luxury of being able to select tools I like. I guess, in professional setting Swift took over most new projects.
- tagyro 3y ago
  I wrote my latest (released) iOS app in obj-c. While I see some of the benefits of swift, I find it unnecessarily unreadable. One might argue about this, but as a developer, I value how readable the code is (no matter the language). Going over various projects written in swift on github, more than 50% don't even compile without serious refactoring. OTOH, grab a project in obj-c, from 15+ years ago, compiles with minimal changes (or, most of the time, without any). I'm a big fan of Chris Lattner and his work, but swift is not his most successful children. While I believe his intentions were good, the end result is a mess worse than brainfuck (the programming language). YMMV
- pjmlp 3y ago
  Metal is written in Objective-C, with Swift bindings.
BrianHenryIE 3y ago
Also worth a look are: https://github.com/iosre/iOSAppReverseEngineering https://github.com/iosre/iOSAppReverseEngineering https://www.amazon.com/NSHipster-Obscure-Topics-Cocoa-Objective/dp/0991218205 https://www.amazon.com/NSHipster-Obscure-Topics-Cocoa-Object... and the ultimate: https://www.mikeash.com/book.html https://www.mikeash.com/book.html
- instagary 3y ago
  Have you come across any newer mobile RE resources?
  - lauriewired 3y ago
    (This is my own channel), but I recently made a video on Objective C calling conventions specifically for Reverse Engineers that you might enjoy, with more iOS videos incoming: https://youtu.be/eI-Btfjp-fg https://youtu.be/eI-Btfjp-fg As for modern RE resources, I can recommend Jonathan Levin's series of books on MacOS and iOS internals as a good reference. It's probably the newest information you are going to be able to get on iOS/mac internals outside of apple. https://newosxbook.com/ https://newosxbook.com/
    - saagarjha 3y ago
      Unfortunately the printed book slowly falls behind as Apple keeps updating things :(
  - BrianHenryIE 3y ago
    Nothing comes to mind that’s similar to that first link. I’m really just replying to emphasize to others how great it is. I learned a ton from it.
- 1propionyl 3y ago
  +1 for Mike Ash's Friday Q&A. Very fond memories of seeing a new post show up in my feed.
grishka 3y ago
As someone who's trying to bridge macOS's native APIs with Java for a future project, this is useful for me.
- tambourine_man 3y ago
  Believe it or not (i'm walking on air), there was a time when Apple had an official Cocoa-Java bridge . They were betting heavily on it, rewrote WebObjects on Java, etc. Then, for some reason, people began to realize ObjC was quite all right after all, despite its crazy bolted-on syntax, and it “caught on”, for some reason. Maybe because Mac OS X was already dog slow and memory hungry as it was to even consider Java. And, funnily enough, ObjC was the slower solution to C/C++ on Carbon, that they somehow menage to run on a phone with 128MB of RAM and a DVD player SOC.
  - r618 3y ago
    just CD player initially first iOSs didn't support user's videos playback
    - tambourine_man 3y ago
      It was a software limitation, IIRC. There were hacks that allowed you to record and play the small videos it generated.
  - pjmlp 3y ago
    Yeah, the Mac OS community was raised in Object Pascal and C++, Java came to be due to a mix of its initial hype, agreement with Sun, and fear that Objective-C would be too alien for the Mac developer community, due to its syntax and semantics. Copland was going to be a microkernel based with C++ frameworks, as an additional note, similar in spirit on how BeOS turned out to be. As that proven not to be an issue, and the community did indeed adopt it, they decided to cut down on costs of having multiple languages. A bit ironic, as we are back to the Object Pascal / C++ days, with two similar inspired languages.
    - 3y ago
ibiza 3y ago
Apple's original Objective-C docs are available at their Documentation Archive. They are quite good. • Programming With Objective-C (current): https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html https://developer.apple.com/library/archive/documentation/Co... • The Objective-C Programming Language (older): https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html https://developer.apple.com/library/archive/documentation/Co...
- woadwarrior01 3y ago
  Also, the Objective-C Runtime reference[1]. About a decade ago, I learnt Objective-C in a day, by reading "The Objective-C Programming Language" and the Runtime Reference. It's such a beautiful and simple language, if you know C. I wish Swift were as simple and succinct. AFAIK, Objective-C++ is still the easiest way to bridge C++ code with Swift code. Knowledge of Objective-C is still relevant for anyone building apps that need to use C++ libraries. [1] https://developer.apple.com/documentation/objectivec/objective-c_runtime https://developer.apple.com/documentation/objectivec/objecti...
  - ethansinjin 3y ago
    As of Swift 5.9, using Obj-C++ is no longer necessary! https://swift.org/documentation/cxx-interop/ https://swift.org/documentation/cxx-interop/
    - saagarjha 3y ago
      Yes it is; Swift’s interop is still experimental and limited.
    - pjmlp 3y ago
      That is still work in progress.
  - hugi 3y ago
    Objective-C was my first "real" language, started working with it with almost no knowledge of C to make some Mac Apps on Rhapsody and later Mac OS X. Nice documentation and an awesome first language, not least due to the lovely Foundation and AppKit frameworks and the nice UIs of ProjectBuilder and InterfaceBuilder at the time. It was pure fun writing software in that environment.
fabiensanglard 3y ago
What a beautiful website! Sadly cannot find a RSS feed :/ !
- lapcat 3y ago
  https://alwaysprocessing.blog/feed.xml https://alwaysprocessing.blog/feed.xml
iamflimflam1 3y ago
I really enjoyed Objective-C some very powerful ideas around message sending and handling. And you could just use C and C++ I loved it. I never got to use smalltalk. And Objective-C felt as close as I could ever get.

96 points by ingve 3y ago

I learned to program in Objective C, it was fun. Spent many hours digging behind the scenes, but the only fun fact I remember is that it’s a strict superset of C, so any C program is a valid Objective C program. Always found this fascinating. Are people still using it today? I thought Swift took over.

TazeTSchnitzel 3y ago
Can't speak to personal experience, but my understanding is Objective-C++ (which is most of C++ plus all of Objective-C) is still popular for bridging the Objective-C/Swift and C++ worlds. Though apparently Swift is getting a C++ interop system, so that might become less common!
lapcat 3y ago
> Are people still using it today? Yes, I am. Apple is too: https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/ https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-... In my estimation, these are the primary reasons why some developers continue to use Objective-C: 1) Rewriting an existing code base is almost always massively expensive and dangerous. 2) 9 years later, the Swift tooling is still atrocious. Compile times are much longer, the compiler still crashes, the debugger still doesn't work reliably. It's a major step down from the mature Objective-C tooling. 3) There are still land mines with interoperability between Swift code and Apple's underlying Objective-C frameworks. Performance bottlenecks, unexpected object bridging issues, erroneous nullability annotations, etc. 4) C and C++ compatibility, as mentioned by another commenter.
- MichaelZuo 3y ago
  Since Apple now controls the entire hardware stack for all their products (except the mac pro), they could conceivably design their own assembly language ('Apple Assembly'?) optimized for, and only for, Apple silicon and bypass the problem.
  - lapcat 3y ago
    Apple has already done this to some extent, though I don't have the references offhand. In any case, there's only so much that hardware can to do compensate for crappy software. It's not inherently a hardware problem.
    - MichaelZuo 3y ago
      It's possible, if they were motivated to really invest in it, to introduce some innovations. For example, it could warn about badly designed software, major flaws, etc... at the assembler level. And since they mostly control software distribution, to then block anything that receives such warnings.
      - saagarjha 3y ago
        There’s no need to do something like that. They just don’t optimize for certain code patterns.
  - AceJohnny2 3y ago
    Bypass the problem?? They'd only create more. There's millions of man-hours invested in optimizing software and hardware for the ARM64 ISA. Abandoning that for a nebulous "we can optimize for our stack" is not a worthwhile tradeoff.
    - vaxman 3y ago
      Nebulous? When TSMC can no longer economically cram more transistors onto the dye, Apple will need other ways of increasing performance to keep the upgrade cash coming in. Apple previously co-developed PowerPC with Motorola (and IBM) for this very reason. At this time, Apple has all but kicked its third-party developers out of kernel space on its operating systems which will make for easy transition to future architectures. I would go so far as to speculate Apple is already designing proprietary RISC-V extensions and even their own FABs to produce them. One would expect such extensions to help Apple's systems execute Swift and ObjC better (faster and more securely) than general purpose processors and to optimize shared memory and fabric access between CPU, NPU and GPU cores.
- catiopatio 3y ago
  Almost no new projects within Apple are written using Objective-C, and old code is actively rewritten for many reasons, with security being a large one.
  - lapcat 3y ago
    Citation needed. I've already provided a citation: https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/ https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-...
    - catiopatio 3y ago
      I cannot provide a citation for my evidence. Your citation shows the clear trend, however. Swift usage is only increasing, and Objective-C is discouraged (not deprecated, discouraged) for new projects.
      - lapcat 3y ago
        I find it interesting that Objective-C would need to be discouraged, which suggests that Apple engineers don't independently prefer Swift. ;-)
        catiopatio 3y ago
        I hope you won’t mind me saying so, but I’m most reminded of NeXT’s reverse-acquisition of Apple. It’s not quite as stark, but the same pattern is emerging — folks that couldn’t or wouldn’t adapt found themselves working on ever-shrinking islands — the blue box, ported userspace libraries, drivers, file systems, etc. I’ve written a lot of C and ObjC over the years, and I get where you’re coming from, but there are good reasons to move past C/ObjC for systems and application programming. Swift has some serious warts and is hardly my favorite language, but it brings a lot to the table relative to ObjC, and there’s still room to resolve many of its issues.
        lapcat 3y ago
- jamil7 3y ago
  > 9 years later, the Swift tooling is still atrocious. Compile times are much longer To be fair you can’t really compare them since the Swift compiler is giving you a lot more guarantees than Objective-C which gives you basically zero. Rust is also atrociously slow to compile.
  - vbezhenar 3y ago
    If you can write the same program with Objective C or Swift, you definitely can compare tooling. Who cares about guarantees? People care about result. I actually feel that recently iOS and macOS programs became more buggy and unreliable compared to old versions. Not sure if that could be attributed to Swift.
    - saagarjha 3y ago
      People care about guarantees when their device gets hacked, for example.
    - user-the-name 3y ago
      [dead]
    - dagmx 3y ago
      Users care that their app doesn’t crash and doesn’t corrupt their data, or allows for RCE. ObjC gives you very few guarantees that your runtime data is correct. Swift makes for more resilient programs all around.
  - lapcat 3y ago
    > Objective-C which gives you basically zero Untrue. In fact, more and more compiler warnings have been added for Objective-C over the years. Moreover, there's the static analyzer, as well as runtime checkers and sanitizers.
    - dagmx 3y ago
      History has shown time and time again that static analysis is an appeal to unrealized perfect humans and not pragmatic realities of developers doing the least possible or hubris
zffr 3y ago
Most new code is probably written in Swift, but there’s still lots of ObjC code out there and people are still writing it to maintain/extend those code bases.
flohofwoe 3y ago
I use ObjC as a thin layer to talk to macOS/iOS frameworks with the rest of the code being mostly C and some C++. Swift would not only be complete overkill for that but also a lot more hassle with build system integration (don't even know if cmake supports mixed C/C++/Swift projects out of the box)
- dagmx 3y ago
  FWIW , Cmake does support mixed language projects with Swift.
miramba 3y ago
I do. Not only because I don‘t want to rewrite my apps but because for me Objective-C is beautiful and better to read than any other language I tried. I never saw the point of learning a new language to implement the same things. The only benefit I could see was for Apple, pushing me a bit farther into their ecosystem which is incompatible with anything else. When it became obvious that Swift was the way to go I switched to js / hybrid app development for new projects. This seems to also die out now, but I‘m still sticking to it.
mrbombastic 3y ago
The bridging layer for react native apps is written in Objective-C for most native iOS things, so most react native libraries and apps will have a fair amount. Older apps and Apple also ensure it will stay alive for some time to come.
vbezhenar 3y ago
I prefer Objective C to Swift. I'm not professional Apple developer, though, just write code for fun in my spare time, so I have luxury of being able to select tools I like. I guess, in professional setting Swift took over most new projects.
tagyro 3y ago
I wrote my latest (released) iOS app in obj-c. While I see some of the benefits of swift, I find it unnecessarily unreadable. One might argue about this, but as a developer, I value how readable the code is (no matter the language). Going over various projects written in swift on github, more than 50% don't even compile without serious refactoring. OTOH, grab a project in obj-c, from 15+ years ago, compiles with minimal changes (or, most of the time, without any). I'm a big fan of Chris Lattner and his work, but swift is not his most successful children. While I believe his intentions were good, the end result is a mess worse than brainfuck (the programming language). YMMV
pjmlp 3y ago
Metal is written in Objective-C, with Swift bindings.

BrianHenryIE 3y ago

Also worth a look are: https://github.com/iosre/iOSAppReverseEngineering https://github.com/iosre/iOSAppReverseEngineering https://www.amazon.com/NSHipster-Obscure-Topics-Cocoa-Objective/dp/0991218205 https://www.amazon.com/NSHipster-Obscure-Topics-Cocoa-Object... and the ultimate: https://www.mikeash.com/book.html https://www.mikeash.com/book.html

instagary 3y ago
Have you come across any newer mobile RE resources?
- lauriewired 3y ago
  (This is my own channel), but I recently made a video on Objective C calling conventions specifically for Reverse Engineers that you might enjoy, with more iOS videos incoming: https://youtu.be/eI-Btfjp-fg https://youtu.be/eI-Btfjp-fg As for modern RE resources, I can recommend Jonathan Levin's series of books on MacOS and iOS internals as a good reference. It's probably the newest information you are going to be able to get on iOS/mac internals outside of apple. https://newosxbook.com/ https://newosxbook.com/
  - saagarjha 3y ago
    Unfortunately the printed book slowly falls behind as Apple keeps updating things :(
- BrianHenryIE 3y ago
  Nothing comes to mind that’s similar to that first link. I’m really just replying to emphasize to others how great it is. I learned a ton from it.
1propionyl 3y ago
+1 for Mike Ash's Friday Q&A. Very fond memories of seeing a new post show up in my feed.

grishka 3y ago

As someone who's trying to bridge macOS's native APIs with Java for a future project, this is useful for me.

tambourine_man 3y ago
Believe it or not (i'm walking on air), there was a time when Apple had an official Cocoa-Java bridge . They were betting heavily on it, rewrote WebObjects on Java, etc. Then, for some reason, people began to realize ObjC was quite all right after all, despite its crazy bolted-on syntax, and it “caught on”, for some reason. Maybe because Mac OS X was already dog slow and memory hungry as it was to even consider Java. And, funnily enough, ObjC was the slower solution to C/C++ on Carbon, that they somehow menage to run on a phone with 128MB of RAM and a DVD player SOC.
- r618 3y ago
  just CD player initially first iOSs didn't support user's videos playback
  - tambourine_man 3y ago
    It was a software limitation, IIRC. There were hacks that allowed you to record and play the small videos it generated.
- pjmlp 3y ago
  Yeah, the Mac OS community was raised in Object Pascal and C++, Java came to be due to a mix of its initial hype, agreement with Sun, and fear that Objective-C would be too alien for the Mac developer community, due to its syntax and semantics. Copland was going to be a microkernel based with C++ frameworks, as an additional note, similar in spirit on how BeOS turned out to be. As that proven not to be an issue, and the community did indeed adopt it, they decided to cut down on costs of having multiple languages. A bit ironic, as we are back to the Object Pascal / C++ days, with two similar inspired languages.
  - 3y ago

ibiza 3y ago

Apple's original Objective-C docs are available at their Documentation Archive. They are quite good. • Programming With Objective-C (current): https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html https://developer.apple.com/library/archive/documentation/Co... • The Objective-C Programming Language (older): https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html https://developer.apple.com/library/archive/documentation/Co...

woadwarrior01 3y ago
Also, the Objective-C Runtime reference[1]. About a decade ago, I learnt Objective-C in a day, by reading "The Objective-C Programming Language" and the Runtime Reference. It's such a beautiful and simple language, if you know C. I wish Swift were as simple and succinct. AFAIK, Objective-C++ is still the easiest way to bridge C++ code with Swift code. Knowledge of Objective-C is still relevant for anyone building apps that need to use C++ libraries. [1] https://developer.apple.com/documentation/objectivec/objective-c_runtime https://developer.apple.com/documentation/objectivec/objecti...
- ethansinjin 3y ago
  As of Swift 5.9, using Obj-C++ is no longer necessary! https://swift.org/documentation/cxx-interop/ https://swift.org/documentation/cxx-interop/
  - saagarjha 3y ago
    Yes it is; Swift’s interop is still experimental and limited.
  - pjmlp 3y ago
    That is still work in progress.
- hugi 3y ago
  Objective-C was my first "real" language, started working with it with almost no knowledge of C to make some Mac Apps on Rhapsody and later Mac OS X. Nice documentation and an awesome first language, not least due to the lovely Foundation and AppKit frameworks and the nice UIs of ProjectBuilder and InterfaceBuilder at the time. It was pure fun writing software in that environment.

fabiensanglard 3y ago

What a beautiful website! Sadly cannot find a RSS feed :/ !

lapcat 3y ago
https://alwaysprocessing.blog/feed.xml https://alwaysprocessing.blog/feed.xml

iamflimflam1 3y ago

I really enjoyed Objective-C some very powerful ideas around message sending and handling. And you could just use C and C++ I loved it. I never got to use smalltalk. And Objective-C felt as close as I could ever get.