31–40 of 50 posts
Earlier quoted context omitted.
Why the downvote?
Maybe because neither the keynote not the state of union said swift is ready for production.
P.D: This remark was about 32 min in the state of union video
I 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…
Can you provide more details? All of the issues you mention seem like typical early beta expectations.
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
Earlier quoted context omitted.
By and large, languages don't really change — they just accrete. It is very rare for something that used to work one way to later work another way. For example, languages generally do not go from being statement-based to being expression-based, or go from something being mutable to immutable, or eliminate operators. (MzScheme did the second one — it went from mutable to immutable defaults — and it was considered so s…
I agree this has historically been true, but again, I think this is changing. Ruby 1.9 and Python 3 both did more than accrete, they actively broke existing code in quite significant ways. 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…
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).
I 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…
Can you provide more details? All of the issues you mention seem like typical early beta expectations.
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.
Earlier quoted context omitted.
I agree this has historically been true, but again, I think this is changing. Ruby 1.9 and Python 3 both did more than accrete, they actively broke existing code in quite significant ways. 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…
Ruby and Python each did one release where they were willing to do significant changes. That's it — they're not doing it again for a good long while now. It's an isolated incident, not a trend in those languages' development practices that we can project into 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/go1co…
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.
Earlier quoted context omitted.
Ruby and Python each did one release where they were willing to do significant changes. That's it — they're not doing it again for a good long while now. It's an isolated incident, not a trend in those languages' development practices that we can project into 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/go1co…
I don't expect either of them to do it for a while either. The trends I'm talking about are in PL development in general. More breaking evolution is taking place post-initial-development than ever has before in languages both new and old. 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 language…
FTFA; > "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?
Because one would hope that the official Swift book does a sufficient job of describing the language?
Earlier quoted context omitted.
Because one would hope that the official Swift book does a sufficient job of describing the language?
Drop the snark. I doubt that it does a sufficient enough job to write a critique of a language that the OP admits they have they haven't tried! This article is nothing but here-say and as such is worthless.
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.
FTFA; > "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?
Earlier quoted context omitted.
I don't expect either of them to do it for a while either. The trends I'm talking about are in PL development in general. More breaking evolution is taking place post-initial-development than ever has before in languages both new and old. 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 language…
The statement you were questioning is that Swift will be "fixed for a decade at least" after release. If you agree that it will be at least four years before Python makes any more changes like Python 3, then you are agreeing with the OP.
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.