Originally Posted by asdasd
Nothing in that code which couldn't be done in objective c of course, albeit without the compile error. Most of the work is the frameworks. At the moment swift is unstable in its design, it's philosophy of design in many ways, the debugger, playgrounds, interaction with objective C, the compiler and debugger. Which is a lot.
I wasn't trying to show things that couldn't be done in Obbj-C or vise versa. Rather, I was trying to illustrate the workflow going from interactive debugging to a compiled app. I could have eliminated the compiler error, but I thought it better to be honest and note that you, likely, will have slightly different versions of code in the Playgrounds and in the compiled classes (at least for now).
Yes, most of the work is in the frameworks -- and much of the problems is unlearning the Obj-C way and relearning the Swift way ... It's more than different syntax, its a different approach to the way you attack a task.
I will concede that Swift is somewhat unstable
in design -- I think that Apple enjoys (and exploits) the luxury of not having a Swift install base (it's only been available for a little over a month) ... They don't need to deprecate things to protect existing developer code -- They just change things and the devs need to go with the flow.
I expect this evolution/instability to continue until the GM (a week before the iPhone availability) when they will accept Swift apps for the App store.
Is it easier to understand than objective C? Sometimes. Sometimes not. See generics.
They have in many cases - and this is a design philosophy - sacrificed code readability on the alter of code compactness. Which is the opposite of objective C. We'll see. I have plans to write some swift code in my large mac project targeting Yosemite. . I've tried already but code which worked in the playground failed with a compiler exception in the real build. That's not good.
It does reduce potential crashes caused by nil pointers passed into some framework API. Performance is not really obvious.
I, too ran into several cases where code that worked in Playground (ha, almost typed Praygrounds) failed to compile. Before I could submit a bug, beta 5 eliminated the problem.
I have been doing some performance comparisons with > 10K packets coming down the line from a web site/service.
I don't think that Apple has rewritten the JSON serialization/deserialization routines to exploit Swift, yet -- so I don't expect any improvements here -- yet!
But I've been testing an alternative to JSON, XML, etc. -- all that verbose crap. I've been timing building arrays and dictionaries using String, Any and AnyObject. Beta 5 Swift is 1 - 2 orders of magnitude faster in some cases.
This performance should really appeal to IT and IBM who need to shlep around big data.
Here's a post I made to another thread:
Originally Posted by Dick Applebaum
I've been playing with Beta 5 Swift.
Some bugs between Swift compiled code and Playgrounds have been fixed.
But the greatest thing I noticed is more than an order of magnitude performance improvement to create a large array of AnyObject:
On the prior release, the time to create theArrayAnyObject was ~ 0.021 sec (similar to both other arrays.
.....With this release, the time to create theArrayAnyObject was 0.000947952270507812 sec
This totally aces JSON or XML deserialization ...Look out big data, here we come !!!
elapsed time: 0.0219079852104187
Total creationTime: theArrayString 0.0213939547538757 sec for 1787 entries
elapsed time: 0.00145995616912842
Total creationTime: theArrayAnyObject 0.000947952270507812 sec for 1787 entries
elapsed time: 0.0282269716262817
Total creationTime: theArrayAny 0.0276419520378113 sec for 1787 entries