4 ms·
I think it's aged wonderfully. Given its requirement to be a pure superset of C, it's a far better (IMHO) version of "C with objects" than C++ has ever managed
by spacedcowboy 2y ago
I think it's aged wonderfully.
Given its requirement to be a pure superset of C, it's a far better (IMHO) version of "C with objects" than C++ has ever managed. If you have a good understanding of C, ObjC is just:
- ok, do all that stuff you did and pretty much forget about[*] memory management, we'll do that for you. This is utterly liberating.
- you want dictionaries, arrays, sets etc ? Gotcha covered
- you want real natively-built-in UTF support ? Yep, got that.
- you can even dynamically create/inspect/alter classes at runtime, which makes things like plugins an absolute doddle.
- on top of all that, if you really need something to be in C or C++, just add it. Pure superset, remember, so your other-language code (or 3rd party libraries) will link just fine.
What I never understood was why people (and to be clear, I am not aiming this at the parent post) would take a look at the [...] syntax and immediately move on. It reminds me of people who board an aeroplane and get whizzed to another continent at enormous speeds, elevation and concomitant pressure-differences and then complain about the in-service drinks. The drinks!
I'm an unabashed fan of ObjC - it pretty much hits the perfect sweet spot between the low-level access that C provides and the over-engineered bloat that C++ ended up as. There's a really minimal extra cognitive load (over C) in ObjC for all the extra facilities the language provides (and in some cases, like memory management, a lot less). It's a real shame that Apple were the only ones to get on board.
[*] Two caveats.
1) You do need to still understand about strong vs weak references. Since ARC. is "Automatic Reference Counting", two objects that each hold a strong reference to each other won't ever be automatically released.
2) If you actually do explicitly call malloc() on something, it's on you to call free(). The reasons to call malloc() are far less than under C but the option is still there for you (being a superset of 'C') if you want to get your hands dirty.
- Klonoar 2y agoThis is more or less where I'm at. It's an amazing language that people have an irrational hatred for due to bracket calls. Also, I know verbosity isn't for everyone, but let me tell you this: every single ObjC project I return to, I know what the hell is going on because of that verbosity. It might suck to write but it's amazing when put against the test of time.
- wslh 2y agoI like your answer but want to clarify what I meant with aging well: programming languages such as Rust and Zig are taking the place of C and C++ and ObjC is not growing, and I think there are ideas behind ObjC that can iterate further and take a new place, no matter if it is call ObjC2 or there are other new programming languages. The interesting things about ObjC are not completely outdated, many are original, but not followed by other initiatives (yet?). Memory management is one of the things you, and I pointed out. I enjoy the "Smalltalk style" of ObjC though.
- lapcat 2y ago> I like your answer but want to clarify what I meant with aging well: programming languages such as Rust and Zig are taking the place of C and C++ and ObjC is not growing This is a false dichotomy, because the primary alternative to Objective-C is Swift if you're writing apps for Apple platforms. And if you're not writing apps for Apple platforms, you wouldn't use ObjC or Swift, which are mostly Apple-specific and Apple-controlled.
- wslh 2y agoYour comment seems off-topic. If you review the entire thread, the discussion is focused on the programming language itself, not platform dichotomies. While it’s clear that Swift is the alternative to Objective-C, the discussion here centers on Objective-C as a viable option compared to C/C++, etc, independent of platform considerations.
- lapcat 2y ago> If you review the entire thread, the discussion is focused on the programming language itself, not platform dichotomies. This is not true. The OP said, "Around 2010, I started learning Objective-C to be part of the whole native mobile development movement." In other words, the OP learned Objective-C in order to write iPhone apps. As far as I'm aware, there's no ObjC toolchain for Android. > Objective-C as a viable option compared to C/C++, etc, independent of platform considerations. It doesn't make sense to consider ObjC independent of platform considerations.
- cosmic_cheese 2y agoThat ability to seamlessly intermix C, C++, and Objective-C I believe was a big driver for the numerous high quality third party apps that OS X became known for in the 2000s. Obj-C paired with AppKit, IB, and KVO made building a good UI a cinch, and for speed critical or cross platform parts under the hood you had C++ and its massive ecosystem of libraries. It was a powerful combination.
- krackers 2y agoEven just using plain C, CoreFoundation and grand central dispatch make for a really nice standard library. The fact that CoreFoundation bridges with Cocoa types is icing on the cake, and just makes every feel so cohesive in a way that's hard to appreciate unless you've used it. It's a shame that despite being open-source there hasn't been much interest in adopting CF or GCD outside the apple ecosystem.