6 ms·

I have used Objective-C since 1997 when I worked with WebObjects back then and I don't miss it for a second. When I have to touch our one codebase with Objectiv

I have used Objective-C since 1997 when I worked with WebObjects back then and I don't miss it for a second. When I have to touch our one codebase with Objective-C I have to groan. It was amazing for its day and I did enjoy it despite its shortcomings. But I can write way more highly functional code faster in Swift than I ever could in Objective-C due to real type safety and other modern features. I also spent years doing regular C and C++ and Java (not at the same time) and all 3 languages seem clunky to me now. Preferring Objective-C over Swift is wishing for the golden oldie days kind of thinking and I'm one with almost 4 decades of programming experience. Swift is still young and growing and sometimes thats a bit challenging to adapt, but its the one language I truly enjoy now.

0x0 8y ago
Objective-C in 1997 and in 2017 are almost two different languages. Between ARC and generics, auto-synthesized ivars, and blocks, there's not much missing from being a modern C#/Java-like language.
- zoul 8y ago
  I love Objective-C, but calling it (close to) a modern language is a long stretch. The “generics” are a joke, for example. The whole type system is miles from what can be expressed (and guaranteed!) by a modern language. We got an immense amount of fun out of it considering its age, but it’s time to move on.
  - tsycho 8y ago
    Totally agree that generics in objective c are very bare. And that's what frustrates me the most. Apple/Lattner could have improved them, but chose not to, by focusing all their energy on Swift. "Simple" things I want from generics: 1. Carry over generic information from header files to .m files, and not force us to drop all type information by having to use "id". 2. A compiler flag to enforce that the generic type must be specified at usage. 3. Where clauses in generics: Foo <T where T : NSCopying, MyProtocol>> 4. Generics on protocols, ideally with all the other features. I know some of these are not trivial to implement, but they are mostly new syntax and hence don't have backward compatibility issues (except #2 which is why I asked for a compiler flag).
    - saagarjha 8y ago
      I don’t understand how you think this should be implemented. Many classes informally conform to protocols or in some cases the conformance can only be checked at runtime with a respondsToSelector: check. So any generics at compile time stricter than what we currently have will just not work or be useful.
      - valuearb 8y ago
        Not useful as I’d rather find that mistake when a customer reports the crash, instead of having the compiler tell me?
        saagarjha 8y ago
        The point I'm making is that the compiler can't tell you this, since conventional Objective-C code does generics checking at runtime. There's just not enough information available for this to be reliably diagnosed.
    - mariodiana 8y ago
      I wan't to ask in all seriousness, or in all ignorance—I don't mind, so please take your pick—why generics are so important. Let's say, in the first case, you have an NSArray in Objective-C. The object in the array is of type id. Now, in the second case, you have an NSArray, but you've declared that it will only hold types of NSString. Why is the second any better? I ask, because the only way I could see it being better is if you're taking that array—that data structure—and passing it all over the program and using it everywhere. (Note to the literal-minded: this is hyperbole.) If that's what you're doing, that's not Object-Oriented Programming. If you're instead doing real OOP, you're designing an object that will perform a clearly circumscribed bit of work for you by responding to a set of messages. The NSArray may live inside that object—in other words, the object is composed in part by using an NSArray—but that array is hidden from the rest of the program. Generics are no big whoop-di-do in that case, because there is no client-programmer that has to worry about them; or, to put it another way, you—the original programmer—only have to worry about that NSArray with respect to the programming of that one object. In that case, the data type the array holds is not a big deal to keep track of. So, again—seriously—what is so great about generics? The whole point of Objective-C, originally, was that it was late-binding—which, if you ask Alan Kay, was the point of OOP in the first place. If you're worrying about types all over the place, you're doing something wrong, no?
- pjmlp 8y ago
  Other than safety, that is.
  - apple4ever 8y ago
    Meh, I think that is overrated.
    - kitsunesoba 8y ago
      It boils down to the self discipline of individual developers. If you’re meticulous in making sure you’ve dotted your I’s and crossed your T’s and haven’t let too many of those insidious cast statements slip in, you can write reasonably safe Obj-C, but during my career as an iOS dev I have yet to encounter an Obj-C codebase that was fully written by such developers. They’ve all been riddled with gratuitous casting, erroneous type assumptions, and other bad practices (that aren’t possible in Swift) to the point that it’s a wonder that they ever functioned as intended. Personally though, I’ve found that even when I’m keeping a close guard on things when writing Obj-C and am sure to avoid all the obvious pitfalls, bugs slip through in the most unexpected places, so I’m quite happy to have the Swift compiler double checking everything for me.
    - valuearb 8y ago
      I’ve never understood this opinion, and always wonder if it’s a professional developer espousing it. Because most of your time as a commercial developer is spent debugging, and Swift makes it far easier to write correct code, and to find bugs when you write incorrect code.
    - blub 8y ago
      On a positive note, at least you're just writing buggy programs and not killing your patients somewhere or causing industrial accidents. Unfortunately, as software continues disrupting various industries, it's less and leas certain that even buggy programs written by someone who thinks that safety is overrated will remain harmless.
    - pjmlp 8y ago
      Only because software is a special snowflake where companies aren't held responsible for shitty software.
- kitsunesoba 8y ago
  That’s a real stretch. As someone who previously wrote Obj-C and currently writes Swift full time, whenever I revisit and work on old Obj-C code I constantly have “oh right, Obj-C doesn’t have that” moments and either have to pull in some third-party library that does what I need or settle for a less than satisfactory (and usually dramatically longer) solution. I do have times when writing Swift where I miss some bit of Obj-C, but those are rare and are becoming fewer as the language develops.
jmpt 8y ago
I'm glad for you, but everything you said is completely subjective.
- IowaBoyInMN 8y ago
  I believe the parent was subjective as well. I am curious as to why you appear to label just this comment. HN is for opinions as well as facts and I deeply value all of them. Particularly the opinions that politely challenge me.
apple4ever 8y ago
I’m the opposite. When I see Swift I just groan. It’s so much hard and slower to write more highly functional code (not to mention going back to ready it) than Objective-C. Part of that is lots of things about Swift are backwards (variable definition) or overly expressive (var/let/func). I just cannot enjoy Swift at all. When I go back to Objective-C its just such a joy to write.
- baby 8y ago
  I'm surprised that anyone could find Objective-C a better language than Swift. I'm just waiting for iOS to move completely to Swift to start developing on that platform. It's a much better language.
  - vbezhenar 8y ago
    Not everyone wants features. Go is an extremely simple language, it doesn't even have generics. People use it widely anyway.
- valuearb 8y ago
  Developer productivity is far less determined by how fast you can write code, than by how many bugs you create, and how hard it is to fix them. The vast majority of time is spent debugging and maintaining code. And I feel like I can write in Swift nearly as fast as Objective C. Objective C was always so baroque, when I define a method or variable and declare the exact same thing in a header file? Properties syntax? I actually switched when Swift 1.0 came out (just after writing a twenty thousand line simulation engine in Objective C). It was so lightly baked I was starting to regret my decision for a couple months until version 1.2 released, only then could I ship my app commercially. Since then every release has only gotten better, and the rough edges are entirely gone. The only thing I miss from Objective C is compile time, and now just barely given how much faster the compiles have gotten.
  - gurkendoktor 8y ago
    > The vast majority of time is spent debugging and maintaining code. Not all programming is the same. I've seen a lot more code churn in frontend projects than in the backend, where the actual logic and persistence happens. That makes the speed of (re)writing code relatively more important (at least for the iOS apps I've worked on, YMMV). But even when I had to clean up legacy code, I spent most of my debugging time on on incorrect threading (typically using UIKit or Core Data from the wrong thread), AutoLayout errors, Apple framework bugs, storyboards/NIBs out of sync with code, performance degradations, or anything else where Swift doesn't help much. In my experience, Objective-C programmers aren't allergic to safety or brevity. We love ARC! It's just that Swift has taken away too much productivity, mostly through terrible tooling and by dividing the community, for very little gain. > Objective C was always so baroque, when I define a method or variable and declare the exact same thing in a header file When I helped out on a Java project, I noticed that my coworkers religiously created interfaces for every single class they wrote. They couldn't really explain it beyond it being a "best practice", but I suspect they enjoyed being able to look at a short file that only contained the interface plus JavaDoc, instead of opening the full implementation every time. They basically re-invented header files :P I don't think people would mind headers as much if Xcode was a better IDE, and we didn't have to copy declarations around manually.

