3 ms·

So is this actually a lot easier to use than Objective-C?

jakejake 12y ago
Not sure if that was meant as sarcasm, but I'll take it as a real question..! Being a mediocre Objective C programmer myself, I really like the look of Swift. The difficulty of programming for iOS (or any platform) is partly the language syntax and partly the library/frameworks. I think Swift will help greatly with the language, but there is still a lot to learn as far as the UI kit and such. Swift doesn't really change the fundamental way the libraries work - the syntax is just cleaner (as a matter of opinion, I suppose). In addition to looking a lot more familiar and certain functions being much more readable, apparently using Swift will be safer in regards to memory issues too, which is comforting for people like me who are not guru-level with managing memory. I'm personally looking forward to using it starting this week.
josephlord 12y ago
Yes...with caveats. It looks really nice, simpler syntax for the most part but the type system seems much stronger and I think those not used to functional languages/type theory may struggle to get complex things running straight away. But when it does run it should be a lot more robust (so I think it is a good change).
- gress 12y ago
  I think this is false. Things that are simple in Objective-C will be simpler in Swift, with better feedback from the compiler. Things that are complex in objective-c will also be simpler and more robust in swift. There is a kind of complex coding using generics and the type system that would be harder for an inexperienced developer to understand, but that seems to me to be strictly additive to Objective-C.
  - josephlord 12y ago
    I think that Swift is better and will overall be easier (I started may comment with a "Yes") BUT there will be a fair few casts and use of optional values needed when integrating anything with the general existing libraries that would cause a beginner programmer difficulties. Example 1 - implementing a protocol (AVAudioPlayerDelagate) You get errors unless you also implement NSObjectProtocol. The easiest way to do that is to also inherit from NSObject. Example 2 - typed arrays/dictionaries You can shove any NSObject in an NSArray or NSDictionary but the Swift arrays are typed (a good thing) but one that may make some things more difficult for beginners. I suspect it is the tip of the iceberg of type related complication. This is a worthwhile tradeoff for greater safety and despite this Swift will still be easier to use overall that ObjC in my view. It may also take a while for the documentation particularly across the internet to catch up with the quantity of examples for Obj C but this is only an interim issue.
    - gress 12y ago
      I think you're wrong about both of these. Yes, it's true that you need to inherit from NSObject in some cases, but Cocoa is complex anyway, and this is not added complexity, so it's not different from objective-c in this regard. For #2 you are flat out incorrect. Swift arrays can be containers of AnyType, in which case they interoperate perfectly with NSArray, and this is the default behavior when working with Cocoa. Your fear about type related complexity being a real issue seems not to be justified by your examples. Compared to dealing with the C based fragility of Objective-C, Swift is simply better for anything that it can do.
      - josephlord 12y ago
        I like Swift and my overall answer is still yes that it is easier to learn than Objective C and that having to deal with types is worthwhile for the safety it brings and increased chance that it will do the right thing when it does run but it is still a barrier to a limited degree. I remember initially struggling with the stuff in ML in the first year at university, I got it but I and many others had an initial struggle. I think that at least for beginners and maybe those coming from runtime duck typed languages Python, PHP, Ruby etc. it will be more of a barrier than you think. For #1 in Objective C you inherit from NSObject (or a subclass thereof) for every class anyway so it is in all the examples and it isn't something that you need to do especially for a protocol. For #2 yes of course you can have an array of a generic type but firstly you need to understand enough about the type system to create your array in that form and secondly what you get out will <AnyType> objects rather than <id>'s which get automatically cast to whatever you assign them to. But I do like the idiom for downcasting using as?: if let movie = item as? Movie { println("Movie: '\(movie.name)', dir. \(movie.director)") } else if let song = item as? Song { println("Song: '\(song.name)', by \(song.artist)") } [0] Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/gb/jEUH0.l https://itun.es/gb/jEUH0.l
        gress 12y ago
        Yeah - the central point is that there aren't really caveats about Swift being simpler than objective-c. It's not perfect, but Objective-C has a much greater number of rough edges so is strictly harder for new users.

