11 ms·

A love letter to Objective-C

62 points by ingve 3y ago

fractallyte 3y ago
It's "abstractions" that led to this: https://youtu.be/kZRE7HIO3vk https://youtu.be/kZRE7HIO3vk [The Thirty Million Line Problem] And Apple is one of the companies directly responsible for the explosion in complexity - and insanity - in modern computing. It's all so deeply entrenched - the hardware, abstraction layers, languages, culture - that it's difficult to imagine ever being able to extricate ourselves from this mess. We need another 'quantum leap' in technology, or some new paradigm...
- bsaul 3y ago
  i don't like to be overly enthusiastic, but an obvious instrument i see right now that would be capable to refactor 30 million lines are LLM. They might be a good tool to provide superhuman code simplification.
  - eska 3y ago
    I don’t think that throwing even more complexity at not only our problems but also our solutions is the lesson from that.
    - bsaul 3y ago
      it's a one-time shot though. You see what suggestions the LLM is producing, and decide or not to apply them. Once the code is refactored, you get back to regular coding.
      - flohofwoe 3y ago
        That doesn't sound like it's less work than an "AI free" approach. The tricky part with refactoring isn't figuring out what needs to be changed and how, but to implement the change in a way that it works with the rest of the system, while at the same time actually improving things (and not just applying a different coding style).
  - deleted 3y ago
    [deleted]
- Someone 3y ago
  > It's "abstractions" that led to this: https://youtu.be/kZRE7HIO3vk https://youtu.be/kZRE7HIO3vk [The Thirty Million Line Problem] > And Apple is one of the companies directly responsible for the explosion in complexity - and insanity - in modern computing. I’m not going to watch an almost two hour long video to check whether it supports that claim or not. Can you elaborate, especially on the “directly” and “insanity” parts?
- mpweiher 3y ago
  Hmm...Objective-C is exactly the kind of language that helps you prevent 30 million line problems. Of course it doesn't do this by itself. If you insist on using it like a C++ or a Java, you will get the same 30 million line problem, slightly worse, because Objective-C is not a good C++ or Java. But if you can use it right, as the good folks at NeXT did, then you can work magic (aka. a sufficiently advanced technology).