0x0 8y ago

Objective-C in 1997 and in 2017 are almost two different languages. Between ARC and generics, auto-synthesized ivars, and blocks, there's not much missing from being a modern C#/Java-like language.

zoul 8y ago
I love Objective-C, but calling it (close to) a modern language is a long stretch. The “generics” are a joke, for example. The whole type system is miles from what can be expressed (and guaranteed!) by a modern language. We got an immense amount of fun out of it considering its age, but it’s time to move on.
- tsycho 8y ago
  Totally agree that generics in objective c are very bare. And that's what frustrates me the most. Apple/Lattner could have improved them, but chose not to, by focusing all their energy on Swift. "Simple" things I want from generics: 1. Carry over generic information from header files to .m files, and not force us to drop all type information by having to use "id". 2. A compiler flag to enforce that the generic type must be specified at usage. 3. Where clauses in generics: Foo <T where T : NSCopying, MyProtocol>> 4. Generics on protocols, ideally with all the other features. I know some of these are not trivial to implement, but they are mostly new syntax and hence don't have backward compatibility issues (except #2 which is why I asked for a compiler flag).
  - saagarjha 8y ago
    I don’t understand how you think this should be implemented. Many classes informally conform to protocols or in some cases the conformance can only be checked at runtime with a respondsToSelector: check. So any generics at compile time stricter than what we currently have will just not work or be useful.
    - valuearb 8y ago
      Not useful as I’d rather find that mistake when a customer reports the crash, instead of having the compiler tell me?
      - saagarjha 8y ago
        The point I'm making is that the compiler can't tell you this, since conventional Objective-C code does generics checking at runtime. There's just not enough information available for this to be reliably diagnosed.
  - mariodiana 8y ago
    I wan't to ask in all seriousness, or in all ignorance—I don't mind, so please take your pick—why generics are so important. Let's say, in the first case, you have an NSArray in Objective-C. The object in the array is of type id. Now, in the second case, you have an NSArray, but you've declared that it will only hold types of NSString. Why is the second any better? I ask, because the only way I could see it being better is if you're taking that array—that data structure—and passing it all over the program and using it everywhere. (Note to the literal-minded: this is hyperbole.) If that's what you're doing, that's not Object-Oriented Programming. If you're instead doing real OOP, you're designing an object that will perform a clearly circumscribed bit of work for you by responding to a set of messages. The NSArray may live inside that object—in other words, the object is composed in part by using an NSArray—but that array is hidden from the rest of the program. Generics are no big whoop-di-do in that case, because there is no client-programmer that has to worry about them; or, to put it another way, you—the original programmer—only have to worry about that NSArray with respect to the programming of that one object. In that case, the data type the array holds is not a big deal to keep track of. So, again—seriously—what is so great about generics? The whole point of Objective-C, originally, was that it was late-binding—which, if you ask Alan Kay, was the point of OOP in the first place. If you're worrying about types all over the place, you're doing something wrong, no?
pjmlp 8y ago
Other than safety, that is.
- apple4ever 8y ago
  Meh, I think that is overrated.
  - kitsunesoba 8y ago
    It boils down to the self discipline of individual developers. If you’re meticulous in making sure you’ve dotted your I’s and crossed your T’s and haven’t let too many of those insidious cast statements slip in, you can write reasonably safe Obj-C, but during my career as an iOS dev I have yet to encounter an Obj-C codebase that was fully written by such developers. They’ve all been riddled with gratuitous casting, erroneous type assumptions, and other bad practices (that aren’t possible in Swift) to the point that it’s a wonder that they ever functioned as intended. Personally though, I’ve found that even when I’m keeping a close guard on things when writing Obj-C and am sure to avoid all the obvious pitfalls, bugs slip through in the most unexpected places, so I’m quite happy to have the Swift compiler double checking everything for me.
  - valuearb 8y ago
    I’ve never understood this opinion, and always wonder if it’s a professional developer espousing it. Because most of your time as a commercial developer is spent debugging, and Swift makes it far easier to write correct code, and to find bugs when you write incorrect code.
  - blub 8y ago
    On a positive note, at least you're just writing buggy programs and not killing your patients somewhere or causing industrial accidents. Unfortunately, as software continues disrupting various industries, it's less and leas certain that even buggy programs written by someone who thinks that safety is overrated will remain harmless.
  - pjmlp 8y ago
    Only because software is a special snowflake where companies aren't held responsible for shitty software.
kitsunesoba 8y ago
That’s a real stretch. As someone who previously wrote Obj-C and currently writes Swift full time, whenever I revisit and work on old Obj-C code I constantly have “oh right, Obj-C doesn’t have that” moments and either have to pull in some third-party library that does what I need or settle for a less than satisfactory (and usually dramatically longer) solution. I do have times when writing Swift where I miss some bit of Obj-C, but those are rare and are becoming fewer as the language develops.

jmpt 8y ago

I'm glad for you, but everything you said is completely subjective.

IowaBoyInMN 8y ago
I believe the parent was subjective as well. I am curious as to why you appear to label just this comment. HN is for opinions as well as facts and I deeply value all of them. Particularly the opinions that politely challenge me.

apple4ever 8y ago

I’m the opposite. When I see Swift I just groan. It’s so much hard and slower to write more highly functional code (not to mention going back to ready it) than Objective-C. Part of that is lots of things about Swift are backwards (variable definition) or overly expressive (var/let/func). I just cannot enjoy Swift at all. When I go back to Objective-C its just such a joy to write.

baby 8y ago
I'm surprised that anyone could find Objective-C a better language than Swift. I'm just waiting for iOS to move completely to Swift to start developing on that platform. It's a much better language.
- vbezhenar 8y ago
  Not everyone wants features. Go is an extremely simple language, it doesn't even have generics. People use it widely anyway.
valuearb 8y ago
Developer productivity is far less determined by how fast you can write code, than by how many bugs you create, and how hard it is to fix them. The vast majority of time is spent debugging and maintaining code. And I feel like I can write in Swift nearly as fast as Objective C. Objective C was always so baroque, when I define a method or variable and declare the exact same thing in a header file? Properties syntax? I actually switched when Swift 1.0 came out (just after writing a twenty thousand line simulation engine in Objective C). It was so lightly baked I was starting to regret my decision for a couple months until version 1.2 released, only then could I ship my app commercially. Since then every release has only gotten better, and the rough edges are entirely gone. The only thing I miss from Objective C is compile time, and now just barely given how much faster the compiles have gotten.
- gurkendoktor 8y ago
  > The vast majority of time is spent debugging and maintaining code. Not all programming is the same. I've seen a lot more code churn in frontend projects than in the backend, where the actual logic and persistence happens. That makes the speed of (re)writing code relatively more important (at least for the iOS apps I've worked on, YMMV). But even when I had to clean up legacy code, I spent most of my debugging time on on incorrect threading (typically using UIKit or Core Data from the wrong thread), AutoLayout errors, Apple framework bugs, storyboards/NIBs out of sync with code, performance degradations, or anything else where Swift doesn't help much. In my experience, Objective-C programmers aren't allergic to safety or brevity. We love ARC! It's just that Swift has taken away too much productivity, mostly through terrible tooling and by dividing the community, for very little gain. > Objective C was always so baroque, when I define a method or variable and declare the exact same thing in a header file When I helped out on a Java project, I noticed that my coworkers religiously created interfaces for every single class they wrote. They couldn't really explain it beyond it being a "best practice", but I suspect they enjoyed being able to look at a short file that only contained the interface plus JavaDoc, instead of opening the full implementation every time. They basically re-invented header files :P I don't think people would mind headers as much if Xcode was a better IDE, and we didn't have to copy declarations around manually.