6 ms·

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

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.
  - pjmlp 8y ago
    > 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 Then they should have known better. That makes sense for unit testing, in cases where mock classes would be required. All Java IDEs have object browsers no need for header files.
    - gurkendoktor 8y ago
      Mockability was the official reason until we started using Mockito 2. I hope everyone on the team was aware of the object browser. And yet they felt better with interfaces everywhere. It might have been a simple case of cargo-culting, though.
Redoubts 8y ago
> Part of that is lots of things about Swift are backwards (variable definition) or overly expressive (var/let/func). Is this a joke? This sounds like "the language is wrong because it didn't completely ape C"

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.
- pjmlp 8y ago
  > 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 Then they should have known better. That makes sense for unit testing, in cases where mock classes would be required. All Java IDEs have object browsers no need for header files.
  - gurkendoktor 8y ago
    Mockability was the official reason until we started using Mockito 2. I hope everyone on the team was aware of the object browser. And yet they felt better with interfaces everywhere. It might have been a simple case of cargo-culting, though.

Redoubts 8y ago

> Part of that is lots of things about Swift are backwards (variable definition) or overly expressive (var/let/func). Is this a joke? This sounds like "the language is wrong because it didn't completely ape C"