Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Cool news. Hope to see it expanded as much as possible as time goes on. I have to try it first though before I judge however :)

Also, minor mistake, but you specified "Ubuntu 14.01", which doesn't exist. There's only 14.10 and 14.04.
 
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
 
But it's a bit disingenuous to say iOS is a result of 30 years of hard work. Forstall and his team did use OS X to engineer iOS, but the revolutionary part about iOS was the touch interface, not the fact that a desktop OS was ported to a mobile OS (we had Windows Mobile already). And that touch interface was new, not something that had been in development had NeXT.
Touch interface doesn't affect the fact that iOS shares the core with OS X and it dates back to NeXTSTEP.
 
  • Like
Reactions: Elbon and usamaah
I started learning Swift and made my first music player for OS X. It's not easy as people say it is. The main problem I have with coding is what functions to use. Sure the documentation is there but it doesn't really say how to actually use that function.

And something I noticed with Swift is that you have to write your code in a certain way. Xcode kept complaining about using this form instead or this form has been deprecated. So you are kind of controlled in a way.
 
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

The new for loops with range are very easy and intuitive... if you are used to Python. I think that is were the inspiration came from. Seems to me that Swift 1 tried to get both C and Python loops into one, and now they decided to go with only the latter. It is just a matter of getting used to it, it is not more or less complex than C.
 
Swift 3, yay. New code to learn :D

I've wanted to become a Mac developer for years and years, but just never had the time and energy to take the huge leap towards the complex C-based syntax. I learned C++ in college, and I'm a professional PHP developer these days. Learning Objective-C's syntax was just too much of a task to take on. Swift changes that.

With Swift being multi-platform, the future looks extremely bright for the language.
 
  • Like
Reactions: chrismail627
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.

They incorporate some code from FreeBSD, yes. But that's a direct bloodline, or else I could say that iOS has been in the making since the dawn of History.
[doublepost=1464828780][/doublepost]
But it's a bit disingenuous to say iOS is a result of 30 years of hard work. Forstall and his team did use OS X to engineer iOS, but the revolutionary part about iOS was the touch interface, not the fact that a desktop OS was ported to a mobile OS (we had Windows Mobile already). And that touch interface was new, not something that had been in development had NeXT.

I agree though, moving iOS to Swift is unlikely for some time. Apps definitely.

That matters what?

iOS has OS X code, so reprogramming that code in Swift is a big PIA.

I won't say that it might be beneficial, because writing in Swift guides the programmer to write safer code.
 
  • Like
Reactions: usamaah
I'm a programmer by trade and have not directly worked with Swift or learned it but from the snippets I have seen it really doesn't seem at all intuitive in syntax or anything really. It sort of seems all over the place all at once and lacking focus. I guess I just don't see what makes it a great language or easier to learn or even something that 'should' be faster then anything else.


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).
 
  • Like
Reactions: 762999 and Mactendo
I prefer Rust. It's similar to Swift without the influence of Objective-C.
I don't see so much Objective-C influence in the core Swift language itself. It's just that for now, the vast majority of the code you write will necessarily interact with Objective-C APIs (Foundation, AppKit). I suppose you could say that some parts of Foundation included in Swift are parallel, for example String (from NSString), but I also think Foundation is a very well-written API so it doesn't bother me. Many function names do carry the verbosity of Objective-C, but with modern IDEs with code completion I don't see what the problem is, it makes the code more readable and maintainable, and labeled arguments are a huge boon for productivity.
 
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?
 
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.

As far as the OS being written in Swift, I would bet that it isn't written in Objective C either. Some where I remember UNIX being originally coded in K&R C, or at least grew using that language.

From Wikipedia:

"C was originally developed by Dennis Ritchie between 1969 and 1973 at Bell Labs,[5] and used to re-implement the Unix operating system."

I also understand that the NEXT and OSX has its roots in UNIX behind all the fancy UI API.

From Wikipedia again:

