4 ms·

I find it hard to believe that anybody is faster coding in objc than swift, if you control for garbage code. It was easy to quickly write buggy messes in objc -

I find it hard to believe that anybody is faster coding in objc than swift, if you control for garbage code. It was easy to quickly write buggy messes in objc - swift made that a lot harder, and is also a much more ergonomic and productive language in my experience. I feel like there has to be some other factors at play if that’s the results you’re seeing. (Source: I’ve been doing objc since 2009, and swift since version 1.0)

ardit33 5y ago
A well jelled team, with senior engineers can be much more productive with Objective C. But for beginners, swift looks less intimidating due to its syntax familiarity. The language pitfalls become apparent as you dive into it. Perhaps that’s why swift in ML and other areas failed. People don’t like the language. In iOS you are forced to use it. I hope the swift team does some hard thinking and start slashing features and make it Simpler. What we got is something more complex than even Java. This is the same reason that Scala didn't take off (even though some people like it).
- jshier 5y ago
  This just isn't true. Given equal familiarity, Swift will be vastly more productive at any skill level. Of course you can always tunnel deeper into more sophisticated solutions using Swift, since Obj-C lacks most of its capabilities, but that's hardly an equal comparison.
  - novok 5y ago
    I have a lot of experience in both languages, and TBH it's just not true. I'm less productive in swift in many ways, mostly because of it's slow build and indexing times. It's infuriating. You are still coding against the same UIKit and other apple libraries in both. SwiftUI has a chance to make it better, but it's incomplete and has bugs/gotchas that make it not as productive as UIKit when you run into that, which is pretty easy. But in an imaginary world where we got ObjectiveSwift instead, SwiftUI could have existed there and given the same productivity benefits. Binary sizes ballooned because of the language. Binaries were significantly smaller in equivalent Obj-C programs than the swift ones, even when the standard swift library was finally baked into the OS.
    - jshier 5y ago
      It would be impossible to evolve Obj-C to add most of Swift's capabilities unless you drop binary and source back compatibility. At that point it's just another new language and you've lost the things you say made Obj-C simpler. I have a hard time believing any engineer is productivity bound by Swift's build times and especially indexing times, since indexing doesn't affect your ability actually write code. Typically developer productivity is bound by thinking of an appropriate solution to a problem and expressing that solution in a language. Given how much easier that expression is in Swift, especially if you spend a bit of time optimizing the language to your problem, the build time becomes rather incidental. Add to that Swift's ability to catch far more issues at build time and its language features and the Obj-C solution falls further and further behind. Even if your Obj-C solution builds faster it will likely be an inferior solution anyway.
      - novok 5y ago
        I see you haven't worked in a swift code base that is more than a few engineers. Work in a project that is 20-80+ engineers and you slam into these issues very quickly. Last time I checked the inflection point starts around 100k lines of code. Also 'thinking' of solutions often involves writing something and then trying it out in a build-edit-run cycle, and then integrating your thing into a larger app context, which also involves many build-edit-run cycles. Most people do not think of their solution in whole cloth in their head other than in a broad strokes manner and then start writing code. This means indexing and building matters greatly for actual productivity. Indexing issues means your ide is not auto completing, click to definition doesn't work, and in the past, even syntax highlighting failed. Also when you have some half formed code, a lot of indexing functions start breaking in an annoying way, while I don't really recall this behavior in Objective-C code bases. In practice I've found swift being 'able to catch issues more' is mostly strict nullability, better array / dictionary strictness and enums, which would actually be relatively simple to implement in an extended ObjectiveSwift. Strict generics would be more work, but you can add it to the language also as a version update. Dart showed how it's possible to add big changes like strict nullability to a language with their dart v1 -> v2 update. Objective-C could have gone down that path instead.
  - ardit33 5y ago
    You are talking out of your arse… and so am I. Unless we have well researched data, it is just a opinion. My opinion and experience is definitely different than yours, and I have seen that objective c leads to more productive teams if they are mostly senior people. (With a couple of libraries (just some helper categories on strings and arrays) and some sparse macros objective c becomes a very productive language. But it takes a senior team to do that well). Meanwhile with swift you feel you have to please the compiler at every! step? And it really doesn’t lead to much safer language anyway (swift bugs are different) and you feel you have to fight the compiler in every way. Objective c is less fuzzy, and while it lets you do dumb/fast things (especially important during prototyping) it gives you a clear ‘you are doing x wrong’ warning which gives you the best of both worlds Fast prototyping when you need it, and safety when you need to ship (you can have a production build fail on just warnings)
    - jshier 5y ago
      These are the same stupid points people brought up when Swift was first released. I used to believe it too. Then I actually used the language and integrated it into existing codebases. The jump in quality and performance was notable and immediate. What you state here about both languages doesn't match any experience I've ever had or seen from other teams.
    - novok 5y ago
      Nullability isn't that big of an issue in practice. Every call in objective-c is equivalent to a variable?.thing call anyway, and in swift codebases most things become non-null fairly quick. It's probably the top feature of swift for me, which is ironic because it's relatively cheap (in compile time) to implement compared to many other things swift has. And if you're doing nullability, you might as well add ADT enums, since that is usually how it's implemented.
  - diskzero 5y ago
    I have a rather complex application that is a mix of C++, ObjC and Swift. I humbly consider myself an expert in all three languages and worked on AppKit while employed at Apple. Perhaps Swift is slightly more accessible when you begin development. If you aren't familiar with ObjC syntax, Swift my look more familiar at first, but syntax quickly becomes familiar. When you mention more sophisticated solutions using Swift, I am not sure what capabilities Obj-C lacks that would hamper it. Are you referring to the functional parts of the Swift language? Combine?
  - gurkendoktor 5y ago
    Lacking capabilities also means fewer decisions. If you want to model something in ObjC, it's a class, full stop. In Swift you have the choice between classes and structs. There are generally more degrees of freedom. Just observe how much the iOS community talks about Swift patterns. Objective-C was more like Go, in that you accept your fate, keep things simple, and write some boilerplate code here and there. It seems to drive some people crazy, but it also avoids C++-style meta discussions about language features. Whether this trade-off increases or decreases productivity depends on your team.
  - Apocryphon 5y ago
    You’re correct, the post isn’t completely true- Swift syntax isn’t more familiar to beginners than ObjC is, because in their pursuit to take out the C, they also replaced several of the long-standing C patterns such as lack of prefix/postfix operators, standard for loops, parameter name and type ordering.
