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
P.D: This remark was about 32 min in the state of union video
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).
If you feel like a language is missing something, that might be fixable — but if you feel like a language either added the wrong thing or did something the wrong way (which is the OP's concern), that is a much more difficult problem, because after release you can't take away what's already there without making people angry.
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.
C++ has so far avoided completely breaking changes, but with all the accretion it's doing now it's probably only a matter of time before some significant breaking changes happen lest it become even more ridiculously complex than it is now.
Go has had breaking changes as well, I believe, but they have a smart upgrade tool to help with it. This is probably something that will catch on for other rapidly evolving languages.
I think we'll see a lot more of this kind of thing in the future.
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?
But let's delve in. Why is it impossible to analyze a language from a programming language theory perspective without having used it? Obviously having used it will give a fuller perspective, but I don't see what you think is so deficient about the extensive documentation Apple has put out that it's impossible to comment from a theoretical standpoint on that basis.
To put it another way, I think you should drop the snark. If you have an actual problem with the critique or with the Swift documentation, you can bring it up. A snarky dismissal like "Question; why post this then?" does not add anything.
