4 ms·

could not agree more with the author here. Swift certainly is a nice, impressive, modern language but it seems like Apple created a language they want themselv

could not agree more with the author here. Swift certainly is a nice, impressive, modern language but it seems like Apple created a language they want themselves to rewrite OS frameworks with millions of lines of code. i could also see it as a rival to C++ in Game (engine) creation. i don't see it suited at all to the average app with less than 100kloc though. points from the article: > […] but I personally think it's harder to master Swift than to master Objective-C absolutely. one can learn Objective-C in an afternoon if you know C - and master it in a few weeks. mastering Swift (like C++) could take decades. why is that the case? because it is a very complex language with many advanced features (like C++) that solve problems that you don't even have in simpler languages. some of these features also solve problems for extremely complex projects or some performance requirements but the simple truth is that most apps on both mobile and desktop are relatively simple (<50kloc) and are better suited by simpler languages with high productivity. (and you can always drop down to C if you see performance issues with Obj-C...) > I don't see how I'm sacrificing safety by continuing to write Objective-C. me neither. yeah Objective-C is not memory safe but no seasoned programmer would ever make those mistakes that Swift aims to solve here - with a high price. our flagship app is still written in Objective-C and i see nothing to gain by switching to Swift. p.s. shameless plug, if you live and breathe Objective-C and want to work on a cool app (MacUpdater), drop me a line at jobs@corecode.io

Pulcinella 3y ago
> me neither. yeah Objective-C is not memory safe but no seasoned programmer would ever make those mistakes that Swift aims to solve here - with a high price. Citation seriously needed. Like just look at the entire history of memory safety related bugs and security issues.
- dinkblam 3y ago
  have you ever had a look at any Objective-C codebase? Objective-C is a high-level language and there usually is no memory manipulation. just because the possibility exists (via dropping down to the C part of it) doesn't mean it is done. ARC does memory management for you and there hasn't been the need for manual memory management in ages. even that was pretty hassle-free. i can count the memory bugs i have seen our Objective-C projects in the past 10 years on one hand. > entire history of memory safety related bugs and security issues you are talking about C and C++, not Obj-C
  - pjmlp 3y ago
    One just needs to read Apple's security bulletins to know how it actually works in practice.
- b3morales 3y ago
  A citation is needed for the number of iOS projects that have more than a minuscule amount of code at the application level that risks memory unsafety.¹ The value proposition becomes stronger for the system frameworks that the app consumes, of course. (Although even the stdlib dips more than once into memory-unsafe Swift for performance.) But this brings us to another of the points from the article: is it really best to use one language for both use cases? ¹And additionally for whether those project would eliminate such code if rewritten in Swift.
  - pjmlp 3y ago
    Apple's security bulletins for one.
happytoexplain 3y ago
>yeah Objective-C is not memory safe but no seasoned programmer would ever make those mistakes that Swift aims to solve here Wow, that's a hell of an assertion!
- masklinn 3y ago
  Perfect C programmers strike again. Good thing they’re around and memory safety is never a problem thanks to their seasoned work.
