Swift: Not quite there, but too far gone too
studentf.wordpress.com
Swift: Not quite there, but too far gone too
1–10 of 50 posts
Re: Swift: Not quite there, but too far gone too
#2The article suffers from a bit from looking at things from a strictly theoretical knowledge (i.e. the first example is not valid Swift code), but it does bring up a few interesting points.
Re: Swift: Not quite there, but too far gone too
#3Optional types are not the only use of algebraic data types. I agree that it's weird to have them and optional operators in the same language, but I don't see it as a big issue.
Re: Swift: Not quite there, but too far gone too
#4I agree that instances being pass-by-reference is weird, with everything else having copy semantics. It seems as yet another odd artifact of the design constraint that Swift must be ObjC-runtime compatible.
I sort of wish they had created a special type annotation to support legacy ObjC classes, and gone for Go-style structs for the non-legacy OO.
Re: Swift: Not quite there, but too far gone too
#5I agree that instances being pass-by-reference is weird, with everything else having copy semantics. It seems as yet another odd artifact of the design constraint that Swift must be ObjC-runtime compatible. I sort of wish they had created a special type annotation to support legacy ObjC classes, and gone for Go-style structs for the non-legacy OO.
It's more than that. I don't think having non-reference objects is entirely impossible (e.g. Objective-C blocks are already stack-based objects until they are copied), but it doesn't work for Swift's design goals. Objects have to be reference types because Swift needs to interact with Cocoa and Cocoa Touch, which assume reference-sharing in many places.
Re: Swift: Not quite there, but too far gone too
#6I don't understand the obsession with mutability. When is it a problem that a variable is mutable?
Re: Swift: Not quite there, but too far gone too
#7I start writing a ORM (that is how I learn a new language). Very fast I hit problems. The keynote and the state of union say swift is ready for production, but is not there yet. The coding experience is buggy, the repl violate the language (is possible to change a constant to another type!), the importing of other obj-c code is sometimes broken (ie: Not work at all, or yes). A lot of things are not documented (For example, how do a generator?), etc
Still, I hope this lang mature and be popular, because I want badly to not use obj-c
Re: Swift: Not quite there, but too far gone too
#8I don't understand the obsession with mutability. When is it a problem that a variable is mutable?
Probably because is hard to track the chain of calls that could have change the data. If inmutable, you are sure what exactly you have at hand.
But the article point to a inconsistent mutable/inmutable behavior that is more problematic.
Re: Swift: Not quite there, but too far gone too
#9I don't understand the obsession with mutability. When is it a problem that a variable is mutable?
Check out Rich Hickey's (the creator of Clojure) talk The Value of Values. He makes a good case for immutability.
http://www.confreaks.com/videos/1830-jaxconf2012-keynote-the...
Re: Swift: Not quite there, but too far gone too
#10I start writing a ORM (that is how I learn a new language). Very fast I hit problems. The keynote and the state of union say swift is ready for production, but is not there yet. The coding experience is buggy, the repl violate the language (is possible to change a constant to another type!), the importing of other obj-c code is sometimes broken (ie: Not work at all, or yes). A lot of things are not documented (For ex…
Why the downvote?