wlesieutre 5y ago
They're not saying developing in Swift is faster than OjbC, they're saying Java for Android was slower than ObjC for iOS, and now Kotlin for Android is faster than Swift for iOS. Both teams move faster in the new languages, but the Android team moves more faster.
occamrazor 5y ago
I think GP is saying that ObjC is faster than Java for development, but Kotlin is faster than Swift. No comparison between ObjC and Swift.
w0mbat 5y ago
I code several times faster in ObjC than Swift, and this is after writing two released Swift apps. Just a simple thing like writing string to num to string that works in different bases is a nightmare in Swift.
- bsaul 5y ago
  the swift string / substring api is still incredibly convoluted (or poorly documented, or both), but my feeling is that it's because it does a lot.
- fingerlocks 5y ago
  Hope this eases your nightmares: String( Int("ff", radix: 16), radix: 10)
  - w0mbat 5y ago
    Actually that simplistic approach crashes if the value of the string goes out of range or the string contains invalid characters for the base. For commercial quality code dealing with user input you need to do your own checking char by char and assemble the result using multipliedReportingOverflow and addingReportingOverflow. The char by char processing is a pain given you can't really take the value of a Character the way you can in other languages and end up having to feed them through a map. In the end my correct bulletproof implementation is only about a page of code, but it was awkward to write.
    - fingerlocks 5y ago
      You yourself said "Just a simple thing like...", so I thought you were looking for a simple solution. Your complaints are no different if you were using strtol/atoi, so what's unique about swift here? Are you expecting "value of character" to be in some range that's not within 0..<radix? I have also written commercial code that does this, and I'm just going to paste it here because it's actually not that much code. Sums two strings of arbitrary length, well outside of the overflow limit, for the given base. Returns the sum as string in the base given. No mapping or overflow checks needed. Invalid characters for the base are treated as 0, but you can easily modify it to throw an error or whatever. func sumStrings(_ left: String, _ right: String, _ radix: Int) -> String { var left = Array(left) var right = Array(right) var carry = 0 var result: String = "" while left.isEmpty == false || right.isEmpty == false { let charLeft = left.popLast() ?? "0" let charRight = right.popLast() ?? "0" let intLeft = Int("\(charLeft)", radix: radix) ?? 0 let intRight = Int("\(charRight)", radix: radix) ?? 0 carry += (intLeft + intRight) result = String(carry % radix, radix: radix, uppercase: false) + result carry /= radix } if carry % radix != 0 { result = String(carry % radix, radix: radix, uppercase: false) + result } return result }
iainmerrick 5y ago
I prefer Swift on balance, but there’s still a lot I miss from Obj-C. For one thing, Obj-C compiles much faster. Swift compilation is ludicrously slow.
- bsaul 5y ago
  Recently had to update an old objc ios codebase, and the first time i built i thought something went wrong, because it completed way too fast. Swift compilation is an order of magnitude too slow, especially in incremental built, compared to objc.