Not sure if that was meant as sarcasm, but I'll take it as a real question..! Being a mediocre Objective C programmer myself, I really like the look of Swift. The difficulty of programming for iOS (or any platform) is partly the language syntax and partly the library/frameworks. I think Swift will help greatly with the language, but there is still a lot to learn as far as the UI kit and such. Swift doesn't really change the fundamental way the libraries work - the syntax is just cleaner (as a matter of opinion, I suppose). In addition to looking a lot more familiar and certain functions being much more readable, apparently using Swift will be safer in regards to memory issues too, which is comforting for people like me who are not guru-level with managing memory. I'm personally looking forward to using it starting this week.

josephlord 12y ago

Yes...with caveats. It looks really nice, simpler syntax for the most part but the type system seems much stronger and I think those not used to functional languages/type theory may struggle to get complex things running straight away. But when it does run it should be a lot more robust (so I think it is a good change).

gress 12y ago
I think this is false. Things that are simple in Objective-C will be simpler in Swift, with better feedback from the compiler. Things that are complex in objective-c will also be simpler and more robust in swift. There is a kind of complex coding using generics and the type system that would be harder for an inexperienced developer to understand, but that seems to me to be strictly additive to Objective-C.
- josephlord 12y ago
  I think that Swift is better and will overall be easier (I started may comment with a "Yes") BUT there will be a fair few casts and use of optional values needed when integrating anything with the general existing libraries that would cause a beginner programmer difficulties. Example 1 - implementing a protocol (AVAudioPlayerDelagate) You get errors unless you also implement NSObjectProtocol. The easiest way to do that is to also inherit from NSObject. Example 2 - typed arrays/dictionaries You can shove any NSObject in an NSArray or NSDictionary but the Swift arrays are typed (a good thing) but one that may make some things more difficult for beginners. I suspect it is the tip of the iceberg of type related complication. This is a worthwhile tradeoff for greater safety and despite this Swift will still be easier to use overall that ObjC in my view. It may also take a while for the documentation particularly across the internet to catch up with the quantity of examples for Obj C but this is only an interim issue.
  - gress 12y ago
    I think you're wrong about both of these. Yes, it's true that you need to inherit from NSObject in some cases, but Cocoa is complex anyway, and this is not added complexity, so it's not different from objective-c in this regard. For #2 you are flat out incorrect. Swift arrays can be containers of AnyType, in which case they interoperate perfectly with NSArray, and this is the default behavior when working with Cocoa. Your fear about type related complexity being a real issue seems not to be justified by your examples. Compared to dealing with the C based fragility of Objective-C, Swift is simply better for anything that it can do.
    - josephlord 12y ago
      I like Swift and my overall answer is still yes that it is easier to learn than Objective C and that having to deal with types is worthwhile for the safety it brings and increased chance that it will do the right thing when it does run but it is still a barrier to a limited degree. I remember initially struggling with the stuff in ML in the first year at university, I got it but I and many others had an initial struggle. I think that at least for beginners and maybe those coming from runtime duck typed languages Python, PHP, Ruby etc. it will be more of a barrier than you think. For #1 in Objective C you inherit from NSObject (or a subclass thereof) for every class anyway so it is in all the examples and it isn't something that you need to do especially for a protocol. For #2 yes of course you can have an array of a generic type but firstly you need to understand enough about the type system to create your array in that form and secondly what you get out will <AnyType> objects rather than <id>'s which get automatically cast to whatever you assign them to. But I do like the idiom for downcasting using as?: if let movie = item as? Movie { println("Movie: '\(movie.name)', dir. \(movie.director)") } else if let song = item as? Song { println("Song: '\(song.name)', by \(song.artist)") } [0] Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/gb/jEUH0.l https://itun.es/gb/jEUH0.l
      - gress 12y ago
        Yeah - the central point is that there aren't really caveats about Swift being simpler than objective-c. It's not perfect, but Objective-C has a much greater number of rough edges so is strictly harder for new users.