Apple Releases First Preview of Swift 3.0 for Developers [Update: Not Available]

[Mascots]

There are more than a few issues with this announcement about Swift 3.0, the first of which it is not fully backward compatible with earlier versions. Today is code was written in the first iteration of Swift it has to be updated by xCode before it will even compile, now imagine what 3.0 will do to the current base of Swift code out there.

There is nothing new about this.
Every version of Swift has added changes to the foundation and syntax and is something that is to be expected upon adopting the language. By the response from many people, those who aren't up to the challenge certainly did not take the leap. I have several projects written in Swift and have been down the entire version path without issue, annoyance, maybe, but I've had much worse transitions from UIKit. The changes are minor and Swift 3.0's leap isn't going to be any different than 1.2 to 2.0 was. There is no now imagine.
There's also nothing preventing someone from working on 2.2 and 3.0 projects simultaneously as you can run multiple versions of Xcode. It's a hoop, but every time I've jumped it it's been more than worth it in my opinion. I'd much rather be working with todays rendition than the first.

 

[Janichsan]

There are more than a few issues with this announcement about Swift 3.0, the first of which it is not fully backward compatible with earlier versions. Today is code was written in the first iteration of Swift it has to be updated by xCode before it will even compile, now imagine what 3.0 will do to the current base of Swift code out there.

There is nothing new about this.
Every version of Swift has added changes to the foundation and syntax and is something that is to be expected upon adopting the language. By the response from many people, those who aren't up to the challenge certainly did not take the leap. I have several projects written in Swift and have been down the entire version path without issue, annoyance, maybe, but I've had much worse transitions from UIKit. The changes are minor and Swift 3.0's leap isn't going to be any different than 1.2 to 2.0 was. There is no now imagine.
There's also nothing preventing someone from working on 2.2 and 3.0 projects simultaneously as you can run multiple versions of Xcode. It's a hoop, but every time I've jumped it it's been more than worth it in my opinion. I'd much rather be working with todays rendition than the first.

Not only that, but the previous versions of Swift included an importer that made updating the code easy by either applying certain changes automatically or by pointing out necessary changes.

 

[groovyd]

Same here. The more I learn the more I hate it. It's incredibly sloppy and you're right, the syntax is all over the place. It's hard to realize what you're looking at sometimes.

