Still, I hope this lang mature and be popular, because I want badly to not use obj-c
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:
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
Swift, as XCode 6, is still beta.
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?
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.
Go did breaking changes pre-1.0, but they are now committed to providing a stable platform that only accretes features (http://golang.org/doc/go1compat).
Note that the Go compat wiki you link to acknowledges a future Go 2 that may break compatibility. That's actually a pretty strongly pro-evolution statement compared to past languages.
It's also worth noting that Swift isn't even at 1.0 yet, and they've said there will be changes before release. So I also disagree with a somewhat hysterical "we'll be stuck with this!!11!!" right now.
It's all just guesses, though. We'll see.
It was intentionally done as a 'clean break' release; 2.x keeps doing the same stuff it used to do, and Python 3 changes a bunch of stuff which, in hindsight, makes sense (such as a distinction between 'stream of bytes' and 'string of text', vs. 'stream of bytes which may or may not be ascii text' and 'string of unicode text').
That said, there's no real benefit to moving an existing project/codebase from 2.x to 3.x, and it was never intended that there would be one. Python 3 is for new projects; Python 2.x is for existing projects, or new projects which need deployment in older environments.
That said, I don't think this part of the python3 effort entirely succeeded. Unfortunately they share a package source, so a lot of projects do need to support both. But whatever failings there have been in the python jump to 3.0, they're nothing compared to the disaster that was ruby 1.9, even though I think 1.8.7 is truly relegated to legacy now.
As long as they learn from those issues, though, I think the future is bright for non-stagnating languages.
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.
But the article point to a inconsistent mutable/inmutable behavior that is more problematic.
What you actually gain from (im)mutability notation is documentation and sanity checks: it's a huge win to tell the compiler "yell at me if I ever try to modify this variable", which unambiguously indicates to a human "don't worry, this variable is never modified in this code".
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.