That might be a bit optimistic. Right now there isn't any Swift info out there for people who do not already code in Objective-C. Just following the examples in the iBook isn't going to get you very far without a background in Objective-C. You still need all the libraries and frameworks and know how to use them which the Swift iBook doesn't explain. If you are planning to write the entire app in Swift without that background you are going to have to wait until someone offers a beginner to advanced complete Swift tutorial. If you wanted to jump right in now your best bet is to learn Object-C because it will be quite a while before a pure Swift implementation exists. If you look at the Lister example app on dev, it is still full of Object-C libraries and frameworks.
There is are some really great Obj-C tutorials on Lynda. That is what I used to get up to speed. Not free, but reasonable. I always maintain an annual subscription there and can highly recommend all their tutorials. Fantastic instructors.
I have spent several years struggling to learn Obj-C and write Cocoa and Cocoa Touch apps so I'm not coming in without prior knowledge, but I do get tripped up easily with the complex, repetitive and seemingly redundant syntax of Obj-C. I understand the logic of the code and how to use the Xcode IDE so I'm hoping Swift will help me cut the fat that I constantly choke on when trying to write apps.
I have spent several years struggling to learn Obj-C and write Cocoa and Cocoa Touch apps so I'm not coming in without prior knowledge, but I do get tripped up easily with the complex, repetitive and seemingly redundant syntax of Obj-C. I understand the logic of the code and how to use the Xcode IDE so I'm hoping Swift will help me cut the fat that I constantly choke on when trying to write apps.
I know what you mean nevertheless, that same legacy coding style is still present in all the frameworks so although Swift offers some greatly simplified scripting like syntax the real meat of an Xcode app is coming from the frameworks. Sure you can write an app without the frameworks but that is reinventing the wheel. As of now you still need the 1000's of methods in NSObject.
I know what you mean nevertheless, that same legacy coding style is still present in all the frameworks so although Swift offers some greatly simplified scripting like syntax the real meat of an Xcode app is coming from the frameworks. Sure you can write an app without the frameworks but that is reinventing the wheel. As of now you still need the 1000's of methods in NSObject.
But it's reduced and that's a huge benefit, not to mention the gains from reduced errors and other things that can kill your progress as you have to hunt down a single issue in a sea of shitty syntax. This is a huge improvement. Next year I expect they will be have pretty much Swift-based sessions and a lot more changes to make the frameworks and APIs easier.
let myTableView: UITableView = UITableView(frame: CGRectZero, style: .Grouped)
Don't you still have to write initialization code for that "let"? It is not automatic in Swift. I'm pretty sure that is Obj-C shorthand not Swift shorthand.
You still have to write initialization code for that "let".
Sure, this is still writing code. It sounds like you'd only be happy if the code wrote itself from a thought you had.
I don't think Apple made any comment that it was going to be magic, just that Swift will reduce time and effort from the amount of code (in most cases) to reducing bugs and making it generally safer.
The readability is world's better without the extreme repetition, excessive '@' symbols and brackets, but my favorite is the inclusion of values in strings.
You know, i don't mean the material. Okay the anode aluminium is good, but they can do something new, not again these 2 places on the top and the bottom of the rear side. Anyway i hope Tim Cook finally keep his 2013 promise and ll see at last all these "amazing new products" this fall.
Sure, this is still writing code. It sounds like you'd only be happy if the code wrote itself from a thought you had.
No I'm all in on Swift, I just don't have enough info on how it is going to work during transition or how one gets by without being familiar with the NS references. All I'm saying about "init", is that code you mentioned is not substantially shorter because you still have to initialize it somewhere else.
Quote:
Originally Posted by SolipsismX
Sure, this is still writing code. It sounds like you'd only be happy if the code wrote itself from a thought you had.
The readability is world's better without the extreme repetition, excessive '@' symbols and brackets, but my favorite is the inclusion of values in strings.
Code:
println("I picked \(number) \(fruit).")
NSLog(@"I picked %i %@.", number, fruit);
The Swift version is probably more readable from a concatenation perceptive but it isn't any shorter.
No I'm all in on Swift, I just don't have enough info on how it is going to work during transition or how one gets by without being familiar with the NS references. All I'm saying about "init", is that code you mentioned is not substantially shorter because you still have to initialize it somewhere else.
The Swift version is probably more readable from a concatenation perceptive but it isn't any shorter.
In that example you have still less characters — 41 for Obj-C v 39 for Swift, which won't always be the case — but shorter also refers to various time elements involved. Having to use the @ symbol constantly (there wasn't an example of excessive brackets here), and trying to read the code and figure out what's going on will be huge time savers in both learning to use the code as well as others coming into project and trying to get up to speed. Again, there is a lot more than be done and I'm sure will be done as Swift matures but this is a great start.
In that example you have still less characters — 41 for Obj-C v 39 for Swift, which won't always be the case — but shorter also refers to various time elements involved. Having to use the @ symbol constantly (there wasn't an example of excessive brackets here), and trying to read the code and figure out what's going on will be huge time savers in both learning to use the code as well as others coming into project and trying to get up to speed. Again, there is a lot more than be done and I'm sure will be done as Swift matures but this is a great start.
I don't disagree. I am just making a point that programming with Swift without a working knowledge of Obj-C is not all that easy right now because there are limited examples or documentation available. Programming is programming. I've been through a few different languages over the past couple decades. I was never, and still not, a huge fan of Obj-C, but if you want to write iOS apps that is what we use. In many ways it is better than pure C. NeXt really took the high road when they forked C. Java and C++/C# broke all compatibility with C and Swift is staying on that course by leveraging the compiler functionality to remain binary compatible even though the language is not.
With respect to the code examples: the placeholder replacement style of Obj-C comes directly from traditional C and Regular Expression syntax which is rather nerdy so I see your point, however I still think Swift's supplanting of Obj-C is not going to happen overnight. It will probably be a mash-up for a number of years. As I mentioned earlier, go look at what Apple is offering as an example of a Swift app on dev. It looks a lot like Obj-C to me.
...however I still think Swift's supplanting of Obj-C is not going to happen overnight. It will probably be a mash-up for a number of years.
Sure. I bet a decade from now there will still be code that need the 'NS' prefix, but it's a great start and not one that anyone was expecting. And frankly, anything that will reduce time and effort, even if just a little right now is a big deal to me.
I think it is worth mentioning that the @ signs are a signal to the compiler that what follows is Obj-C code, not traditional C code. Swift inherits its abbreviated syntax to the fact that the compiler engineers figured out a way to recognize , C, Obj-C and Swift code automatically thus the shorthand of Swift can be used sans semicolons, etc. The same type of shorthand simplification has been ongoing within Obj-C itself, as well, over the last couple of versions of Xcode/LLVM, just not as dramatically as with the announcement of Swift.
Swift is new. I have not tested it at all. One thing I question about the above code is how do the bounds check work with a Swift array. If I asked for the value of names{101] , what would I get back? I know what the answer is in NSArray.
I think it is worth mentioning that the @ signs are a signal to the compiler that what follows is Obj-C code, not traditional C code. Swift inherits its abbreviated syntax to the fact that the compiler engineers figured out a way to recognize , C, Obj-C and Swift code automatically thus the shorthand of Swift can be used sans semicolons, etc. The same type of shorthand simplification has been ongoing within Obj-C itself, as well, over the last couple of versions of Xcode/LLMV, just not as dramatically as with the announcement of Swift.
Sure, but that was a huge annoyance for me when trying to learning Obj-C and also attempting to write it today. Besides being visually unappealing I find it easy to omit an @ not catch it right away.
Personally, I wish Swift did even more by realizing that Tom, Dick, and Harry are single word strings and allowing me to omit the quotes unless it's required. For example, let me use...
let names = [Tom, Dick, Harry]
...or add the quotes if the string will have a space...
Swift is new. I have not tested it at all. One thing I question about the above code is how do the bounds check work with a Swift array. If I asked for the value of names{101] , what would I get back? I know what the answer is in NSArray.
As I understand it, the price of iphone 5 iphone 6 will be more expensive around $ 100, I'm waiting for an official date iphone 6 sold in the market. Hopefully utility features will not disappoint me.
True tone is not being abandoned. Notice that the hole for the flash is BIGGER than the standard single tone LEDs? They probably have some new design that embed both into the larger circle.
Personally, I wish Swift did even more by realizing that Tom, Dick, and Harry are single word strings and allowing me to omit the quotes unless it's required. For example, let me use...
Code:
let names = [Tom, Dick, Harry]
...or add the quotes if the string will have a space...
Code:
let names = [Tom, "Dick Applebaum", Harry]
Sure, Swift is smart but it isn't a mind reader. What if one of your array values is something that has either a constant, variable, keyword or method name already associated with it. You need uniformity and non ambiguous syntax. a string needs quotes, ALWAYS!
Comments
I have spent several years struggling to learn Obj-C and write Cocoa and Cocoa Touch apps so I'm not coming in without prior knowledge, but I do get tripped up easily with the complex, repetitive and seemingly redundant syntax of Obj-C. I understand the logic of the code and how to use the Xcode IDE so I'm hoping Swift will help me cut the fat that I constantly choke on when trying to write apps.
I know what you mean nevertheless, that same legacy coding style is still present in all the frameworks so although Swift offers some greatly simplified scripting like syntax the real meat of an Xcode app is coming from the frameworks. Sure you can write an app without the frameworks but that is reinventing the wheel. As of now you still need the 1000's of methods in NSObject.
But it's reduced and that's a huge benefit, not to mention the gains from reduced errors and other things that can kill your progress as you have to hunt down a single issue in a sea of shitty syntax. This is a huge improvement. Next year I expect they will be have pretty much Swift-based sessions and a lot more changes to make the frameworks and APIs easier.
Objective-C:
Swift:
edit: http://nshipster.com/ios8/
Swift:
Don't you still have to write initialization code for that "let"? It is not automatic in Swift. I'm pretty sure that is Obj-C shorthand not Swift shorthand.
They can only change the outer part but so much.
Sure, this is still writing code. It sounds like you'd only be happy if the code wrote itself from a thought you had.
I don't think Apple made any comment that it was going to be magic, just that Swift will reduce time and effort from the amount of code (in most cases) to reducing bugs and making it generally safer.
The readability is world's better without the extreme repetition, excessive '@' symbols and brackets, but my favorite is the inclusion of values in strings.
println("I picked \(number) \(fruit).")Sure, this is still writing code. It sounds like you'd only be happy if the code wrote itself from a thought you had.
No I'm all in on Swift, I just don't have enough info on how it is going to work during transition or how one gets by without being familiar with the NS references. All I'm saying about "init", is that code you mentioned is not substantially shorter because you still have to initialize it somewhere else.
Sure, this is still writing code. It sounds like you'd only be happy if the code wrote itself from a thought you had.
The readability is world's better without the extreme repetition, excessive '@' symbols and brackets, but my favorite is the inclusion of values in strings.
The Swift version is probably more readable from a concatenation perceptive but it isn't any shorter.
In that example you have still less characters — 41 for Obj-C v 39 for Swift, which won't always be the case — but shorter also refers to various time elements involved. Having to use the @ symbol constantly (there wasn't an example of excessive brackets here), and trying to read the code and figure out what's going on will be huge time savers in both learning to use the code as well as others coming into project and trying to get up to speed. Again, there is a lot more than be done and I'm sure will be done as Swift matures but this is a great start.
edit:
In that example you have still less characters — 41 for Obj-C v 39 for Swift, which won't always be the case — but shorter also refers to various time elements involved. Having to use the @ symbol constantly (there wasn't an example of excessive brackets here), and trying to read the code and figure out what's going on will be huge time savers in both learning to use the code as well as others coming into project and trying to get up to speed. Again, there is a lot more than be done and I'm sure will be done as Swift matures but this is a great start.
I don't disagree. I am just making a point that programming with Swift without a working knowledge of Obj-C is not all that easy right now because there are limited examples or documentation available. Programming is programming. I've been through a few different languages over the past couple decades. I was never, and still not, a huge fan of Obj-C, but if you want to write iOS apps that is what we use. In many ways it is better than pure C. NeXt really took the high road when they forked C. Java and C++/C# broke all compatibility with C and Swift is staying on that course by leveraging the compiler functionality to remain binary compatible even though the language is not.
With respect to the code examples: the placeholder replacement style of Obj-C comes directly from traditional C and Regular Expression syntax which is rather nerdy so I see your point, however I still think Swift's supplanting of Obj-C is not going to happen overnight. It will probably be a mash-up for a number of years. As I mentioned earlier, go look at what Apple is offering as an example of a Swift app on dev. It looks a lot like Obj-C to me.
Try looking at the pictures before spewing lies instead, okay champ?
Sure. I bet a decade from now there will still be code that need the 'NS' prefix, but it's a great start and not one that anyone was expecting. And frankly, anything that will reduce time and effort, even if just a little right now is a big deal to me.
I think it is worth mentioning that the @ signs are a signal to the compiler that what follows is Obj-C code, not traditional C code. Swift inherits its abbreviated syntax to the fact that the compiler engineers figured out a way to recognize , C, Obj-C and Swift code automatically thus the shorthand of Swift can be used sans semicolons, etc. The same type of shorthand simplification has been ongoing within Obj-C itself, as well, over the last couple of versions of Xcode/LLVM, just not as dramatically as with the announcement of Swift.
Swift is new. I have not tested it at all. One thing I question about the above code is how do the bounds check work with a Swift array. If I asked for the value of names{101] , what would I get back? I know what the answer is in NSArray.
Sure, but that was a huge annoyance for me when trying to learning Obj-C and also attempting to write it today. Besides being visually unappealing I find it easy to omit an @ not catch it right away.
Personally, I wish Swift did even more by realizing that Tom, Dick, and Harry are single word strings and allowing me to omit the quotes unless it's required. For example, let me use...
...or add the quotes if the string will have a space...
You mean something like this?
As I understand it, the price of iphone 5 iphone 6 will be more expensive around $ 100, I'm waiting for an official date iphone 6 sold in the market. Hopefully utility features will not disappoint me.
...or add the quotes if the string will have a space...
Sure, Swift is smart but it isn't a mind reader. What if one of your array values is something that has either a constant, variable, keyword or method name already associated with it. You need uniformity and non ambiguous syntax. a string needs quotes, ALWAYS!