Flappy Bird in Swift(github.com) |
Flappy Bird in Swift(github.com) |
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
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.
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()}
var spawn = SKAction.runBlock self.spawnPipesI 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
Lisps have the RPN psychological barrier. Python has the significant whitespace psychological barrier. etc. Any language can present someone with some psychological barrier.
I think the OP's strongest point was, Objective-C the language is pretty trivial to learn quickly (after all, it's just C with message passing). You'll spend far longer trying to learn the Cocoa APIs than you will spend learning Objective-C-the-language.
For instance, I decided to try to learn swift and SpriteKit at the same time. I spent far longer looking up methods on SKSpriteNode than I did looking up language constructs. (i.e. I assumed "let" was the same as in ES6 and couldn't figure out why the compiler was mad.)
It's far more difficult to get to grips with how the APIs work.
Direct link to the playground file: https://developer.apple.com/library/prerelease/ios/documenta...
But there are plenty of language constructs which exist only in Objective-C.
"Apple has recently added new functionality to their runtime, including built-in exception handling, etc. Hopefully these will be ported to the GNU runtime in the future."
When dealing with anything legally distributed / created in the US there are many questions, but "is it copywritten" should be one of the last ones, because the answer is always YES.
Considering the language has only been public for <36 hours, I would imagine effectively no one outside of Apple (and its Alpha partners) does.
In this sense, the code is even less clear than the Objective C implementation.
All you have to do is get over named parameters, square bracket message passing, and overall verbosity, and you know enough to read/understand Objective-C code.
If you can get past those three differences, Objective-C is remarkably similar to Java and other OOP languages.
Personally, I love the verbosity. The code pretty much just explains itself.
Swift is a welcomed change though. I'm very optimistic and excited about the future of iOS going forward.
> All you have to do is get over named parameters, square bracket message passing, and overall verbosity
Translation: "All you have to do is get over it's poor readability and it's quite readable!"
> Objective-C is remarkably similar to Java and other OOP languages.
Translation: "Objective-C is as readable as several other unreadable languages".
;-)
Readability isn't about familiarity as much as it's about clarity and a lack of boilerplate. Verbosity is in most cases the antithesis if readability. I think there can be exceptions (maybe some verbose DSLs that manage to map cleanly from your brain to the code on the page) but if the verbosity comes from boilerplate or visual clutter then verbosity is a strong point against.
if var == true {...}
if (<expression> == true) {
return true;
} else {
return false;
}
if var == true {...}
However in the strongly typed swift I don't think it will be a problem as I suspect (but haven't read/tested enough yet to confirm) that only false and nil will be falsy and that comparison with true will throw errors if var isn't of bool type.
3 == true // Give an error (operator overload doesn't cover this)
true == 3 // Returns false
nil == false // Returns false
But the branch and explicit boolean comparison are additional structural complexity (not just "verbosity") and invariably harms readability to me. Care give a poster child example for where it helps readability? Unless it's unclear <expression> results in a boolean - a problem better solved through better naming - code like this forces me to perform the equivalent simplification in my head to understand and reason about the code, a process fraught with error and distraction from my actual task.
return expression;