> Well... > > First: I think Swift is going to be the future, so I might as well start > learning it now.
I thought that too, then dropped back a bit until the full spec for 1.0 is there at least so the moving target doesn’t move as fast. It’s the future absolutely, think it’s got a couple of years/versions before it’s the language of choice. > > But: > The speed of Swift is still not so swift. > I just ran an app which has two versions: the running time in Swift beta 5 is > only 76 % of beta 4 (which is a nice improvement), but it is still 10 % > slower than Obj-C. I was asking more about actually using the language to write applications, real ones, not just examples in a book but real apps which have to interface with the runtime we use, Cocoa. Do you find you are really using the full power of Swift, making powerful typesafe data structures, using generics and only dropping back to Cocoa for input/output and event handling? It has seemed to me, and I’m most certainly not trying to be rude, that you’ve had to spend a lot of time re-expressing ObjC/Cocoa constructs in Swift, and often they aren’t very pretty. That was my experience when I tried it out, and I didn’t spend anywhere near as much time as you have, that the Cocoa library has so much in it you have to spend a lot of time there and the friction between Swift and Cocoa is great enough once you’d crossed over, you stayed there and that I ended up just writing what I would have in Objective-C, using a different syntax, that of Swift, which didn’t buy me much. The example in this thread was quite illustrative in some ways. Swift strings and NSStrings are convertible to each other. Swift strings have a rangeOfString() method, NSStrings have a rangeOfString: method. But the results of those two methods are very different, one’s a Swift range, a generic, it’s typesafe, it’s iterable, it’s fine in Swift, it’s a super thing until you want to use it as it bears no relation to, and as far as I could tell just wasn’t practically convertible to, the NSRange the NSString method returned which you needed back in Cocoa to colour your attributed string. So the answer ended up being to bail out of Swift right at the top, at the last point of compatibility, between string and NSString, and then just drive objective-C from there onwards, using a different call syntax. Obviously this is going to get better. I have to think Swift will grow its own class library full of all the tools we’re so used to in Cocoa we hardly think about them. At the moment, for actual practical apps of any size, Swift feels like a racehorse tied to a donkey cart, and you keep getting dragged down to the level of the donkey. (and I like donkeys by the way and think they are wonderful animals just incase there are any donkeys on the cocoa list). _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