- twoodfin 3y ago
  Fortunately, Apple has a decade or more of crash telemetry that tells them exactly how often users hit such problems running code from “seasoned programmers”!
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
turdprincess 3y ago
[flagged]
- lapcat 3y ago
  > I think the reason why the "pro Obj C" lobby strikes such a nerve is that their personal preference is holding back the whole team. You appear to be complaining about some anecdotal experience of yours. Exactly how many different teams have you been on where this happened? It should be noted that the article author has been a lone developer since 2016 and hasn't belonged to or "held back" any teams during that time. In any case, rewriting existing, working code is usually a bad idea regardless of the language, so if that's what you were aiming for on your team, it wouldn't be surprising to meet resistance on that. > Objective C actively makes it harder to do such best practices Completely untrue.
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
  - turdprincess 3y ago
    It is true though! Consider a simple example where you have two classes, with one depending on the other. As a best practice, I'd like to inject one class into the other's constructor, so I could do some unit testing. Here is the Swift code: class Dependency1 { } class Object1 { private let dependency: Dependency1 init(dependency: Dependency1 = Dependency1()) { self.dependency = dependency } } And the Objective C equivalent: @interface Dependency1 : NSObject @end @implementation Dependency1 @end @interface Object1 : NSObject - (instancetype)initWithDependency:(Dependency1 *)dependency; - (instancetype)init; @end @interface Object1() @property (nonatomic, strong, readonly) Dependency1 *dependency; @end @implementation Object1 - (instancetype)initWithDependency:(Dependency1 *)dependency { self = [super init]; if (self) { _dependency = dependecy; } return self; } - (instancetype)init { return [self initWithDependency:[[Dependency1 alloc] init]]; } @end Thats 9 lines of code in Swift and 31 lines of code in Objective C. If I have to type 3 times more code every time I want to break up big class into a few smaller ones, I am going to be much less likely to do it. In other words, the sheer verbosity of Objective C will make even the most disciplined developer start cutting corners to reduce effort, which ultimately leads to codebases which are messier, harder to test and less flexible. And finally, looking at the example above, is it really true that Objective C is easier to learn and understand than Swift? The code forces you to learn: * What is an NSObject? * How to create a private category on an class * What does "alloc init" do, and why is it different than "new"? * What is the difference between `self.dependency` and `_dependency`, and why does one let me change a "readonly" property? * Why would `super init` return nil, and what does that mean? For sure Swift also has its share of nuance, but I feel like the Objective C nuance is just baggage, while the Swift nuance opens the door to a richer feature set. [edited] updated code for correctness
