You'll spend far more time getting to grips with Cocoa/Cocoa Touch.
Of course it is. It's certainly not a physical barrier. But psychological or not, other languages don't have a similar barrier.
Link: https://itunes.apple.com/us/book/the-swift-programming-langu...
Hope it helps.
In any case, here's a few things I learned about swift yesterday building this. Please note that I have about 4 hours swift experience, so feel free to correct anything I say that's wrong.
1. To make properties on a class you simply declare the variable on the class e.g.:
class GameScene: SKScene {
var bird = SKSpriteNode()
// ...
}
SKTexture* birdTexture1 = [SKTexture textureWithImageNamed:@"Bird1"];
var birdTexture1 = SKTexture(imageNamed: "Bird1")
var flap = SKAction.repeatActionForever(animation)
var spawn = SKAction.runBlock({() in self.spawnPipes()})
var quarter = UInt32( self.frame.size.height / 4 )
var y = arc4random() % quarter + quarter;
5. I use `var` everywhere and I'm pretty sure I should be using `let` a lot more. I haven't worked with Swift enough to have a strong intuition about when to use either.
I should also mention that my code is just converted from Matthias Gall's code [1].
I also want to put in a shameless plug that the point of making this was to advertise the "Making Games with Swift" class that auser and I are building. If you're interested, put in your email here: https://fullstackedu.com
I intend to redo this more fully with Playgrounds. I've been looking for a way to teach kids programming for a while now (if you recall, auser and I built Choc [2] a few months back). I think Playgrounds in Swift are finally the tool we've been waiting for.
[1] http://digitalbreed.com/2014/how-to-build-a-game-like-flappy...
[2] http://www.fullstack.io/choc/
EDIT: added choc
var spawn = SKAction.runBlock({() in self.spawnPipes()})
var spawn = SKAction.runBlock({self.spawnPipes()})
var spawn = SKAction.runBlock() {self.spawnPipes()}
var spawn = SKAction.runBlock {self.spawnPipes()}
I think you should type let everywhere, except when you cannot get away with it.
So, it is var when declaring a loop variable. Elsewhere you almost always can introduce a new name. So, instead of
X += 1
let newX = x + 1
If you find yourself creating a newerX, a newestX, etc. you may be better of with a var, but chances also are that you are better of writing your code differently (for example can you iterate over a constant array of values instead of doing x+=1 a few times? If your function needs to create 10+ Local variables, can you factor out a function?)
1. Strings, arrays and dictionaries are value types (like structs in C# - stored on stack, not on the heap) with special copying rules for arrays.
2. Custom operators - can be defined as a sequence of "/ = - + * % < > ! & | ^ . ~" characters and made prefix, infix or postfix. There is an example in the reference that defines a prefix operator "+++" for vectors
I'm quite impressed so far. Having been an Objective C and Ruby engineer, so far Swift seems to offer the best of both.
That said, OpenGL support doesn't appear to be finished yet.
* func, function, fun, defun fu, funct
* CamelCase vs snake_case
* whitespace, semicolon or comma usage
* var, int/integer/uint64/Integer/
* choice of (), {}, [] or better (){a[]}
* import/include/require, class/class, override, self vs this, new vs Class()
PS: next time you design a new language just make a random unique combination of the above.
That's my impression whenever I see a new programming language too. Why would someone switch to your language if the syntax is just the same boring old syntax they've been using in another language?
Use different syntax and naming for the things that are genuinely different about your language.
What I'm saying is that I sometimes get the impression that language designers randomly change up syntax just to make their language look different, and thus superficially more appealing to users. Just like any other kind of product.
Woof woof! I got one too. My view of Swift is: not a good enough reason not to continue using Lua for the same problem.
I'm not trying to be flippant and I understand that the named parameter format may throw some people for a loop, but I'm curious why it appears to be such a limiting factor in trying Objective-C.
I didn't build the collision detection yet just b/c I actually think it's more fun to play this way.
That said, we'll add it before too long.
If people really take to swift, it'll be interesting to see if that's because it creates a shift in programming style, or because people really are just afraid of small syntactical differences.
I would imagine that is very on the reasons for creating it.
I think a lot of the trouble people have with starting to develop apps for Apple platforms actually comes from trying to figure out the APIs and style, while at the same time battling against unfamiliar syntax. From the little I've seen, Swift doesn't change the first part of that very much.
I can see my AFNetworking code becoming much, much more readable now, without the need to @weakify/@strongify self on both sides of the block, but just add a blanket '[unowned self] in' inside the closure.
Apple's UI frameworks are all MVC based, which means multiple classes and apple specific UI terminology.
That reads a lot more sarcastic than it should have, but it's unfortunately true. Swift was announced in front of a room of people who needed to be convinced to start migrating from something they all know (ObjC) in favor of something new, so you have to win them over quick.
The language isn't tailored to it, but there are things it makes easy that are. If that makes any sense.
In Flappy Bird I used inline images, as in (define bird <the-bird-image-here> ) This makes it simple to distribute the source and images as a single file, but unfortunately the resulting file is not pretty.
In short: to see the source open it in DrRacket.
The departure from this ideal, I've discovered, is that there is a "Practical Crowd" who will swoop through when questions of practicality, such as cross-platform compatibility come up. Their opinions will be nearly absolute and they will be all but intolerant of the "weak" who claim that merely targeting Windows, Linux and OSX is "enough." They will justify with numerous cherry-picked examples from history, starkly, if not carefully, considered arguments toward the future, and with evidence of grit on their fingers from the present, in which the particular ideal is espoused. At that time, they will down vote anyone deviant enough to cheer for Swift.
Yet, currently my friend, the Apple Crowd has the floor. Any practical concerns are scheduled after the celebration. Think of this when you read the next cross-platform thread and see the Apple fans trying to get a point in edgewise amongst The Practical. There is very little global reality, mainly local basins of morality.
Is there a way to get that without being a signed up dev with Apple?
You need to be in the iOS developer program to get iOS 8 beta.
Tell that to Microsoft ;)
On principle I'd like to see Apple put Swift under a free software license of some kind and ideally make a cross-platform reference implementation, but realistically, even if they do that it's unlikely to ever get wide use anywhere but Apple products.
It's Apple's libraries you don't get on Windows.