I have yet to find out how the code is magically shorter (its not, unless you count the fact that there's only one file for a class, not a separate header and footer), I do not see at all how its more concise, there's so many freaking ways to do one thing that its just a headache. You have to learn them to because some high speed out there will try and be fancy with his code and use nonsense like function currying (which thankfully they're getting rid of).

yeah, gotta hate those high speeders out there always using the eclectic features that just make for confusion and don't really improve anything but sound good on paper. I think there is a bit too much of that sort in comp sci. these days.
[doublepost=1464877944][/doublepost]

Probably because you're a programmer by trade who has plenty of experience. Swift is designed for those who are not used to the C way of doing things, but rather the Perl/Python way of doing things (save type-safety - I'm referring to syntax). Basically, it's designed for new programmers who don't want to bother with complex syntax - and on that front it's certainly much easier to learn than say, Obj-C
[doublepost=1464844558][/doublepost]

Obj-C is a nightmare language too for it's cryptic syntax and calling conventions. Regarding Perl also a complete syntactic mess. Python at least tries to simplify the syntax and I applaud that. If I was to learn a first language of them all as a new programmer I would guess either c or python would be the easiest to learn and also the most powerful 'swift' as it might be. The biggest issue in general with programming isn't the language but the ease and availability of libraries or api's for actually doing something bigger then sorting a vector.
[doublepost=1464878008][/doublepost]

According to some apple engineer the only part in iOS/OS X that uses swift so far is the calculator on iOS and the dock in OS X.


You are joking right ? Swift has the cleanest and most logical syntax out of all the programming languages, by far.

Not joking at all and just don't see that as true.

 

[Essenar]

As an iOS Developer who worked full time in Objective-C: Yes Swift is better. Not performance wise but just convenience wise. It's harder to make mistakes, easier to write lines of code and there's more you can "do". Period.

As a mobile developer in general/software developer by profession: Please stop bringing up the iOS operating system and asking when it will be written in Swift. The best answer to that is never. iOS is written in BSD/C, similar to OSX, Linux and almost every other performance driven OS on the planet.

You will not find a way to have easier access to hardware level addresses using a high level language like Swift. Think beyond simply accessing a "piece" of hardware, similar to using the Bluetooth Manager in an iOS app to detect beacons. A low level OS needs to actually CREATE pointers and then reference to them. It needs to access memory bit by bit.

You'll never see the source code to iOS because making the device secure requires absolute protection of the source code. Thus, you'll never see the way iOS is built unless you get hired by Apple and work on it. Apple knows what they're doing. Swift is to make us write apps for iOS easier. iOS is written in a traditional operating systems language.

 

[springsup]

Warning: Wall of text

I really dislikes where Swift is heading, Swift 1 was incredible easy to move to from languages that was influenced by C, even people that only had been programming in PHP could very quickly get into Swift 1, then, in Swift 2, they removed several things that made it easy for beginners and C styled language programmers to learn Swift, and now with Swift 3 they removed/changed even more.

Swift 1 was a fairly easy language for beginners, now, they are moving in the direction that made it so hard for beginners to learn Objective-C, sure, it is also inspired by C but you had to write so much to get so little done and alot of function names gave no clue to beginners what they actually ment, with the launch of Swift it was on its way to become a language for a whole new generation of developers that had never coded anything before

Now, with these updates, it gets harder and stricter, we live in a world where alot of developers are multi language programmers, why then not keep a somewhat nice relationship between languages instead of forcing Swift away from these, Swift is heading in a direction where people have to relearn alot of stuff and cant rely on experience from other languages like Go, Java, Javascript, PHP, C, C++, C#, Perl (i think), for example if you come from another languages you are probably very used to unary incr/decr (not best practice but hey), but now they will be gone from Swift, you can no longer lean on experience from other languages for some parts of Swift (well, you could in Swift 1, but not Swift 3), when the new and younger developers, even schools starts to adopt programming from an early age, a new language should be easy to learn, Swift 1 was that language, but it has slightly moved away from that philosophy


The obvious example:
C style for loops was easy, really easy, i did not have to help anyone of the PHP developers with for loops when they wanted to learn Swift 1, now, i don't know how many times i had to remind people of the for loops in Swift 2, and every time i do, trying to explain the concept of ranges, i always get a reply that the "new" way is so unintuitive (1...5 are easy for everyone but more advanced examples seems to be hard for some people to wrap their head around, dont know why), yes, the new for loops is more consistent with the other loops but...the for loop, or the enumerations is used by almost any other language, now, Swift removes them, C style for loops could happily live next to the new ones


Yes, i realize that alot of people will disagree with me and C style for loops and unarys have been discussed to death the last year but hey, i like languages that makes it easy to jump between languages when developing, Swift will not be one of them if this continue

C is not a perfect language. Those 'for' loops you mentioned are total garbage, some kind of hieroglyphics that isn't immediately obvious. Swift's loop syntax is much easier to understand IMO, and it can support filters to make it even easier to read ("for case let ... where ..." -- the 'if case let' syntax is a bit iffy, I'll grant that, but Swift is open and you're welcome to suggest improvements).

Other things, like unary operators, you yourself agree that they're bad while also criticising Swift for not wanting to keep this C cruft around?

I think your expectations of Swift are wrong. They want it to be as universal as C, they want it to be as fast if not faster than C, but Swift is not C. They will not copy C's syntax, and if there are decades-old C conventions which today are considered unsafe/poor practice, they will not apologise for not implementing them.

When creating a new language, you want it to be reasonably familiar so people have an easier time learning it, but it's a very minor consideration. Having a clear and consistent identity for the language is more important, and if you get those right your language will be intuitive without needing to cobble it together from bits of other languages' corpses.

Things like the for syntax are good examples. Swift is just plain better than C here, IMO:

Swift:

for index in 0...5 {
// index will be 0,1,2,3,4,5
}​

C:

for(int index=0; index<=5; index++) {
// huh?
}​

Swift:

for index in 0...10 where index % 2 == 0 {
// index will be 0,2,4,6,8,10
}​

C:

for(int index=startIndex; index<=10; index++) {
if( index % 2 != 0 ) {
continue;
}
// Yuck.
}​

 

[MacsRgr8]

That in turn was based on BSD which which started in the 1970's. I believe iOS and OS X may be based on the FreeBSD derivative.

But it's fair to say that OS X and thus iOS far more directly linked to NeXTSTEP than any earlier version of UNIX.
It's really Steve's vision of UNIX made easy-to-use.

 

[mildocjr]

Does anyone think iOS 10 will be completely rewritten with Swift 3.0?

I'll almost bet anything it will be written in C, Obj-C, and Swift 2.2. Probably won't see that jump to Swift 3 until iOS 11. Since we have 2 weeks to go before WWDC, the preview will be using the latest stable version of Swift, and there is a really good chance that the iOS 10 GM will still be holding on to Swift 2.2 even if Swift 3.0 comes to fruition before the public release of iOS 10.
[doublepost=1464894456][/doublepost]

As someone just starting to learn Swift (2.x) could someone else provide some perspective for me on just goe different 3.x will be? How much of my learning will be made-for-not?

It all depends.

In Swift 2.2 this works.

for (j = 0; j < 5; j++) {
//loop stuff
}

In Swift 3.0 you will not be able to use the ++ operator or the c-style for loop. Instead you'd use

for j in 0 ..< 5 {
// loop stuff
}

j is still your loop variable so if you are iterating through arr[] you can still use arr[j] the same way. To increment this you'd need j += 1.

If you'd like more on what will change bookmark the Swift Evolution Github page.

EDIT: I know above I said you'd need j += 1 but in the new for-in loop you get this for free as is. Instead you'd be looking at calling stride() if you wanted to iterate by something else. Perhaps someone could elaborate because I haven't gotten good enough with it to actually write about it I just know you need to use it for j += 2 or higher.

 

[bjet767]

As languages become "higher" they do a lot of the trivial stuff like ++ for the coder, but it comes at a cost, speed. I have a friend who writes code for speed and the ability to do really massive computational work, the kind of work which uses 100% of the CPU through a single core and he writes exclusively in C. Why? Because it is really low level, assumes nothing and is also why OSs are written in it.

All languages use clock time and the higher they are the more they use to do seemingly simple tasks. Swift is a higher language than objectiveC and will be a bit slower, but you and I will never see that penalty because most of our apps and programs spend 90% of their time just idling.

Overall it doesn't matter what language you use the real problem is writing stuff other people can really use. I will wager many commenting on this thread do not have one app or program out for public consumption (App Store). Don't be disheartened, code away and take the plunge by publishing something on the App Store, even if it's a free app.

 

[mildocjr]

As languages become "higher" they do a lot of the trivial stuff like ++ for the coder, but it comes at a cost, speed. I have a friend who writes code for speed and the ability to do really massive computational work, the kind of work which uses 100% of the CPU through a single core and he writes exclusively in C. Why? Because it is really low level, assumes nothing and is also why OSs are written in it.

Absolutely, what might take Swift 0.04 seconds to do might take C 0.000001 seconds to do, it's just the nature of the language, but don't let it deter you from a language. OSes need that fast of processing because they do a lot more than your average application.

To explain why you'd use C over another language and vice versa can be used with a game example.

Keeping this simple, a game is based in two parts the engine and the game itself.
BattleField 4 for example - Game is BattleField 4, engine is Frostbite.

The engine does all the heavy lifting, the game engine handles the AI movement, the (2d/3d) graphic rendering, etc...

The rest of the game handles networking, keeping a list of player names, social media connections, keeping track of your character customizations, currently playing music track.

As you need classes to hold your character customizations you cannot use C as you need a higher level language such as C++ to handle objects and pass all of the character customizations at once as a character object.

As nice as it is to have everything written in a lower level language and blazingly fast, it might be easier to implement and maintain in a higher level language where most of the code is preformatted in an MVC architecture.

 

[chrono1081]

I'm glad the purely useless function currying is leaving. It's quicker and easier and more intuitive just to write another function vs to split one up all crazy like.

Not a single person on many different programming forums was able to give me a concise example of function currying or why it is better than just making another function to do what you want. Most replies turned into "Well its useful in Haskell..."

 

[arkmannj]

I'll almost bet anything it will be written in C, Obj-C, and Swift 2.2. Probably won't see that jump to Swift 3 until iOS 11. Since we have 2 weeks to go before WWDC, the preview will be using the latest stable version of Swift, and there is a really good chance that the iOS 10 GM will still be holding on to Swift 2.2 even if Swift 3.0 comes to fruition before the public release of iOS 10.
[doublepost=1464894456][/doublepost]

It all depends.

In Swift 2.2 this works.

for (j = 0; j < 5; j++) {
//loop stuff
}

In Swift 3.0 you will not be able to use the ++ operator or the c-style for loop. Instead you'd use

for j in 0 ..< 5 {
// loop stuff
}

j is still your loop variable so if you are iterating through arr[] you can still use arr[j] the same way. To increment this you'd need j += 1.

If you'd like more on what will change bookmark the Swift Evolution Github page.

Thanks I'll be sure to give that link a look over. At least in that example I much prefer the updated way of performing the loop.

From a quick glance at the material in the link, it looks like I'm not seeing earth shattering differences that would make my current studies worthless, just a few potential bumps in the road. I've noticed that Xcode has been giving me friendly warnings about some of my code not being compatible with swift 3.

 

[bjet767]

As nice as it is to have everything written in a lower level language and blazingly fast, it might be easier to implement and maintain in a higher level language where most of the code is preformatted in an MVC architecture.

Absolutely!

Back in the day I wrote simple assembly functions that wrote directly to the screen memory for speed. In the earliest days of Windows (even the first Foundation Classes) one had to write their own printer functions. I love the fact all the " hard stuff" (think about the number of lines of code it would take to display a view) has been done for the developer.

Example: I wrote a program for OS X a few months ago to build a database of text and images (to be used in an iOS app)and with the help of Storyboards, UIDocument, NSDocument, image objects I was dragging and dropping images and text within a day. In the day it would have been countless hours, days and lines of code to accomplish the same.

Object oriented programming is a blessing.

 

[springsup]

Not only that, but the previous versions of Swift included an importer that made updating the code easy by either applying certain changes automatically or by pointing out necessary changes.

There will be a migrator for Swift 3 as well. That will come much later, when the language spec for 3.0 is finalised.

Some things can't be automatically migrated, like the new indexing model, but it's a one-off thing that considerably improves how you build collections in Swift. That's the cost of using such a new language. Things will change more often than in a decades-old language like C.
[doublepost=1464907345][/doublepost]

As languages become "higher" they do a lot of the trivial stuff like ++ for the coder, but it comes at a cost, speed. I have a friend who writes code for speed and the ability to do really massive computational work, the kind of work which uses 100% of the CPU through a single core and he writes exclusively in C. Why? Because it is really low level, assumes nothing and is also why OSs are written in it.

All languages use clock time and the higher they are the more they use to do seemingly simple tasks. Swift is a higher language than objectiveC and will be a bit slower, but you and I will never see that penalty because most of our apps and programs spend 90% of their time just idling.

Overall it doesn't matter what language you use the real problem is writing stuff other people can really use. I will wager many commenting on this thread do not have one app or program out for public consumption (App Store). Don't be disheartened, code away and take the plunge by publishing something on the App Store, even if it's a free app.

That's not necessarily true. Swift is designed, really, to be as helpful as it can to the optimiser and compiler. Unless you want to hand-tune assembly for every architecture, your source code doesn't determine performance - the compiler and optimiser do. Maybe you need to structure your code in a certain way to make it more optimisable, but that's a failure of the language and optimiser. They should generate the very best code that does what you expressed, however you expressed it.

Simple operations like an Int increment should be as fast as C. If not, file a big report. But remember that C benefits from being extremely mature, so it has really good compilers and optimisers. Swift needs time to match/beat it.

 

[bjet767]

your source code doesn't determine performance

That's completely untrue.

What happens is the speed of the processor makes the performance hit unnoticeable. Yes the compiler, when fully optimized, will do it's best to "optimize" the coder's failures to be efficient, but it can't overcome just junky, bulky, repeated calls and poorly written code. That's what makes a great coder over a poor one. There is an art to this stuff and while one might use "brute force" others use a bit more graceful approach to coding.

As far as the speed of an int incremented loop or such, will it be as fast as C? The answer is ObjectiveC is also C. A simple loop with a ++ or -- is still a "C" loop. Now I can't say the same for the fast iteration "for loop" through an ObjectiveC array. One would have to run a good time comparison to see how it compares to a more raw "for loop". But I will bet none of us would notice any difference because again it really is insignificant.

As I mentioned previously I have a friend who is a pro level optimizer and would never use any "object" oriented code for such work because pure speed is absolutly essential to what he does. Again imagine a process which literally uses the fastest i7 core on the market and maxs it out, that's 100% CPU use and yes heat is an issue. BTW his title is formaly called a "Algorithm Theorist" and does some serious stuff, not the consumer things we typically produce for iOS and OS X.

I might point out that I am not against Swift at all. I learned OC and did some intro stuff with Swift (both 1 and 2) and found I have too much stuff committed to OC and until they get some sort of "inline" capability I will just let Swift sit on the back burner. What I have found is necessary is to know Swift enough to convert some of the newest example code to OC when I need it.

BTW I'm basically a hacker when it comes to coding and often use "brute force" when I can't find a graceful approach to a problem.

 

[mdriftmeyer]

Absolutely, what might take Swift 0.04 seconds to do might take C 0.000001 seconds to do, it's just the nature of the language, but don't let it deter you from a language. OSes need that fast of processing because they do a lot more than your average application.

To explain why you'd use C over another language and vice versa can be used with a game example.

Keeping this simple, a game is based in two parts the engine and the game itself.
BattleField 4 for example - Game is BattleField 4, engine is Frostbite.

The engine does all the heavy lifting, the game engine handles the AI movement, the (2d/3d) graphic rendering, etc...

The rest of the game handles networking, keeping a list of player names, social media connections, keeping track of your character customizations, currently playing music track.

As you need classes to hold your character customizations you cannot use C as you need a higher level language such as C++ to handle objects and pass all of the character customizations at once as a character object.

As nice as it is to have everything written in a lower level language and blazingly fast, it might be easier to implement and maintain in a higher level language where most of the code is preformatted in an MVC architecture.

In other words, write all your tightly coupled C functions with data structures and message them via ObjC and it's well-developed, rich and globally used MVC model that pioneered it long before C++ acted and adopted it as if it were the first to do so.
[doublepost=1464915805][/doublepost]

I'll almost bet anything it will be written in C, Obj-C, and Swift 2.2. Probably won't see that jump to Swift 3 until iOS 11. Since we have 2 weeks to go before WWDC, the preview will be using the latest stable version of Swift, and there is a really good chance that the iOS 10 GM will still be holding on to Swift 2.2 even if Swift 3.0 comes to fruition before the public release of iOS 10.
[doublepost=1464894456][/doublepost]

It all depends.

In Swift 2.2 this works.

for (j = 0; j < 5; j++) {
//loop stuff
}

In Swift 3.0 you will not be able to use the ++ operator or the c-style for loop. Instead you'd use

for j in 0 ..< 5 {
// loop stuff
}

j is still your loop variable so if you are iterating through arr[] you can still use arr[j] the same way. To increment this you'd need j += 1.

If you'd like more on what will change bookmark the Swift Evolution Github page.

EDIT: I know above I said you'd need j += 1 but in the new for-in loop you get this for free as is. Instead you'd be looking at calling stride() if you wanted to iterate by something else. Perhaps someone could elaborate because I haven't gotten good enough with it to actually write about it I just know you need to use it for j += 2 or higher.

I'm assuming they are adopting the domain nomenclature of general mathematics to eliminate the pre-iterative or post-iterative errors of ++j or j++ so commonly displayed by programmers?

In short, they are insulating it from you, behind the scenes. Then again, if you really understand applied mathematics that's the least of the concerns all programming languages exhibit when it comes to Numerical Analysis and mimicking discrete structured algorithms to cover large data sets with the included lack of elegance of actual applied mathematics: everything that Wolfram tries to preserve.

 

[flaw600]

yeah, gotta hate those high speeders out there always using the eclectic features that just make for confusion and don't really improve anything but sound good on paper. I think there is a bit too much of that sort in comp sci. these days.
[doublepost=1464877944][/doublepost]

Obj-C is a nightmare language too for it's cryptic syntax and calling conventions. Regarding Perl also a complete syntactic mess. Python at least tries to simplify the syntax and I applaud that. If I was to learn a first language of them all as a new programmer I would guess either c or python would be the easiest to learn and also the most powerful 'swift' as it might be. The biggest issue in general with programming isn't the language but the ease and availability of libraries or api's for actually doing something bigger then sorting a vector.
[doublepost=1464878008][/doublepost]

Not joking at all and just don't see that as true.

That's actually a fair point. Perl is a syntactic mess. My point was that Swift was designed to be easy for newer programmers to pick up, and I think it's largely succeeded on that front although Swift 2 was a backwards step in that regard. C, imo, is not easy to learn. Python is, but I have other issues with Python that isn't germane to this discussion.

 

[bjet767]

I think some have missed the point that iOS and OS X really don't care what you code in. After the compiler is done with it it really doesn't look a whole lot like what you or I typed in our editor.

 

[crashoverride77]

yeah, gotta hate those high speeders out there always using the eclectic features that just make for confusion and don't really improve anything but sound good on paper. I think there is a bit too much of that sort in comp sci. these days.
[doublepost=1464877944][/doublepost]

Obj-C is a nightmare language too for it's cryptic syntax and calling conventions. Regarding Perl also a complete syntactic mess. Python at least tries to simplify the syntax and I applaud that. If I was to learn a first language of them all as a new programmer I would guess either c or python would be the easiest to learn and also the most powerful 'swift' as it might be. The biggest issue in general with programming isn't the language but the ease and availability of libraries or api's for actually doing something bigger then sorting a vector.
[doublepost=1464878008][/doublepost]

Not joking at all and just don't see that as true.

Fair enough, most developers would disagree with you. So would IBM that uses swift and google who are considering to use swift as a first class language.

What better and clearer languages are there

Java? Nope;
Python? Nope
ObjC? Hell no

Swift is the simplest and cleanest by far, getting rid of as much baggage and legacy syntax along the way. I like it a lot.

 

[mildocjr]

In other words, write all your tightly coupled C functions with data structures and message them via ObjC and it's well-developed, rich and globally used MVC model that pioneered it long before C++ acted and adopted it as if it were the first to do so.
[doublepost=1464915805][/doublepost]

I'm assuming they are adopting the domain nomenclature of general mathematics to eliminate the pre-iterative or post-iterative errors of ++j or j++ so commonly displayed by programmers?

In short, they are insulating it from you, behind the scenes. Then again, if you really understand applied mathematics that's the least of the concerns all programming languages exhibit when it comes to Numerical Analysis and mimicking discrete structured algorithms to cover large data sets with the included lack of elegance of actual applied mathematics: everything that Wolfram tries to preserve.

Good response, however one complaint about your response Keep it Simple:

 

[crashoverride77]

Absolutely!

Back in the day I wrote simple assembly functions that wrote directly to the screen memory for speed. In the earliest days of Windows (even the first Foundation Classes) one had to write their own printer functions. I love the fact all the " hard stuff" (think about the number of lines of code it would take to display a view) has been done for the developer.

Example: I wrote a program for OS X a few months ago to build a database of text and images (to be used in an iOS app)and with the help of Storyboards, UIDocument, NSDocument, image objects I was dragging and dropping images and text within a day. In the day it would have been countless hours, days and lines of code to accomplish the same.

Object oriented programming is a blessing.

Protocol oriented programming is an even bigger blessing

 

[mildocjr]

Fair enough, most developers would disagree with you. So would IBM that uses swift and google who are considering to use swift as a first class language.

What better and clearer languages are there

Java? Nope;
Python? Nope
ObjC? Hell no

Swift is the simplest and cleanest by far, getting rid of as much baggage and legacy syntax along the way. I like it a lot.

I gotta say I do like Java because it's easily interchangeable with C# but I don't like the overhead of needing the JVM. C and C++ are probably some of my other favorites because of their speed. Python is cool but seems a little dangerous since the maximum value of an Integer is your RAM. Outside of that, it's a pretty awesome language. Obj-C... Little overboard on pulling NSEverything and @everything.

 

[crashoverride77]

I gotta say I do like Java because it's easily interchangeable with C# but I don't like the overhead of needing the JVM. C and C++ are probably some of my other favorites because of their speed. Python is cool but seems a little dangerous since the maximum value of an Integer is your RAM. Outside of that, it's a pretty awesome language. Obj-C... Little overboard on pulling NSEverything and @everything.

C to me is just hideous, doesn't matter the functionality. That's why I am surprised you said swift is confusing.

Swift is like Java on steroids. Especially now with its protocol orientated approach (protocol extensions), it's just so good.

I also just love the little syntax sugar swift has such as the guard statement. Code readability with swift is second to none IMO.

 

[mildocjr]

C to me is just hideous, doesn't matter the functionality. That's why I am surprised you said swift is confusing.

Swift is like Java on steroids. Especially now with its protocol orientated approach (protocol extensions), it's just so good.

I also just love the little syntax sugar swift has such as the guard statement. Code readability with swift is second to none IMO.

Swift isn't really confusing, it gets a little crazy when you first start learning about closures and preventing an object from owning itself, but I like it, it's a great place for beginners to start programming. My first language was actually C# and I can translate code between the two languages easily, C++ and C are confusing languages with writing std::cout << "Hello, World!" << endl; and If I didn't know any better I'd have no idea what the hell that was. As for Swift not only is it readable but it's simple print("Hello, World!"). It's almost as easy as COBOL in that respect display "Hello, World!". Of course when writing different ways to write Hello, World! anything looks easy.

 

[bjet767]

C to me is just hideous

The cool part about C is how open it is. In the day people would/could put code in the their .h files to hide it from lookers would normally be in the .c files. The main function could call just one funtion and a whole program would emerge. C++ added a whole bunch of required type checking and forcing the functions to actually return values, if required.

Yes C can be very messy and that's the heart of a low level language.

 

[springsup]

That's completely untrue.

What happens is the speed of the processor makes the performance hit unnoticeable. Yes the compiler, when fully optimized, will do it's best to "optimize" the coder's failures to be efficient, but it can't overcome just junky, bulky, repeated calls and poorly written code. That's what makes a great coder over a poor one. There is an art to this stuff and while one might use "brute force" others use a bit more graceful approach to coding.

As far as the speed of an int incremented loop or such, will it be as fast as C? The answer is ObjectiveC is also C. A simple loop with a ++ or -- is still a "C" loop. Now I can't say the same for the fast iteration "for loop" through an ObjectiveC array. One would have to run a good time comparison to see how it compares to a more raw "for loop". But I will bet none of us would notice any difference because again it really is insignificant.

As I mentioned previously I have a friend who is a pro level optimizer and would never use any "object" oriented code for such work because pure speed is absolutly essential to what he does. Again imagine a process which literally uses the fastest i7 core on the market and maxs it out, that's 100% CPU use and yes heat is an issue. BTW his title is formaly called a "Algorithm Theorist" and does some serious stuff, not the consumer things we typically produce for iOS and OS X.

I might point out that I am not against Swift at all. I learned OC and did some intro stuff with Swift (both 1 and 2) and found I have too much stuff committed to OC and until they get some sort of "inline" capability I will just let Swift sit on the back burner. What I have found is necessary is to know Swift enough to convert some of the newest example code to OC when I need it.

BTW I'm basically a hacker when it comes to coding and often use "brute force" when I can't find a graceful approach to a problem.

The compiler doesn't just slightly modify your code; it has pretty large amounts of freedom to reorder and even remove code if it can prove that the result is the same. In some cases, if the result can be statically known at compile time, it might just run your code and paste the result in instead (!). Inlining is a great optimisation - you might think that there is some overhead to a function call in some hot path of a loop, but the compiler is able to just paste the function in the code to remove that if it decides that's a good thing to do. One of the big problems with Objective-C was that the compiler couldn't inline anything; it was so dynamic you could replace anything at runtime.

So yeah, I'm not saying algorithms aren't important, but the actual source code of the algorithms that you write really only affects performance insofar as it helps the compiler reason about optimisations (does that make sense?). The level of abstraction shouldn't matter.

When using Swift, and learning about SIL, you get the feeling it was built from LLVM up rather than expressive-language down. The Swift primitives like Int and Float map directly to LLVM primitives (that's why something like an Int increment should certainly have no cost when compared to C). But that has a big upside - that the compiler has a huge amount of knowledge about your code, and is thus able to make deductions about your code that aren't possible with other programming languages. That's where their lofty goal of beating C for speed comes from - the idea that real-world Swift code will be faster than real-world C code because the compiler will be that much better at understanding your code.

With Swift, your friend will be able to right sort-of object-oriented code with no performance penalty. I say sort-of, because you need to make use of Swift's rich value types which are almost interchangeable with classes from other languages (except they don't support inheritance; they are static types). If he does, he can make use of zero-cost abstractions - wrapping his value in a struct and giving it instance methods will take no extra memory, and the instance methods are all 'final' and will be inlined (so as if the functions were never split up to begin with).

I would recommend reading/watching this about zero-cost abstractions: https://realm.io/news/swift-summit-airspeed-velocity-zero-cost-abstractions/

Basically, he shows exactly what you describe - taking a coding challenge to sort the hex digits in a 64-bit integer, abstracting it with a struct and the standard library MutableCollection protocol. He talks about it more in a different blog post, but the upshot is that the abstraction really is free, and that it performs roughly equivalently to the same code in C when you use the same sort function (maybe not quite as good, but that's probably down to general optimisations than a structural overhead caused by the abstraction).