- Apocryphon 5y ago
  Debugging with LLDB often feels broken or incomplete in Swift than with Objective-C, as well.

ardit33 5y ago

A well jelled team, with senior engineers can be much more productive with Objective C. But for beginners, swift looks less intimidating due to its syntax familiarity. The language pitfalls become apparent as you dive into it. Perhaps that’s why swift in ML and other areas failed. People don’t like the language. In iOS you are forced to use it. I hope the swift team does some hard thinking and start slashing features and make it Simpler. What we got is something more complex than even Java. This is the same reason that Scala didn't take off (even though some people like it).

jshier 5y ago
This just isn't true. Given equal familiarity, Swift will be vastly more productive at any skill level. Of course you can always tunnel deeper into more sophisticated solutions using Swift, since Obj-C lacks most of its capabilities, but that's hardly an equal comparison.
- novok 5y ago
  I have a lot of experience in both languages, and TBH it's just not true. I'm less productive in swift in many ways, mostly because of it's slow build and indexing times. It's infuriating. You are still coding against the same UIKit and other apple libraries in both. SwiftUI has a chance to make it better, but it's incomplete and has bugs/gotchas that make it not as productive as UIKit when you run into that, which is pretty easy. But in an imaginary world where we got ObjectiveSwift instead, SwiftUI could have existed there and given the same productivity benefits. Binary sizes ballooned because of the language. Binaries were significantly smaller in equivalent Obj-C programs than the swift ones, even when the standard swift library was finally baked into the OS.
  - jshier 5y ago
    It would be impossible to evolve Obj-C to add most of Swift's capabilities unless you drop binary and source back compatibility. At that point it's just another new language and you've lost the things you say made Obj-C simpler. I have a hard time believing any engineer is productivity bound by Swift's build times and especially indexing times, since indexing doesn't affect your ability actually write code. Typically developer productivity is bound by thinking of an appropriate solution to a problem and expressing that solution in a language. Given how much easier that expression is in Swift, especially if you spend a bit of time optimizing the language to your problem, the build time becomes rather incidental. Add to that Swift's ability to catch far more issues at build time and its language features and the Obj-C solution falls further and further behind. Even if your Obj-C solution builds faster it will likely be an inferior solution anyway.
    - novok 5y ago
      I see you haven't worked in a swift code base that is more than a few engineers. Work in a project that is 20-80+ engineers and you slam into these issues very quickly. Last time I checked the inflection point starts around 100k lines of code. Also 'thinking' of solutions often involves writing something and then trying it out in a build-edit-run cycle, and then integrating your thing into a larger app context, which also involves many build-edit-run cycles. Most people do not think of their solution in whole cloth in their head other than in a broad strokes manner and then start writing code. This means indexing and building matters greatly for actual productivity. Indexing issues means your ide is not auto completing, click to definition doesn't work, and in the past, even syntax highlighting failed. Also when you have some half formed code, a lot of indexing functions start breaking in an annoying way, while I don't really recall this behavior in Objective-C code bases. In practice I've found swift being 'able to catch issues more' is mostly strict nullability, better array / dictionary strictness and enums, which would actually be relatively simple to implement in an extended ObjectiveSwift. Strict generics would be more work, but you can add it to the language also as a version update. Dart showed how it's possible to add big changes like strict nullability to a language with their dart v1 -> v2 update. Objective-C could have gone down that path instead.
- ardit33 5y ago
  You are talking out of your arse… and so am I. Unless we have well researched data, it is just a opinion. My opinion and experience is definitely different than yours, and I have seen that objective c leads to more productive teams if they are mostly senior people. (With a couple of libraries (just some helper categories on strings and arrays) and some sparse macros objective c becomes a very productive language. But it takes a senior team to do that well). Meanwhile with swift you feel you have to please the compiler at every! step? And it really doesn’t lead to much safer language anyway (swift bugs are different) and you feel you have to fight the compiler in every way. Objective c is less fuzzy, and while it lets you do dumb/fast things (especially important during prototyping) it gives you a clear ‘you are doing x wrong’ warning which gives you the best of both worlds Fast prototyping when you need it, and safety when you need to ship (you can have a production build fail on just warnings)
  - jshier 5y ago
    These are the same stupid points people brought up when Swift was first released. I used to believe it too. Then I actually used the language and integrated it into existing codebases. The jump in quality and performance was notable and immediate. What you state here about both languages doesn't match any experience I've ever had or seen from other teams.
  - novok 5y ago
    Nullability isn't that big of an issue in practice. Every call in objective-c is equivalent to a variable?.thing call anyway, and in swift codebases most things become non-null fairly quick. It's probably the top feature of swift for me, which is ironic because it's relatively cheap (in compile time) to implement compared to many other things swift has. And if you're doing nullability, you might as well add ADT enums, since that is usually how it's implemented.