"Early versions of NeXTSTEP used an "NX" prefix and contained only the Application Kit, relying on standard Unix libc types for low-level data structures. OPENSTEP remained NeXT's primary operating system product until they were purchased by Apple Computer in 1996. OPENSTEP was then combined with technologies from the existing Mac OS to produce Mac OS X. iPhone and iPad's iOS is also a descendant of OPENSTEP, but targeted at touch devices."

Will Swift change OS X or iOS?
No, just how apps and programs can be written and somewhere under all the GUI and API stuff still resides good old UNIX and C.
 
Last edited:
As far as the OS being written in Swift, I would bet that it isn't written in Objective C either.
The kernel is written in C, with the drivers (IOKit) being C++. The lower-level UI code (CoreGraphics) is written in C++, but only has headers for C. I don't know what the old Display PostScript UI was written in, but I'm guessing C. The file and socket APIs from the Mach side and the BSD side are C.

And K&R C… *shudder* I very much prefer C99, thankyouverymuch.
 
I'm a programmer by trade and have not directly worked with Swift or learned it but from the snippets I have seen it really doesn't seem at all intuitive in syntax or anything really. It sort of seems all over the place all at once and lacking focus. I guess I just don't see what makes it a great language or easier to learn or even something that 'should' be faster then anything else.
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]
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

Yeah I have to agree - Swift 2 breaks a lot of conventions that Swift 1 maintained and not for the better.
[doublepost=1464844659][/doublepost]
I started learning Swift and made my first music player for OS X. It's not easy as people say it is. The main problem I have with coding is what functions to use. Sure the documentation is there but it doesn't really say how to actually use that function.

And something I noticed with Swift is that you have to write your code in a certain way. Xcode kept complaining about using this form instead or this form has been deprecated. So you are kind of controlled in a way.
The Obj-C documentation isn't any better, to be fair. Apple's SDK documentation is rather terrible tbh. But alas, that's what Google's for. As for syntax, that's mostly due to type-safety which Obj C doesn't seem to care nearly as much about
 
Even older than that. OS X/iOS userland is based on BSD, originally 1977, which traces back to the original AT&T UNIX, 1971.

Not that far back. NeXTSTEP/Openstep Mach is BSD 4.3 userspace.
[doublepost=1464847178][/doublepost]
The kernel is written in C, with the drivers (IOKit) being C++. The lower-level UI code (CoreGraphics) is written in C++, but only has headers for C. I don't know what the old Display PostScript UI was written in, but I'm guessing C. The file and socket APIs from the Mach side and the BSD side are C.

And K&R C… *shudder* I very much prefer C99, thankyouverymuch.

Display Postscript was a combination of C and Postscript. The C was 89 and very custom, not K&R.
[doublepost=1464847685][/doublepost]
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.

As far as the OS being written in Swift, I would bet that it isn't written in Objective C either. Some where I remember UNIX being originally coded in K&R C, or at least grew using that language.

From Wikipedia:

"C was originally developed by Dennis Ritchie between 1969 and 1973 at Bell Labs,[5] and used to re-implement the Unix operating system."

I also understand that the NEXT and OSX has its roots in UNIX behind all the fancy UI API.

From Wikipedia again:

"Early versions of NeXTSTEP used an "NX" prefix and contained only the Application Kit, relying on standard Unix libc types for low-level data structures. OPENSTEP remained NeXT's primary operating system product until they were purchased by Apple Computer in 1996. OPENSTEP was then combined with technologies from the existing Mac OS to produce Mac OS X. iPhone and iPad's iOS is also a descendant of OPENSTEP, but targeted at touch devices."

Will Swift change OS X or iOS?
No, just how apps and programs can be written and somewhere under all the GUI and API stuff still resides good old UNIX and C.

OPENSTEP was the Standard jointly developed with Sun Microsystems who ported NeXTSTEP 4.0 (OPENSTEP Standard compliant) fully as a replacement to Solaris. Relationships soured and the partnership dissolved.