danaris 3y ago
> absolutely. one can learn Objective-C in an afternoon if you know C ...See, that last part you toss off as if it's practically a given, but it's really not. Sure, when I was (and probably you were) first going to CS classes, being taught C was pretty much the standard thing. But that's much less true now, from all I've seen. And why not? 20 years ago, it was much, much more likely that if you were a programmer, you were going to be working with C code at some point. Nowadays, you can easily have full mastery in a dozen different languages, all of which are in widespread demand, and never touch C. (Or C++. Or C#. Or Objective-C.) Personally, where I am at this point in my career? If I wanted to write a small utility program that runs natively on macOS, I'd pick Swift over C 10 times out of 10. I'm roughly equally familiar with both of them (which is "moderately"), and I know enough about the pitfalls of C to know that I don't want to deal with them, and Swift handles almost all of the frustration of memory management for me. Plus, there's a single authoritative source for information about Swift for when I run into something I'm unfamiliar with, forgot, or got confused about. If I try the same in C there's literally thousands of different sources, of varying authority, across every major and minor platform that's ever existed, and every version of C. It's fantastic that there's all that information out there, don't get me wrong, but when I'm trying to write a small utility to solve a specific problem, every time I run into something that's talking about the wrong C version, or the wrong platform, or just plain has bad information, is going to add one more bit of frustration that's likely to make me quit trying. Yes, Apple's documentation is imperfect—but I always know that it is there, acting as a single authority for the language.

Pulcinella 3y ago

> me neither. yeah Objective-C is not memory safe but no seasoned programmer would ever make those mistakes that Swift aims to solve here - with a high price. Citation seriously needed. Like just look at the entire history of memory safety related bugs and security issues.

dinkblam 3y ago
have you ever had a look at any Objective-C codebase? Objective-C is a high-level language and there usually is no memory manipulation. just because the possibility exists (via dropping down to the C part of it) doesn't mean it is done. ARC does memory management for you and there hasn't been the need for manual memory management in ages. even that was pretty hassle-free. i can count the memory bugs i have seen our Objective-C projects in the past 10 years on one hand. > entire history of memory safety related bugs and security issues you are talking about C and C++, not Obj-C
- pjmlp 3y ago
  One just needs to read Apple's security bulletins to know how it actually works in practice.
b3morales 3y ago
A citation is needed for the number of iOS projects that have more than a minuscule amount of code at the application level that risks memory unsafety.¹ The value proposition becomes stronger for the system frameworks that the app consumes, of course. (Although even the stdlib dips more than once into memory-unsafe Swift for performance.) But this brings us to another of the points from the article: is it really best to use one language for both use cases? ¹And additionally for whether those project would eliminate such code if rewritten in Swift.
- pjmlp 3y ago
  Apple's security bulletins for one.

happytoexplain 3y ago

>yeah Objective-C is not memory safe but no seasoned programmer would ever make those mistakes that Swift aims to solve here Wow, that's a hell of an assertion!

masklinn 3y ago
Perfect C programmers strike again. Good thing they’re around and memory safety is never a problem thanks to their seasoned work.
twoodfin 3y ago
Fortunately, Apple has a decade or more of crash telemetry that tells them exactly how often users hit such problems running code from “seasoned programmers”!

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

turdprincess 3y ago

[flagged]

lapcat 3y ago
> I think the reason why the "pro Obj C" lobby strikes such a nerve is that their personal preference is holding back the whole team. You appear to be complaining about some anecdotal experience of yours. Exactly how many different teams have you been on where this happened? It should be noted that the article author has been a lone developer since 2016 and hasn't belonged to or "held back" any teams during that time. In any case, rewriting existing, working code is usually a bad idea regardless of the language, so if that's what you were aiming for on your team, it wouldn't be surprising to meet resistance on that. > Objective C actively makes it harder to do such best practices Completely untrue.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- turdprincess 3y ago
  It is true though! Consider a simple example where you have two classes, with one depending on the other. As a best practice, I'd like to inject one class into the other's constructor, so I could do some unit testing. Here is the Swift code: class Dependency1 { } class Object1 { private let dependency: Dependency1 init(dependency: Dependency1 = Dependency1()) { self.dependency = dependency } } And the Objective C equivalent: @interface Dependency1 : NSObject @end @implementation Dependency1 @end @interface Object1 : NSObject - (instancetype)initWithDependency:(Dependency1 *)dependency; - (instancetype)init; @end @interface Object1() @property (nonatomic, strong, readonly) Dependency1 *dependency; @end @implementation Object1 - (instancetype)initWithDependency:(Dependency1 *)dependency { self = [super init]; if (self) { _dependency = dependecy; } return self; } - (instancetype)init { return [self initWithDependency:[[Dependency1 alloc] init]]; } @end Thats 9 lines of code in Swift and 31 lines of code in Objective C. If I have to type 3 times more code every time I want to break up big class into a few smaller ones, I am going to be much less likely to do it. In other words, the sheer verbosity of Objective C will make even the most disciplined developer start cutting corners to reduce effort, which ultimately leads to codebases which are messier, harder to test and less flexible. And finally, looking at the example above, is it really true that Objective C is easier to learn and understand than Swift? The code forces you to learn: * What is an NSObject? * How to create a private category on an class * What does "alloc init" do, and why is it different than "new"? * What is the difference between `self.dependency` and `_dependency`, and why does one let me change a "readonly" property? * Why would `super init` return nil, and what does that mean? For sure Swift also has its share of nuance, but I feel like the Objective C nuance is just baggage, while the Swift nuance opens the door to a richer feature set. [edited] updated code for correctness

danaris 3y ago

> absolutely. one can learn Objective-C in an afternoon if you know C ...See, that last part you toss off as if it's practically a given, but it's really not. Sure, when I was (and probably you were) first going to CS classes, being taught C was pretty much the standard thing. But that's much less true now, from all I've seen. And why not? 20 years ago, it was much, much more likely that if you were a programmer, you were going to be working with C code at some point. Nowadays, you can easily have full mastery in a dozen different languages, all of which are in widespread demand, and never touch C. (Or C++. Or C#. Or Objective-C.) Personally, where I am at this point in my career? If I wanted to write a small utility program that runs natively on macOS, I'd pick Swift over C 10 times out of 10. I'm roughly equally familiar with both of them (which is "moderately"), and I know enough about the pitfalls of C to know that I don't want to deal with them, and Swift handles almost all of the frustration of memory management for me. Plus, there's a single authoritative source for information about Swift for when I run into something I'm unfamiliar with, forgot, or got confused about. If I try the same in C there's literally thousands of different sources, of varying authority, across every major and minor platform that's ever existed, and every version of C. It's fantastic that there's all that information out there, don't get me wrong, but when I'm trying to write a small utility to solve a specific problem, every time I run into something that's talking about the wrong C version, or the wrong platform, or just plain has bad information, is going to add one more bit of frustration that's likely to make me quit trying. Yes, Apple's documentation is imperfect—but I always know that it is there, acting as a single authority for the language.