- diskzero 5y ago
  I have a rather complex application that is a mix of C++, ObjC and Swift. I humbly consider myself an expert in all three languages and worked on AppKit while employed at Apple. Perhaps Swift is slightly more accessible when you begin development. If you aren't familiar with ObjC syntax, Swift my look more familiar at first, but syntax quickly becomes familiar. When you mention more sophisticated solutions using Swift, I am not sure what capabilities Obj-C lacks that would hamper it. Are you referring to the functional parts of the Swift language? Combine?
- gurkendoktor 5y ago
  Lacking capabilities also means fewer decisions. If you want to model something in ObjC, it's a class, full stop. In Swift you have the choice between classes and structs. There are generally more degrees of freedom. Just observe how much the iOS community talks about Swift patterns. Objective-C was more like Go, in that you accept your fate, keep things simple, and write some boilerplate code here and there. It seems to drive some people crazy, but it also avoids C++-style meta discussions about language features. Whether this trade-off increases or decreases productivity depends on your team.
- Apocryphon 5y ago
  You’re correct, the post isn’t completely true- Swift syntax isn’t more familiar to beginners than ObjC is, because in their pursuit to take out the C, they also replaced several of the long-standing C patterns such as lack of prefix/postfix operators, standard for loops, parameter name and type ordering.

wlesieutre 5y ago

They're not saying developing in Swift is faster than OjbC, they're saying Java for Android was slower than ObjC for iOS, and now Kotlin for Android is faster than Swift for iOS. Both teams move faster in the new languages, but the Android team moves more faster.

occamrazor 5y ago

I think GP is saying that ObjC is faster than Java for development, but Kotlin is faster than Swift. No comparison between ObjC and Swift.

w0mbat 5y ago

I code several times faster in ObjC than Swift, and this is after writing two released Swift apps. Just a simple thing like writing string to num to string that works in different bases is a nightmare in Swift.

bsaul 5y ago
the swift string / substring api is still incredibly convoluted (or poorly documented, or both), but my feeling is that it's because it does a lot.
fingerlocks 5y ago
Hope this eases your nightmares: String( Int("ff", radix: 16), radix: 10)
- w0mbat 5y ago
  Actually that simplistic approach crashes if the value of the string goes out of range or the string contains invalid characters for the base. For commercial quality code dealing with user input you need to do your own checking char by char and assemble the result using multipliedReportingOverflow and addingReportingOverflow. The char by char processing is a pain given you can't really take the value of a Character the way you can in other languages and end up having to feed them through a map. In the end my correct bulletproof implementation is only about a page of code, but it was awkward to write.
  - fingerlocks 5y ago
    You yourself said "Just a simple thing like...", so I thought you were looking for a simple solution. Your complaints are no different if you were using strtol/atoi, so what's unique about swift here? Are you expecting "value of character" to be in some range that's not within 0..<radix? I have also written commercial code that does this, and I'm just going to paste it here because it's actually not that much code. Sums two strings of arbitrary length, well outside of the overflow limit, for the given base. Returns the sum as string in the base given. No mapping or overflow checks needed. Invalid characters for the base are treated as 0, but you can easily modify it to throw an error or whatever. func sumStrings(_ left: String, _ right: String, _ radix: Int) -> String { var left = Array(left) var right = Array(right) var carry = 0 var result: String = "" while left.isEmpty == false || right.isEmpty == false { let charLeft = left.popLast() ?? "0" let charRight = right.popLast() ?? "0" let intLeft = Int("\(charLeft)", radix: radix) ?? 0 let intRight = Int("\(charRight)", radix: radix) ?? 0 carry += (intLeft + intRight) result = String(carry % radix, radix: radix, uppercase: false) + result carry /= radix } if carry % radix != 0 { result = String(carry % radix, radix: radix, uppercase: false) + result } return result }

iainmerrick 5y ago

I prefer Swift on balance, but there’s still a lot I miss from Obj-C. For one thing, Obj-C compiles much faster. Swift compilation is ludicrously slow.

bsaul 5y ago
Recently had to update an old objc ios codebase, and the first time i built i thought something went wrong, because it completed way too fast. Swift compilation is an order of magnitude too slow, especially in incremental built, compared to objc.
Apocryphon 5y ago
Debugging with LLDB often feels broken or incomplete in Swift than with Objective-C, as well.