OPENSTEP 4.0 had a lot of promising projects that never made it out to general release. We used them internally at NeXT. OPENSTEP for Consumer/Devs ultimately rolled out as Openstep compliant APIs with Foundation/AppKit, etc., on top of NeXTSTEP 3.3. Openstep was then ported to Windows for the 4.1 release, etc.

NX wasn't just for AppKit. It wasn't until Openstep Foundation Kit was fully realized that an equivalent to AppKit for low system APIs was ready.
 
  • Like
Reactions: RedWeasel
Before OS X, there was NeXTSTEP, a project that started in 1985 with the foundation of NeXT.

The Open-Source Mach microkernel first release was in 1985.
Yeah, but you said iOS not OS X ;)
By that line go back more to UNIX then go back some more to whatever else.
 
It is vanishingly unlikely that an OS will be written in Swift within the next 10 years. I suspect that some of the user-facing applications (think Stocks and Calculator) in iOS will be rewritten over time using it for ease of maintenance. The core of the OS will probably stay Objective-C (and plain C and maybe some assembler) for the foreseeable future.

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.
I'm a programmer by trade and have not directly worked with Swift or learned it but from the snippets I have seen it really doesn't seem at all intuitive in syntax or anything really. It sort of seems all over the place all at once and lacking focus. I guess I just don't see what makes it a great language or easier to learn or even something that 'should' be faster then anything else.

You are joking right ? Swift has the cleanest and most logical syntax out of all the programming languages, by far.
 
But it's a bit disingenuous to say iOS is a result of 30 years of hard work. Forstall and his team did use OS X to engineer iOS, but the revolutionary part about iOS was the touch interface, not the fact that a desktop OS was ported to a mobile OS (we had Windows Mobile already). And that touch interface was new, not something that had been in development had NeXT.

I agree though, moving iOS to Swift is unlikely for some time. Apps definitely.

Otherwise you could reason back to Adam en Eve........
 
Its more of Swift 0.5 IMO rather than Swift 3.0, as the language is far from being complete. I assume it will take until Swift 5.0 or so at this pace, but Apple is getting there. Their pragmatic approach of delivering a working set of tools and slowly refining them into a feature-complete language makes sense. Swift is definitely usable at this point and this release brings a number of important refinements. At any rate, the Swift team is doing a very good job while being very open on their decision making.
 
My programming goes way back to punch cards and waiting in the que to see if the code will run so I appreciate any changes which streamline the process of developing a useable product. Right now my one single wish for Apple's Swift is that it be able to run inline with objectiveC.

What I mean is there needs, no there must be a compiler command to drop some Swift code into an objectiveC code file. Then there must also be a way to call Swift objects in objectiveC by the standard of #import and objectiveC calls to the Swift Object.

Right now it seems a project, in practicality, must be one or the other, Swift or ObjectiveC.
 
If you guys would read the release blog, you'd see that 3.0 is going to be canonical... there are no more changes that break prior versions unless the change runs the gauntlet. It looks like style is set in stone, and that's a really healthy approach. Considerable changes on an annual basis aren't good for a language, so to see this new philosophy makes me want to dig in more. I won't need to unlearn the bad habits that existed in transition, and 3.0 sounds as if it will stand on its own.

At least, that's how I read it. I hope this is the case.
 
Does anyone think iOS 10 will be completely rewritten with Swift 3.0?

Very funny. iOS will never be rewritten in Swift. That would be insanity.
[doublepost=1464871838][/doublepost]
My programming goes way back to punch cards and waiting in the que to see if the code will run so I appreciate any changes which streamline the process of developing a useable product. Right now my one single wish for Apple's Swift is that it be able to run inline with objectiveC.

What I mean is there needs, no there must be a compiler command to drop some Swift code into an objectiveC code file. Then there must also be a way to call Swift objects in objectiveC by the standard of #import and objectiveC calls to the Swift Object.

Right now it seems a project, in practicality, must be one or the other, Swift or ObjectiveC.
False.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.