- fractallyte 3y ago
  Here's a summary of the video: Casey Muratori makes the point that we've had phenomenal growth in hardware power, but our software is not correspondingly better. Computers should be much more pleasant to use. We all know what he's talking about: laggy software, crashes, updates, driver issues, etc. Things are no longer coded from scratch - we pile code on top of code on top of code. Features accumulate, together with complexity - and bugs. How many lines of code does it take to read a text file, in a web browser? Across the whole stack - browser, website, OS, router - he estimates 56 million LoC. The OS alone takes 30 million lines of code! And yet, in the 90s, demo writers routinely produced literal operating systems on a single floppy disk. Remember Amiga demos? They 'hit the metal' because they weren't hobbled by drivers and other abstractions. But as hardware developed, the manufacturers removed that access, forcing developers to work through abstractions. A SoC is a super powered 1980s home computer, but we can't actually reach that hardware. And it's up to hardware people to start taking this problem seriously. And now my comments: Apple is one of those manufacturers. This article hit a nerve with me, because I dumped iOS development; because of the complexity and insanity. Swift is a sprawling behemoth of a language now, hugely complex, full of gotchas. In some senses, it has to be - because it's a reflection of the hardware. I'm not going to elaborate more. Quite simply: you can't program your iDevice, EVER, without going through Apple's prescribed programming language(s), frameworks, libraries, LLVM, and hardware drivers. That's Apple's fault. Computing should not be like this.
  - flohofwoe 3y ago
    > And yet, in the 90s, demo writers routinely produced literal operating systems on a single floppy disk. Remember Amiga demos? They 'hit the metal' because they weren't hobbled by drivers and other abstractions. That was possible because the hardware was essentially a "game engine API" (e.g. the hardware was designed to be conveniently used directly, and was also designed with game requirements in mind). Whether that's good or bad is definitely debatable, for instance on the Amiga the need for hardware backward compatibility because of popular games that directly accessed the hardware was definitely stalling the Amiga's progress in the 90's. I don't disagree with most of your points though. We're definitely in an age of unnecessary software bloat, but I think the answer isn't to go back to accessing hardware directly. A lot can be gained by just applying some common sense when writing code. PS: Apple or the iPhone definitely isn't at fault though. The mess already started with the PC and Windows (but this mess also gave us increadibly fast hardware progress in the second half of the 90's by allowing hardware to evolve faster because of driver abstraction layers).
orasis 3y ago
I’ve written a lot of Objective C. It is by far the worst language I’ve used professionally. While I don’t love Swift it is still a breath of fresh air compared to ObjC.
- buzzert 3y ago
  Care to elaborate? Objective-C's simplicity and minimalism is what makes it one of my favorites.
  - pavlov 3y ago
    I like Objective-C too. It's just C with a very good lightweight abstraction layer for modeling GUI apps. I'm enough of a purist to think Obj-C 2.0 (introduced around 2007 at the same time as iOS) was mostly a mistake. In old Objective-C, it was absolutely clear when you were sending a message. You couldn't mistake a line of C code for an Obj-C message call. But Obj-C 2.0 lets you use the same syntax for message calls and struct member access, as in: foo.view.bounds.size.width Two of these dots are expensive virtual message calls. The other two are practically free stack pointer offsets. It's not in good C spirit to introduce this kind of confusion about performance impact. (However it's very much in the worst C++ spirit of frivolous overrides.) And the benefits were mostly meaningless because the old way (which still works) was barely any longer to type, especially with IDE autocomplete: [[foo view] bounds].size.width
    - mpweiher 3y ago
      Yep. And what's even worse is that the semantics are muddled. foo.view.bounds.size.width = 200; This will not set the width of the view to 200.
    - another2another 3y ago
      >But Obj-C 2.0 lets you use the same syntax for message calls and struct member access I'm in 100% agreement, you should never hide the message passing syntax, and am not a fan of this feature. Alas it was probably introduced as a sop to those people that are constantly complaining about the syntax, and in the process made the language worse ergonomically, not better.
waynecochran 3y ago
No mention of smalltalk? Essentially Objective-C was smalltalk message passing bolted onto C. Then you had Objective-C++ which allowed a whole new language rolled in. I still find myself writing MacOS apps in Objective-C/C++ which allows me to use all the fantastic C++ libraries and frameworks that exist. No doubt Swift is a better language that gives you strong typing and functional constructs, but I’ll always have a place in my heart for Objective-C.
- pasc1878 3y ago
  Ruby is also based on Smalltalk. The author is just showing ignorance of where things come from.
  - mhoad 3y ago
    Thoughtbot is famously a Ruby shop since their inception, I don’t know that this detail just happened to slip their mind due to ignorance.
- halogen64 3y ago
  Why would they mention smalltalk? The article is framed from the writer's specific experience with both languages, not as a historical deep dive into the progenitors of Objective-C. Granted these historical details are super interesting, but feels far from the intent of the article.
  - waynecochran 3y ago
    Because that is in essence why Obj-C works the way it does -- e.g., has all the square brackets. Obj-C is the child of smalltalk and C. It wasn't created in a vacuum.
mhd 3y ago
> The language has respectably reached that level of maturity and support that allows it to just continues on, quietly running in the background. Didn't Apple tinker with Objective-C a lot during its runtime, or am I just concentrating on the bumps? I remember reading the Cox book ages ago, where you basically had a simple SmallTalk-ish message syntax on top of plain old C. NeXt you got protocols etc. Over the time of it being heavily used on OS X and especiallly iOS (where a lot of new and fledgling programmers came in), all kinds of stuff was added. Properties, various memory management experiments etc. Sure, after Swift was introduced, that seemed to have calmed down a bit. But "mature"? And no, it's not like other languages fare reasonably better, now that most of them are handled like products.
- gilgoomesh 3y ago
  Apple added a lot of sugar to different parts of Objective-C and a few side features – dot syntax, synthesised properties, blocks, etc. They're still adding tweaks like nullability, generics and other Swift-compatibility features. And they were continually changing things like NSString and NSNumber internal representations and allocation patterns to avoid actually allocating. They really only changed the runtime once – Objective-C 2.0 – which they mostly hid behind the transition to 64-bit. This introduced layout resilience (so they could add fields to objects without breaking compatibility) and tagged pointers (so the reference count could be stored inside the pointer).
  - pjmlp 3y ago
    There have been a couple of more runtime changes, for performance reasons, and better integration with Swift.
seydor 3y ago
Nobody loved objc. Apple forced people to do so. Sometimes people get Stockholm syndrome
- Conscat 3y ago
  Probably nobody has ever gotten Stockholm Syndrome, including the hostages in Stockholm.
  - pavlov 3y ago
    In a Babylon 5 episode (set a few centuries in the future) they call it the Helsinki Syndrome, which I thought was a clever little nod by the writer to remind us how a legend continues to mutate.
    - asjfka 3y ago
      I'm not aware of a mention in B5 but they do call it Helsinki Syndrome in Die Hard.
- __d 3y ago
  What about those of us who liked it before Apple touched it?
  - seydor 3y ago
    It was a figure of speech. You were a tiny minority https://www.researchgate.net/figure/Popularity-Trend-of-the-Objective-C-Programming-Language-13_fig2_297909273 https://www.researchgate.net/figure/Popularity-Trend-of-the-...
    - deleted 3y ago
      [deleted]
- mpweiher 3y ago
  I bought a NeXT because, among other reasons, it had Objective-C.
EGreg 3y ago
It’s not just objective C but the entire Apple ecosystem that grew up around it is a tangled ball of mess.
bowsamic 3y ago
I love both Objective-C and Swift. I prefer the former simply because it feels quite novel and interesting in 2023
zer0zzz 3y ago
Objective-C is probably the worst language I’ve ever encountered (speaking as a compiler guy). A language where you can’t prove anything is dead, where you can’t make any changes to the runtime to deal with the dynamic semantics is not great. ObjC did one neat thing by having language level runtime type resolution address the component oriented programming and Abi stability issues present in c++ and later addressed by things like COM. But at the cost of some seriously bad performance characteristics.
- mpweiher 3y ago
  Yeah, compiler people hate it. Because there's very little for them to do. The question is whether programming languages exist to make the compiler (people) happy, or to enable programmers to build great software. I'd argue the latter. Apple has now accepted the former.
  - zer0zzz 3y ago
    They have done some nice stuff recently with objc_direct. The minute you can annotate away the dynamism it’s much better. Question is what’s the best way to do this? Lots of folks have been investigating analysis of entire apps either at the source level or some ir (maybe mlir some day).
    - mpweiher 3y ago
      objc_direct is pretty awful. > The minute you can annotate away the dynamism it’s much better. Only if you think dynamism is a bad thing. It isn't. There are cases when you might want or need to take it away, but they are both (a) rare and (b) context sensitive. So taking the dynamism away at the supplier side is the wrong approach. > analysis of entire apps either at the source level Dramatically worse build times for little to no gain. What's not to like?!
      - zer0zzz 3y ago
        People already enable pgo and lto which dramatically makes their build times worse all the time just to produce a shipable app/dylib. When large objc codebases (apple, meta, google scale code bases) ship frameworks and apps they basically can’t do so without this sort of thing. World builds at apple literally take days. It’s also not little to no gain, codebases that misuse/overuse objc instead of C/C++ often get vastly better startup time (less selectors to page in at app boot) and app size because of this sort of thing (especially with lto and -Oz).
smohare 3y ago
[dead]
grishka 3y ago
One terrible thing about ObjC is that it considers it valid to call methods on null pointers. It just does nothing and returns 0/false/nil. This leads to especially frustrating bugs.
atombender 3y ago
So much negativity in this thread. I, for one, absolutely loved working with ObjC. I no longer do any macOS programming, but when I did, it was magical. Is the syntax weird and crazy? No doubt. It is, however, an extremely pragmatic approach. It's completely unique in that it offers a dynamic, very-high-level OO language on top of C, giving you a way to work on both levels. C (or C++) for the performance-sensitive parts and integration with C libraries, and ObjC for the glue that orchestrates the application. ObjC isn't without its faults, and if was starting to show its age, so it makes sense for Apple to develop Swift, though between the two languages, I think ObjC is the more innovative one. It's a lot like having a scripting language around a C core, though ObjC has stronger static typing. Dynamic dispatch, late binding, and interfaces (protocols) results in a super rich, dynamic ecosystem of objects all interacting with each other, fulfilling the promise of Smalltalk better — in the sense of being the basis for real, mainstream products, including macOS itself — than any implementation of Smalltalk ever did.
- Brian_K_White 3y ago
  Vala
  - uranusjr 3y ago
    I rooted so much for Vala when it first came out. Such good idea to bring the same good ideas to GLib. Alas it was not to be, the (irrational IMO) negativity around this approach killed it before it had a chance.
    - shrimp_emoji 3y ago
      >GNOME >A whole GNOME-specific language Lmao I was also a big Theranos investor and an early toe sock adopter.
waffletower 3y ago
I like many of the highlights of the article. I found it odd that Objective-C was described in terms of Ruby, rather than the reverse given that Objective-C was initially developed more than a decade earlier than Ruby. I do understand that the author came to the language Objective-C after a long history with Ruby.
lapcat 3y ago
> It’s really a testament to the Objective-C runtime (and Ruby C extension API) that while much of the original code was written in 2001, an incredible amount of it runs unchanged over 20 years later on modern versions of macOS and Ruby. This is one of the things I love. Starting in 2014 with the introduction of Swift and continuing to the present, I've heard people claim that every line of Objective-C code you write is technical debt, but the opposite turned out to be true: any Swift code you wrote in the early years is now completely unusable. Apple even removed some Swift version migration tools from Xcode. Meanwhile, old Objective-C code still Just Works™. I continue to write ObjC today, with no regrets. Another thing I love is that you can import open source C projects with no changes whatsoever. Compiling is much faster. The debugger actually works (though Apple has been making it worse lately). There are so many practical advantages to Objective-C, even if it's not the most "beautiful" language. Objective-C has always valued pragmatism over idealism, as the marriage between high level object-oriented programming and low-level systems programming.
chunkyguy 3y ago
I don't miss Objective-C because I still use it on daily basis. I also like Swift, I use it daily at work but I don't see the point of using Swift when working on solo projects. ObjC is fast, fun and I personally feel very productive in it.

62 points by ingve 3y ago

It's "abstractions" that led to this: https://youtu.be/kZRE7HIO3vk https://youtu.be/kZRE7HIO3vk [The Thirty Million Line Problem] And Apple is one of the companies directly responsible for the explosion in complexity - and insanity - in modern computing. It's all so deeply entrenched - the hardware, abstraction layers, languages, culture - that it's difficult to imagine ever being able to extricate ourselves from this mess. We need another 'quantum leap' in technology, or some new paradigm...

bsaul 3y ago
i don't like to be overly enthusiastic, but an obvious instrument i see right now that would be capable to refactor 30 million lines are LLM. They might be a good tool to provide superhuman code simplification.
- eska 3y ago
  I don’t think that throwing even more complexity at not only our problems but also our solutions is the lesson from that.
  - bsaul 3y ago
    it's a one-time shot though. You see what suggestions the LLM is producing, and decide or not to apply them. Once the code is refactored, you get back to regular coding.
    - flohofwoe 3y ago
      That doesn't sound like it's less work than an "AI free" approach. The tricky part with refactoring isn't figuring out what needs to be changed and how, but to implement the change in a way that it works with the rest of the system, while at the same time actually improving things (and not just applying a different coding style).
- deleted 3y ago
  [deleted]
Someone 3y ago
> It's "abstractions" that led to this: https://youtu.be/kZRE7HIO3vk https://youtu.be/kZRE7HIO3vk [The Thirty Million Line Problem] > And Apple is one of the companies directly responsible for the explosion in complexity - and insanity - in modern computing. I’m not going to watch an almost two hour long video to check whether it supports that claim or not. Can you elaborate, especially on the “directly” and “insanity” parts?
mpweiher 3y ago
Hmm...Objective-C is exactly the kind of language that helps you prevent 30 million line problems. Of course it doesn't do this by itself. If you insist on using it like a C++ or a Java, you will get the same 30 million line problem, slightly worse, because Objective-C is not a good C++ or Java. But if you can use it right, as the good folks at NeXT did, then you can work magic (aka. a sufficiently advanced technology).
fractallyte 3y ago
Here's a summary of the video: Casey Muratori makes the point that we've had phenomenal growth in hardware power, but our software is not correspondingly better. Computers should be much more pleasant to use. We all know what he's talking about: laggy software, crashes, updates, driver issues, etc. Things are no longer coded from scratch - we pile code on top of code on top of code. Features accumulate, together with complexity - and bugs. How many lines of code does it take to read a text file, in a web browser? Across the whole stack - browser, website, OS, router - he estimates 56 million LoC. The OS alone takes 30 million lines of code! And yet, in the 90s, demo writers routinely produced literal operating systems on a single floppy disk. Remember Amiga demos? They 'hit the metal' because they weren't hobbled by drivers and other abstractions. But as hardware developed, the manufacturers removed that access, forcing developers to work through abstractions. A SoC is a super powered 1980s home computer, but we can't actually reach that hardware. And it's up to hardware people to start taking this problem seriously. And now my comments: Apple is one of those manufacturers. This article hit a nerve with me, because I dumped iOS development; because of the complexity and insanity. Swift is a sprawling behemoth of a language now, hugely complex, full of gotchas. In some senses, it has to be - because it's a reflection of the hardware. I'm not going to elaborate more. Quite simply: you can't program your iDevice, EVER, without going through Apple's prescribed programming language(s), frameworks, libraries, LLVM, and hardware drivers. That's Apple's fault. Computing should not be like this.
- flohofwoe 3y ago
  > And yet, in the 90s, demo writers routinely produced literal operating systems on a single floppy disk. Remember Amiga demos? They 'hit the metal' because they weren't hobbled by drivers and other abstractions. That was possible because the hardware was essentially a "game engine API" (e.g. the hardware was designed to be conveniently used directly, and was also designed with game requirements in mind). Whether that's good or bad is definitely debatable, for instance on the Amiga the need for hardware backward compatibility because of popular games that directly accessed the hardware was definitely stalling the Amiga's progress in the 90's. I don't disagree with most of your points though. We're definitely in an age of unnecessary software bloat, but I think the answer isn't to go back to accessing hardware directly. A lot can be gained by just applying some common sense when writing code. PS: Apple or the iPhone definitely isn't at fault though. The mess already started with the PC and Windows (but this mess also gave us increadibly fast hardware progress in the second half of the 90's by allowing hardware to evolve faster because of driver abstraction layers).

orasis 3y ago

I’ve written a lot of Objective C. It is by far the worst language I’ve used professionally. While I don’t love Swift it is still a breath of fresh air compared to ObjC.

buzzert 3y ago
Care to elaborate? Objective-C's simplicity and minimalism is what makes it one of my favorites.
- pavlov 3y ago
  I like Objective-C too. It's just C with a very good lightweight abstraction layer for modeling GUI apps. I'm enough of a purist to think Obj-C 2.0 (introduced around 2007 at the same time as iOS) was mostly a mistake. In old Objective-C, it was absolutely clear when you were sending a message. You couldn't mistake a line of C code for an Obj-C message call. But Obj-C 2.0 lets you use the same syntax for message calls and struct member access, as in: foo.view.bounds.size.width Two of these dots are expensive virtual message calls. The other two are practically free stack pointer offsets. It's not in good C spirit to introduce this kind of confusion about performance impact. (However it's very much in the worst C++ spirit of frivolous overrides.) And the benefits were mostly meaningless because the old way (which still works) was barely any longer to type, especially with IDE autocomplete: [[foo view] bounds].size.width
  - mpweiher 3y ago
    Yep. And what's even worse is that the semantics are muddled. foo.view.bounds.size.width = 200; This will not set the width of the view to 200.
  - another2another 3y ago
    >But Obj-C 2.0 lets you use the same syntax for message calls and struct member access I'm in 100% agreement, you should never hide the message passing syntax, and am not a fan of this feature. Alas it was probably introduced as a sop to those people that are constantly complaining about the syntax, and in the process made the language worse ergonomically, not better.

waynecochran 3y ago

No mention of smalltalk? Essentially Objective-C was smalltalk message passing bolted onto C. Then you had Objective-C++ which allowed a whole new language rolled in. I still find myself writing MacOS apps in Objective-C/C++ which allows me to use all the fantastic C++ libraries and frameworks that exist. No doubt Swift is a better language that gives you strong typing and functional constructs, but I’ll always have a place in my heart for Objective-C.

pasc1878 3y ago
Ruby is also based on Smalltalk. The author is just showing ignorance of where things come from.
- mhoad 3y ago
  Thoughtbot is famously a Ruby shop since their inception, I don’t know that this detail just happened to slip their mind due to ignorance.
halogen64 3y ago
Why would they mention smalltalk? The article is framed from the writer's specific experience with both languages, not as a historical deep dive into the progenitors of Objective-C. Granted these historical details are super interesting, but feels far from the intent of the article.
- waynecochran 3y ago
  Because that is in essence why Obj-C works the way it does -- e.g., has all the square brackets. Obj-C is the child of smalltalk and C. It wasn't created in a vacuum.

mhd 3y ago

> The language has respectably reached that level of maturity and support that allows it to just continues on, quietly running in the background. Didn't Apple tinker with Objective-C a lot during its runtime, or am I just concentrating on the bumps? I remember reading the Cox book ages ago, where you basically had a simple SmallTalk-ish message syntax on top of plain old C. NeXt you got protocols etc. Over the time of it being heavily used on OS X and especiallly iOS (where a lot of new and fledgling programmers came in), all kinds of stuff was added. Properties, various memory management experiments etc. Sure, after Swift was introduced, that seemed to have calmed down a bit. But "mature"? And no, it's not like other languages fare reasonably better, now that most of them are handled like products.

gilgoomesh 3y ago
Apple added a lot of sugar to different parts of Objective-C and a few side features – dot syntax, synthesised properties, blocks, etc. They're still adding tweaks like nullability, generics and other Swift-compatibility features. And they were continually changing things like NSString and NSNumber internal representations and allocation patterns to avoid actually allocating. They really only changed the runtime once – Objective-C 2.0 – which they mostly hid behind the transition to 64-bit. This introduced layout resilience (so they could add fields to objects without breaking compatibility) and tagged pointers (so the reference count could be stored inside the pointer).
- pjmlp 3y ago
  There have been a couple of more runtime changes, for performance reasons, and better integration with Swift.

seydor 3y ago

Nobody loved objc. Apple forced people to do so. Sometimes people get Stockholm syndrome

Conscat 3y ago
Probably nobody has ever gotten Stockholm Syndrome, including the hostages in Stockholm.
- pavlov 3y ago
  In a Babylon 5 episode (set a few centuries in the future) they call it the Helsinki Syndrome, which I thought was a clever little nod by the writer to remind us how a legend continues to mutate.
  - asjfka 3y ago
    I'm not aware of a mention in B5 but they do call it Helsinki Syndrome in Die Hard.
__d 3y ago
What about those of us who liked it before Apple touched it?
- seydor 3y ago
  It was a figure of speech. You were a tiny minority https://www.researchgate.net/figure/Popularity-Trend-of-the-Objective-C-Programming-Language-13_fig2_297909273 https://www.researchgate.net/figure/Popularity-Trend-of-the-...
  - deleted 3y ago
    [deleted]
mpweiher 3y ago
I bought a NeXT because, among other reasons, it had Objective-C.

EGreg 3y ago

It’s not just objective C but the entire Apple ecosystem that grew up around it is a tangled ball of mess.

bowsamic 3y ago

I love both Objective-C and Swift. I prefer the former simply because it feels quite novel and interesting in 2023

zer0zzz 3y ago

Objective-C is probably the worst language I’ve ever encountered (speaking as a compiler guy). A language where you can’t prove anything is dead, where you can’t make any changes to the runtime to deal with the dynamic semantics is not great. ObjC did one neat thing by having language level runtime type resolution address the component oriented programming and Abi stability issues present in c++ and later addressed by things like COM. But at the cost of some seriously bad performance characteristics.

mpweiher 3y ago
Yeah, compiler people hate it. Because there's very little for them to do. The question is whether programming languages exist to make the compiler (people) happy, or to enable programmers to build great software. I'd argue the latter. Apple has now accepted the former.
- zer0zzz 3y ago
  They have done some nice stuff recently with objc_direct. The minute you can annotate away the dynamism it’s much better. Question is what’s the best way to do this? Lots of folks have been investigating analysis of entire apps either at the source level or some ir (maybe mlir some day).
  - mpweiher 3y ago
    objc_direct is pretty awful. > The minute you can annotate away the dynamism it’s much better. Only if you think dynamism is a bad thing. It isn't. There are cases when you might want or need to take it away, but they are both (a) rare and (b) context sensitive. So taking the dynamism away at the supplier side is the wrong approach. > analysis of entire apps either at the source level Dramatically worse build times for little to no gain. What's not to like?!
    - zer0zzz 3y ago
      People already enable pgo and lto which dramatically makes their build times worse all the time just to produce a shipable app/dylib. When large objc codebases (apple, meta, google scale code bases) ship frameworks and apps they basically can’t do so without this sort of thing. World builds at apple literally take days. It’s also not little to no gain, codebases that misuse/overuse objc instead of C/C++ often get vastly better startup time (less selectors to page in at app boot) and app size because of this sort of thing (especially with lto and -Oz).

smohare 3y ago

[dead]

grishka 3y ago

One terrible thing about ObjC is that it considers it valid to call methods on null pointers. It just does nothing and returns 0/false/nil. This leads to especially frustrating bugs.

atombender 3y ago

So much negativity in this thread. I, for one, absolutely loved working with ObjC. I no longer do any macOS programming, but when I did, it was magical. Is the syntax weird and crazy? No doubt. It is, however, an extremely pragmatic approach. It's completely unique in that it offers a dynamic, very-high-level OO language on top of C, giving you a way to work on both levels. C (or C++) for the performance-sensitive parts and integration with C libraries, and ObjC for the glue that orchestrates the application. ObjC isn't without its faults, and if was starting to show its age, so it makes sense for Apple to develop Swift, though between the two languages, I think ObjC is the more innovative one. It's a lot like having a scripting language around a C core, though ObjC has stronger static typing. Dynamic dispatch, late binding, and interfaces (protocols) results in a super rich, dynamic ecosystem of objects all interacting with each other, fulfilling the promise of Smalltalk better — in the sense of being the basis for real, mainstream products, including macOS itself — than any implementation of Smalltalk ever did.

Brian_K_White 3y ago
Vala
- uranusjr 3y ago
  I rooted so much for Vala when it first came out. Such good idea to bring the same good ideas to GLib. Alas it was not to be, the (irrational IMO) negativity around this approach killed it before it had a chance.
  - shrimp_emoji 3y ago
    >GNOME >A whole GNOME-specific language Lmao I was also a big Theranos investor and an early toe sock adopter.

waffletower 3y ago

I like many of the highlights of the article. I found it odd that Objective-C was described in terms of Ruby, rather than the reverse given that Objective-C was initially developed more than a decade earlier than Ruby. I do understand that the author came to the language Objective-C after a long history with Ruby.

lapcat 3y ago

> It’s really a testament to the Objective-C runtime (and Ruby C extension API) that while much of the original code was written in 2001, an incredible amount of it runs unchanged over 20 years later on modern versions of macOS and Ruby. This is one of the things I love. Starting in 2014 with the introduction of Swift and continuing to the present, I've heard people claim that every line of Objective-C code you write is technical debt, but the opposite turned out to be true: any Swift code you wrote in the early years is now completely unusable. Apple even removed some Swift version migration tools from Xcode. Meanwhile, old Objective-C code still Just Works™. I continue to write ObjC today, with no regrets. Another thing I love is that you can import open source C projects with no changes whatsoever. Compiling is much faster. The debugger actually works (though Apple has been making it worse lately). There are so many practical advantages to Objective-C, even if it's not the most "beautiful" language. Objective-C has always valued pragmatism over idealism, as the marriage between high level object-oriented programming and low-level systems programming.

chunkyguy 3y ago

I don't miss Objective-C because I still use it on daily basis. I also like Swift, I use it daily at work but I don't see the point of using Swift when working on solo projects. ObjC is fast, fun and I personally feel very productive in it.