Still, I hope this lang mature and be popular, because I want badly to not use obj-c
https://devforums.apple.com/thread/227949?tstart=0
and when importing obj-c code https://devforums.apple.com/message/972445#972445 it suddenly can't refer to them.
How much is this about xcode or the language is something I don't know.
The thing is, I'm a avid supported of alternate languages. When everyone use VB, I use FoxPro. When is C, I use Delphi. I get iOS instead of Android, and python instead of php.
But with swift I hit in less than half a hour several crashes & weird behaviour (not just: i don't know how use this lang) that I rarely experiment when use other langs.
But: I still continue with this, because the lang -despite the flaws (no exceptions? why ...? and other stuff) seem enjoyable.
For example, when the REPL is invoked with /Applications/Xcode6-Beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift, is possible to write:
let a= 1
This create a constant integer. According to the docs, is a constant and can't change.
However, you can write:
a=2
And it work. But if is write in XCode it show that that is a error
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.
That sounds like a bug to me. I would expect the compiler to detect it as an error (it doesn't). Can anyone point me to the relevant bit of the spec that says you can do that?
https://developer.apple.com/library/prerelease/ios/documenta...
I'm not sure why the author believes that once the language ships it cannot change. Surely all languages evolve and change over time, it would be foolish to think Swift as it ships in September will not change for a decade after that.
As for Python 3, the Python community never intended for people to move over to Python 3 immediately, nor was it intended for people to move their Python projects from Python 2 to Python 3 unless they had some reason to (e.g. Django, public libraries, etc).
So the expectation seems like it's probably based on real history, but things seem different now, though. Languages are evolving faster than before, even some of the ones that previously moved very slowly.
It is analogous to global variables. We know they are bad, because any other piece of code can change them and break our code.
A variable having state is similar. When you think about what a function does or write tests... having the variable be able to have many unknown states increases the complexity.
In code we write everyday, a variable might be undefined, null, a valid phone number as a string, etc. But in immutable code, if your input comes from a function that returns either None or a valid phone number as a string and no other code can tweak this... then your code becomes much easier to think about and write tests for.
http://www.confreaks.com/videos/1830-jaxconf2012-keynote-the...
But the article point to a inconsistent mutable/inmutable behavior that is more problematic.
I stopped reading about here.
ObjectiveC -> Swift -> C#: iOS, Android, Windows Phone etc.
>"So this is a list of things I don’t like about Swift based on things I’ve read in the book, without having experimented with the language myself..."
Question; why post this then?