Swift Evolution acceptances: The big three
ericasadun.com
Swift Evolution acceptances: The big three
1–10 of 37 posts
Re: Swift Evolution acceptances: The big three
#2Swift is changing fast. Chris Lattner has stated that Apple will have a good migration solution to update current Swift code. If Apple does it right, Swift will be a major cross platform language within a few years.
You can argue that Rust, Nim, or Go are better, for example, but the community and support Apple give Swift give it a big advantage. Simply look at the number of Swift books published in the first 18 months:
Re: Swift Evolution acceptances: The big three
#3I recently did a game jam with my brother where we wrote a small OS X game in a weekend in Swift using SpriteKit. It was quite fun, and Swift was really pleasurable to write in.
These changes look great and will really improve the clarity of the standard API, and are just good coding guidelines in general.
I write web applications all day, and no current web language is as fun to write in as Swift.
Re: Swift Evolution acceptances: The big three
#4Link was down for me here is the google cached version http://webcache.googleusercontent.com/search?q=cache:B3qA4jq...
Re: Swift Evolution acceptances: The big three
#5Swift is changing fast. Chris Lattner has stated that Apple will have a good migration solution to update current Swift code. If Apple does it right, Swift will be a major cross platform language within a few years. You can argue that Rust, Nim, or Go are better, for example, but the community and support Apple give Swift give it a big advantage. Simply look at the number of Swift books published in the first 18 mont…
Wouldn't code released be a better measuring stick?
Re: Swift Evolution acceptances: The big three
#6Big things missing from Swift IMO:
- Higher-kinded types
- Strictly-typed "throw"
I'm not sure about dropping "Type" from protocols because it's pretty commonly used to separate the protocol definition (which is extended to provide most of the implementation) from the concrete base implementation, e.g. RAC's SignalProducerType/SignalProducer.
Re: Swift Evolution acceptances: The big three
#7I'm basically glad to see the Type suffix removed from the standard library protocols. I'm hoping that they'll have a solution to make it so writing a function over a generic sequence isn't such a mouthful.
I'm a little flummoxed by the new effort for first argument labels. Function names often imply the meaning of their first arguments very effectively and the new splits in function names seem arbitrary at times. Labeling subsequent arguments is an excellent feature of Swift but first argument labels often seem to complicate the syntax, especially labels like of: which don't always imply much about the meaning of the argument by themselves.
Re: Swift Evolution acceptances: The big three
#8Swift is changing fast. Chris Lattner has stated that Apple will have a good migration solution to update current Swift code. If Apple does it right, Swift will be a major cross platform language within a few years. You can argue that Rust, Nim, or Go are better, for example, but the community and support Apple give Swift give it a big advantage. Simply look at the number of Swift books published in the first 18 mont…
If anything, I'd argue that we're in the middle of a fantastic time for languages. I have at my disposal Go, Rust, Swift, and Nim, not to mention a re-emergence of Erlang (and birth of Elixir), Clojure on the JVM (and what the heck, Java)...
There's so much happening in languages now, it's a wonderful time to be a developer! People will always argue about which is the best, why Go needs generics, etc., but when you're a "right tool for the job" kind of developer, your toolbox is looking pretty sweet right about now.
Re: Swift Evolution acceptances: The big three
#9Swift is changing fast. Chris Lattner has stated that Apple will have a good migration solution to update current Swift code. If Apple does it right, Swift will be a major cross platform language within a few years. You can argue that Rust, Nim, or Go are better, for example, but the community and support Apple give Swift give it a big advantage. Simply look at the number of Swift books published in the first 18 mont…
Wouldn't code released be a better measuring stick?
There are a lot of a Swift GitHub projects.
http://www.h4labs.com/dev/ios/swift.html?q=github.com&age=10...
Re: Swift Evolution acceptances: The big three
#10I'm basically glad to see the Type suffix removed from the standard library protocols. I'm hoping that they'll have a solution to make it so writing a function over a generic sequence isn't such a mouthful. I'm a little flummoxed by the new effort for first argument labels. Function names often imply the meaning of their first arguments very effectively and the new splits in function names seem arbitrary at times. La…
The function name often includes the name of the first argument just by virtue of it being spelled out. Current Swift function names are usually two parts, one part for the function itself, and one part that indicates the meaning of the first argument. For example, consider removeAtIndex, substringWithRange, or joinWithSeparator.
To me, it makes a lot more sense to just call these remove, substring, and join, and label the first argument to express what's removed, substringed, or joined with. This makes the first parameter consistent with subsequent parameters, and makes the actual function name purely about the function's, uh, function.