6 ms·

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

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).
      - mpweiher 3y ago
        > People already enable pgo and lto which dramatically makes their build times worse all the time No. Not "all the time". Even the cases you listed are fairly unique corner cases. > 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 Apple does this not because the code would not be shippable, but because doing so for an OS once before shipping is a useful performance optimisation. Source: I used to work on the OS X performance team. Haven't heard that FB needs to do this, though their mobile development practices are so fubared that I wouldn't be surprised. The case that I do know about where they absolutely had to do crazy things to be shippable (more precisely: to remain below the iOS AppStore cellular download limit, a P1) was Uber. But that wasn't Objective-C, that was their Swift rewrite.
        zer0zzz 3y ago
        > Source: I used to work on the OS X performance team. I am so sorry to hear that. When I was at Apple I worked on a different part of the stack so my experience is not first hand here, but the folks I knew who worked on optimizing the shared cache either through ld or clang paint a different picture. I don't think they would ship without those performance optimizations, but I take your point that at least at the time you were there it was not as dire. That's not what it sounds like when I speak to those folks in the last year or two however (for iOS anyways). I don't think there's any universe where they wouldn't do these optis at the very least before shipping, but I don't mean that they can't have functioning non-optimized builds internally. Certain apps mentioned above really can not ship without this stuff, but you're right about the development practices. Given the app size limits and startup time constraints as well as the coding practices it is really not feasible to not do things like LTO, objc_direct as much as possible, and align the startup path of an app by page boundary etc. > was Uber. I am well aware of the Uber Swift rewrite and when I say "unable to ship" I don't mean it to that extent in every case, but my point is I don't think anyone is going to worry about lengthy prod build times if having faster builds means less engagement even in the single digits.
- zer0zzz 3y ago
  Also my answer to your question is: I think both. If it’s generally too hard for compiler people to optimize for the common case then it will be harder for folks to build great software. I’d also argue that apple did not do the former in regards to memory safety, rust did.
  - mpweiher 3y ago
    Demonstrably false. It is easy to write fast software in Objective-C. Harder in Swift, for example.
    - zer0zzz 3y ago
      What part are you responding to? I in no way made any claims about objc versus swift performance. I said the way they have tried to address memory safety assumes more compiler optimization and less burden to the programmer than rust.
      - mpweiher 3y ago
        "If it’s generally too hard for compiler people to optimize for the common case then it will be harder for folks to build great software." The compiler people don't need to optimise for the common case.
        zer0zzz 3y ago
        That’s literally all compiler people do.. if we see a pattern people are using 80 percent of the time we find a way to make it better. There are ways to make ObjC better optimized at the compiler and runtime level but no one is exactly asking for patches for doing so for objc for very obvious reasons (which I am not going to discuss on a public forum).
        mpweiher 3y ago
        > That’s literally all compiler people do. I know. My point is that in lots of cases it is unnecessary and in fact unhelpful. > make it better Well, you first need to get agreement from your language users on what constitutes "better". Removing the dynamism from a dynamic language does not make it "better".
pavlov 3y ago
That “one neat thing” was absolutely huge for APIs and applications. Much more significant for a platform than any feature of C++ ever, for instance. The performance wasn’t a real problem because you could always use C types for data on performance-sensitive paths. Nobody does Obj-C message calls to iterate over audio samples.
- zer0zzz 3y ago
  Yep. I think right now we just have too much objc code written that doesn’t need any of the parts of objc needed for frameworks.
flohofwoe 3y ago
The other thing that ObjC does right is that it builds on top of an unmodified C (unlike C++ which went full in, messed everything up and now needs the C++ standard to change to integrate new C features, which then usually ends up as half-assed and incomplete attempt - see designated initalization). C and ObjC can be improved independently from each other, and combining them "just works" without "harmonization efforts" by language committees. Also, doesn't the existance of ARC mean that ObjC supports better "static lifetime analysis" than C++? Or is C++ just behind the curve there?
- jb1991 3y ago
  ARC is runtime reference counting. How does that offer static lifetime analysis? C++ also has a form of ARC in the form of shared pointers, the only difference is that in C++ it's opt-in while in ObjC/Swift ARC it's just the way it is.
  - flohofwoe 3y ago
    ARC does static lifetime tracking (or maybe better: ownership tracking) to remove redundant reference counting operations (highly simplfied: it basically makes the decision for you when to use the equivalent of a shared_ptr or unique_ptr under the hood - which is at least nice for API design, since functions just take or return generic "object references" instead of raw, shared or unique pointers like in C++ (which then is usually not what the caller wants in a specific situation). ARC is not perfect because it has to be fairly conservative (it can be manually tuned though), but ObjC still seems to give the compiler more static information than shared_ptr and unique_ptr in C++ which are purely stdlib runtime constructs.
    - jb1991 3y ago
      I'd imagine Swift also does this?
      - flohofwoe 3y ago
        AFAIK Swift's ARC is the same thing, yeah.
chunkyguy 3y ago
But as an app developer, I love using Objective-C because it lets me build beautiful things without worrying about making the compiler happy.

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).
    - mpweiher 3y ago
      > People already enable pgo and lto which dramatically makes their build times worse all the time No. Not "all the time". Even the cases you listed are fairly unique corner cases. > 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 Apple does this not because the code would not be shippable, but because doing so for an OS once before shipping is a useful performance optimisation. Source: I used to work on the OS X performance team. Haven't heard that FB needs to do this, though their mobile development practices are so fubared that I wouldn't be surprised. The case that I do know about where they absolutely had to do crazy things to be shippable (more precisely: to remain below the iOS AppStore cellular download limit, a P1) was Uber. But that wasn't Objective-C, that was their Swift rewrite.
      - zer0zzz 3y ago
        > Source: I used to work on the OS X performance team. I am so sorry to hear that. When I was at Apple I worked on a different part of the stack so my experience is not first hand here, but the folks I knew who worked on optimizing the shared cache either through ld or clang paint a different picture. I don't think they would ship without those performance optimizations, but I take your point that at least at the time you were there it was not as dire. That's not what it sounds like when I speak to those folks in the last year or two however (for iOS anyways). I don't think there's any universe where they wouldn't do these optis at the very least before shipping, but I don't mean that they can't have functioning non-optimized builds internally. Certain apps mentioned above really can not ship without this stuff, but you're right about the development practices. Given the app size limits and startup time constraints as well as the coding practices it is really not feasible to not do things like LTO, objc_direct as much as possible, and align the startup path of an app by page boundary etc. > was Uber. I am well aware of the Uber Swift rewrite and when I say "unable to ship" I don't mean it to that extent in every case, but my point is I don't think anyone is going to worry about lengthy prod build times if having faster builds means less engagement even in the single digits.
zer0zzz 3y ago
Also my answer to your question is: I think both. If it’s generally too hard for compiler people to optimize for the common case then it will be harder for folks to build great software. I’d also argue that apple did not do the former in regards to memory safety, rust did.
- mpweiher 3y ago
  Demonstrably false. It is easy to write fast software in Objective-C. Harder in Swift, for example.
  - zer0zzz 3y ago
    What part are you responding to? I in no way made any claims about objc versus swift performance. I said the way they have tried to address memory safety assumes more compiler optimization and less burden to the programmer than rust.
    - mpweiher 3y ago
      "If it’s generally too hard for compiler people to optimize for the common case then it will be harder for folks to build great software." The compiler people don't need to optimise for the common case.
      - zer0zzz 3y ago
        That’s literally all compiler people do.. if we see a pattern people are using 80 percent of the time we find a way to make it better. There are ways to make ObjC better optimized at the compiler and runtime level but no one is exactly asking for patches for doing so for objc for very obvious reasons (which I am not going to discuss on a public forum).
        mpweiher 3y ago
        > That’s literally all compiler people do. I know. My point is that in lots of cases it is unnecessary and in fact unhelpful. > make it better Well, you first need to get agreement from your language users on what constitutes "better". Removing the dynamism from a dynamic language does not make it "better".

pavlov 3y ago

That “one neat thing” was absolutely huge for APIs and applications. Much more significant for a platform than any feature of C++ ever, for instance. The performance wasn’t a real problem because you could always use C types for data on performance-sensitive paths. Nobody does Obj-C message calls to iterate over audio samples.

zer0zzz 3y ago
Yep. I think right now we just have too much objc code written that doesn’t need any of the parts of objc needed for frameworks.

flohofwoe 3y ago

The other thing that ObjC does right is that it builds on top of an unmodified C (unlike C++ which went full in, messed everything up and now needs the C++ standard to change to integrate new C features, which then usually ends up as half-assed and incomplete attempt - see designated initalization). C and ObjC can be improved independently from each other, and combining them "just works" without "harmonization efforts" by language committees. Also, doesn't the existance of ARC mean that ObjC supports better "static lifetime analysis" than C++? Or is C++ just behind the curve there?

jb1991 3y ago
ARC is runtime reference counting. How does that offer static lifetime analysis? C++ also has a form of ARC in the form of shared pointers, the only difference is that in C++ it's opt-in while in ObjC/Swift ARC it's just the way it is.
- flohofwoe 3y ago
  ARC does static lifetime tracking (or maybe better: ownership tracking) to remove redundant reference counting operations (highly simplfied: it basically makes the decision for you when to use the equivalent of a shared_ptr or unique_ptr under the hood - which is at least nice for API design, since functions just take or return generic "object references" instead of raw, shared or unique pointers like in C++ (which then is usually not what the caller wants in a specific situation). ARC is not perfect because it has to be fairly conservative (it can be manually tuned though), but ObjC still seems to give the compiler more static information than shared_ptr and unique_ptr in C++ which are purely stdlib runtime constructs.
  - jb1991 3y ago
    I'd imagine Swift also does this?
    - flohofwoe 3y ago
      AFAIK Swift's ARC is the same thing, yeah.

chunkyguy 3y ago

But as an app developer, I love using Objective-C because it lets me build beautiful things without worrying about making the compiler happy.