Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

CutterSlade

macrumors regular
Mar 13, 2014
161
0
Istanbul, Turkey
So you skipped over tuples and multiple return types then? Case statements that allow if statements as part of validation? While not show stoppers in Obj-C, I've certainly coded around shortcomings that won't exist thanks to these new features.

No, I already said that it has some nice features there's no denying that. For now, the most important ones for me are the ones you mentioned and also the ability to assign values to sub-properties directly, lack of which in Obj-C has been annoying me for a long time. My main problem with Swift is its Syntax. I found it neither intuitive to use nor easy to read. I feel like it will be counter-productive for me to switch. Maybe I'll change my mind in the future.

Besides, the real time investment is learning all the APIs involved with iOS and OS X, as well as the MVCS design pattern, delegation, target-action, and notifications. Swift or Objective-C is just different string used to tie API objects together.

That's true for newcomers. But if you already know the platform, the only thing left for you to learn is the language, which we already did once.

With the introduction of Swift, the newcomers to the platform now have to learn 2 languages in addition to the platform itself. This will change in the following years of course but the transition will be painful.
 

CutterSlade

macrumors regular
Mar 13, 2014
161
0
Istanbul, Turkey
Here swift solve it because it guarantte: 1) All objects are initialized before it first use 2)If something could be NULL, then is because the programmer, not the stupid compiler, say so. And it need to be handle the case where if something expected to be something instead is NULL.
Yet, even when using optionals, you still have to use if's to check whether the optional value contains a value or nil. Another problem with the optionals is the fact that all objects from Objective-C APIs are returned as implicitly unwrapped optionals and hence the compile-time checks will become useless for them.
 

PBG4 Dude

macrumors 601
Jul 6, 2007
4,275
4,501
No, I already said that it has some nice features there's no denying that. For now, the most important ones for me are the ones you mentioned and also the ability to assign values to sub-properties directly, lack of which in Obj-C has been annoying me for a long time. My main problem with Swift is its Syntax. I found it neither intuitive to use nor easy to read. I feel like it will be counter-productive for me to switch. Maybe I'll change my mind in the future.

Agree on the syntax for sure, especially with the latest additions to obj-c making it much easier to deal with arrays and dictionaries. I'm chewing on Swift syntax slowly, because I like how it handles blocks better than obj-c. Maybe we won't need a http://www.goshdarnblocksyntax.com for Swift. :)


That's true for newcomers. But if you already know the platform, the only thing left for you to learn is the language, which we already did once.

With the introduction of Swift, the newcomers to the platform now have to learn 2 languages in addition to the platform itself. This will change in the following years of course but the transition will be painful.

The lack of Swift tutorials will definitely be an issue at first, but Ray Wenderlich is already digging into it so I expect some awesome articles once Xcode 6 hits public release. :)

I'm 1/4-1/3 my app right now, so I'm kind of in a zone, but part of me wants to try a master-detail tableview pair in Swift just because. :)

----------

Yet, even when using optionals, you still have to use if's to check whether the optional value contains a value or nil. Another problem with the optionals is the fact that all objects from Objective-C APIs are returned as implicitly unwrapped optionals and hence the compile-time checks will become useless for them.

That's the one thing that's bugging me, switching from obj-c's elegant handling of nil to Swift's ?s everywhere. Basically, I have to test for nil everywhere with little ? notations.
 

mamcx

macrumors regular
Mar 13, 2008
210
28
Sincere question: to a real-world user, what does "faster programs" mean? Would an app that is written in newer code, perform its functions "quicker" than if it were written in an older language - or are you simply saying that the front-end, designing/programming part is quicker?

Could be both. But, how much and if can be noted by the eye of a human is another mather.

A computer is a machine, and computer language is a tool that build machines. Some could "spin" faster and/or be more efficient and/or be able to do several things at onces, but all depend in how the developer(s) across ALL the paths in the software have done his tasks.

So, like in a automated/robotic car manufacturing plant, each "robot" is a diferent program, and some could be better than others. Like as some web pages load faster with browser X than Y (after the whole downloading of data).

The key thing is: A computer language (or more exactly, the compiler and/or interpreter) are also programs/machines and some do a better job than anothers, but have difference in what kind of task are better, ie: Some are truly amazing at handle concurrent/parallel tasks, like erlang that is used in WhatsApp, and some others "spin" faster like C, and others parse a document better as with haskell or ocalm, so you can't have a compiler best at everything.
 

Cromulent

macrumors 604
Oct 2, 2006
6,802
1,096
The Land of Hope and Glory
Sincere question: to a real-world user, what does "faster programs" mean? Would an app that is written in newer code, perform its functions "quicker" than if it were written in an older language - or are you simply saying that the front-end, designing/programming part is quicker?

It depends.

Sometimes it means that programs execute faster on the hardware and other times it means that it is faster for the developer to write code in the programming language. The holy grail of programming is a language that is easy to write correct code for whilst still maintaining performance when executing the compiled / interpreted code on the hardware.

Some people mistakenly think that newer languages equal faster code execution but that is not always the case. C, C++ and Fortran are well known for producing high performance code due to their optimising compilers. Yet Fortran was first developed in the 1950's, C in the 1970's and C++ in the 1980's.

Of course real performance gains come when developing the algorithms you use in your code. You could write a badly designed program in C and a well designed program in Python or some other interpreted language and depending on the gravity of the problem the Python code may well out pace the C code.

There is more to programming than just the language. This is why studying data structures and algorithms is such an integral part of computer science courses.

Edit: Beaten by a minute :).
 

CutterSlade

macrumors regular
Mar 13, 2014
161
0
Istanbul, Turkey
Agree on the syntax for sure, especially with the latest additions to obj-c making it much easier to deal with arrays and dictionaries. I'm chewing on Swift syntax slowly, because I like how it handles blocks better than obj-c. Maybe we won't need a http://www.goshdarnblocksyntax.com for Swift. :)
Yeah, blocks are definitely an exception. I hated their horrible syntax in obj-c, just like I hated the function pointer syntax in C++ :) Swift counterparts of these are so much better.


The lack of Swift tutorials will definitely be an issue at first, but Ray Wenderlich is already digging into it so I expect some awesome articles once Xcode 6 hits public release. :)

I'm 1/4-1/3 my app right now, so I'm kind of in a zone, but part of me wants to try a master-detail tableview pair in Swift just because. :)

I think there will be more than enough tutorials on the web by the time it is released. Even now people have started competing with each other to post about Swift in their blogs earlier :)

I would wait even more after its official release before trying to use it in a production environment. Even though it has been in development about 4 years, it will surely get important updates after the feedback that will come from the masses.

That's the one thing that's bugging me, switching from obj-c's elegant handling of nil to Swift's ?s everywhere. Basically, I have to test for nil everywhere with little ? notations.

Either that, or you'll go all !s just like they did with in the SDK :)
 

ArtOfWarfare

macrumors G3
Nov 26, 2007
9,564
6,062
Yet, even when using optionals, you still have to use if's to check whether the optional value contains a value or nil. Another problem with the optionals is the fact that all objects from Objective-C APIs are returned as implicitly unwrapped optionals and hence the compile-time checks will become useless for them.

The thing is, you shouldn't often be using optionals. Most of your code should be handling things that will never be null and so weren't labeled as optionals. The places you need to check if an optional is null or not are places where you needed to check if your variable is null or not anyways.

It ensures that:

1 - You never write code that doesn't check for null that should have. If this wasn't ensured, you could have bugs that never show up prior to release, but your customers end up having your app crash on them.

2 - You never write code that uselessly checks for null when you shouldn't. Not a big issue to your customer as the performance hit from this is minimal, but it makes your code more difficult to read/maintain than necessary.

Optionals are genius and are one of the biggest appeals of using Swift over Java. I suspect the two languages Apple was going after with Swift were Python and Java - Java is tempting developers away from programming for iOS and instead programming for Android, while Python is just tempting developers to write code with non-native looking UIs.
 

CutterSlade

macrumors regular
Mar 13, 2014
161
0
Istanbul, Turkey
1 - You never write code that doesn't check for null that should have. If this wasn't ensured, you could have bugs that never show up prior to release, but your customers end up having your app crash on them.

2 - You never write code that uselessly checks for null when you shouldn't. Not a big issue to your customer as the performance hit from this is minimal, but it makes your code more difficult to read/maintain than necessary.

The only thing it does is changing the location where you have to think about the values a variable can have. In obj-c, you do it right after assigning something to the variable, while in Swift you do it when declaring the variable. If you forget to assign the value of the implicitly unwrapped optional returned from a method in the SDK to a variable defined with ?, the compile time checks are not gonna catch anything.

(2) is not an issue since not many people would add nil checks unless it is necessary.

I don't think that optionals are that big of an addition, but mightl get in the way by forcing you to use ?s and !s in a lot of places.

Btw, I would choose Objective-C over Java anytime, but that's my opinion. I like the dynamic nature of obj-c and the fact that it isn't a type-safe language. It's both a blessing and a curse but I prefer it to using a type-safe language with generics which leads to longer and harder to read code.
 
Last edited:

mrxak

macrumors 68000
I've read all there is to read on Apple's website, but being that I'm not a developer, I still don't concretely understand the real world benefit here.

Are there a few people from the developer community out there who can explain the change to us as if they're talking to a 5 year old?

I'd love to grasp the impact in a more concrete way.

Apple developing a new programming language that's "simpler, faster, easier" etc sounds great and sets off fireworks on the blogs.. but I'm trying to really gauge exactly what the jump is.

I'll explain what I see as the three biggest benefits as succinctly as I can.

The first thing is safety. The language has very strict rules about defining your intent with code you write. When you go read your code days or years later, the language forced you to be very clear what you meant to do so it's a lot easier to use functions or reuse code without making mistakes and causing bugs. Also, since your intentions are so clear, the compiler can do additional sorts of checks that just aren't possible in some other languages. When you go to compile your project, the compiler will pop up errors that immediately point to where you have problems you might never otherwise be able to track down when they start popping up in a another languages's compiled, running program. There are other aspects of safety built into Swift, such as the way memory is handled (initializations, optionals, automatic reference counting...), but those are two of the easiest to understand for a 5 year old.

The second thing is expressiveness. The language allows you to express complex logical ideas in rather elegant ways. You can type less to get the same results, and what you type is a lot easier to read as a human being. Bear in mind, this also relates to safety, above. Because complexity is expressed in a short, human-readable way, it's far more easy to identify bugs, or avoid making them to begin with.

The third thing is optimization. The language seems designed from the ground up to produce highly optimized compiled applications. This is accomplished through a variety of ways, but the expressiveness and safety of the language feed into that goal. The better you can express your intentions to the compiler, the more optimizations the compiler can make on your code.


So that's basically why most people are excited about Swift. It should save skilled developers time, and it should also guide less experienced developers into making fewer mistakes. Debugging should be easier for both. The compiled code may be a little faster running.

No developer with a huge amount of Objective-C code is going to rewrite all of it. They may or may not rewrite sections in Swift as they go in and debug or otherwise update existing code. Many developers may choose to start a new project entirely in Swift. The biggest thing to take from all of this is there are now two language options with "first class citizen" status for Apple development. More choices are always good. No one language is perfect for all projects, and developers now have a choice of another language to use that may or may not offer significant advantages. I think in the long run Swift will get most of the attention by developers and Apple itself, but it's still very new and it'll take some time to figure out just how advantageous it really is.

The downsides of course should be obvious. It takes time to learn a new language, and that time takes away from development time. Because the language is new there's very few resources and documentation is relatively scarce. The only people with any experience using the language are working for Apple, so companies can't just hire experienced Swift programmers like they can Objective-C programmers.
 

joejoejoe

macrumors 65816
Original poster
Sep 13, 2006
1,428
110
wow. lot's of really helpful responses here, even amidst the snark.

thanks guys!
 

whooleytoo

macrumors 604
Aug 2, 2002
6,607
716
Cork, Ireland.
For the end-user, the only direct benefit is that programmes written in Swift should be slightly faster.

However, anything that makes things easier for the developer can have indirect benefits for the end-user.

More familiar syntax:
- The syntax is simpler, cleaner and more like other popular OO languages (C++ / C# / Java). The syntax is also a bit more script-language-like and the REPL should appeal to programmers coming from scripting backgrounds. This could mean more programmers giving it a go rather than being put off by Obj-C's unusual syntax (even though it never was that hard to learn, but was a disincentive to many). -> More devs, more software.

Simple, powerful features:
- Swift gathers in / copies a lot of features from other, more recent languages; and introduce a few of its own. Some help a lot in code-clarity. Some help eliminate common coding errors. Some features - I love the power of the new switch statement - enable devs to shrink a complex series of statements into just a handful that are quicker to write and easier to read (and so, maintain). -> Less time focusing on "how do I do it?" and more on "what do I want to do" and QA. -> better quality software.
 

ArtOfWarfare

macrumors G3
Nov 26, 2007
9,564
6,062
If you forget to assign the value of the implicitly unwrapped optional returned from a method in the SDK to a variable defined with ?, the compile time checks are not gonna catch anything.

No... that doesn't sound right to me. You're saying methods in the SDK could return nil but aren't marked as optionals? That would suggest a defect in Apple's SDK. I haven't actually looked at the new SDKs yet - I've only been reading the swift manual (don't even have Xcode 6 yet - planning on remedying that tonight).
 

philosopherdog

macrumors 6502a
Dec 29, 2008
737
517
Don't get too excited. You'll pretty much have to know 2 languages to use it for the foreseeable future, or realistically 3: C, Objective C and Swift. In the short run it's going to be a lot of pain with so much code, including the whole SDK, written in Objective C. Sure they provide Swift headers, but from what I'm seeing you now need to know both languages to build anything. So, easy I'm not sure about that. The language itself is a lot simpler to learn initially. But since you can do more crazy things in enums, structs, etc it also provides a bit more rope for people to hang themselves if they don't know what they're doing. Anyhow, it's obviously a move Apple needs to make since objective c lacks the expressiveness of the higher level languages like Ruby. Playgrounds, showing code in real time, and being able to type in code at the command line are awfully nice for learning a language. At the end of the day, no language is hard to learn. It's the SDK that takes all of the time and energy to learn. This hasn't changed. Indeed, since much of the sample code and tutorials written out there are all in objective c things will take a while to settle. Personally, I think the barrier to entry just got higher, not lower. Going forward this will change, but it will take a few years. I'm personally excited, but I have a few years with objective c already. Objective c isn't going away anytime soon.
 

D.T.

macrumors G4
Sep 15, 2011
11,050
12,460
Vilano Beach, FL
...tuples and multiple return types...

Yeah, I just read about those features, good stuff.

My main problem with Swift is its Syntax. I found it neither intuitive to use nor easy to read. I feel like it will be counter-productive for me to switch. Maybe I'll change my mind in the future.

It felt pretty natural for me, I guess it depends on your exposure to other languages[?] For my "non-enterprise" projects (which are all C#/.NET) I use Ruby+Rails|Sinatra [mostly] or Python/Django [occasionally].

Maybe we won't need a http://www.goshdarnblocksyntax.com for Swift. :)

Hahaha, I didn’t know about the PG rated alias, I’ve got the, *ahem*, harsher name bookmarked. :D
 

CutterSlade

macrumors regular
Mar 13, 2014
161
0
Istanbul, Turkey
No... that doesn't sound right to me. You're saying methods in the SDK could return nil but aren't marked as optionals? That would suggest a defect in Apple's SDK. I haven't actually looked at the new SDKs yet - I've only been reading the swift manual (don't even have Xcode 6 yet - planning on remedying that tonight).

No, I'm saying that they return implicitly unwrapped optionals. I haven't tried the SDK's much either and instead have been reading the manual just like you, but that seems to be the case after reading the docs and the problems people having in the web.

----------

It felt pretty natural for me, I guess it depends on your exposure to other languages[?] For my "non-enterprise" projects (which are all C#/.NET) I use Ruby+Rails|Sinatra [mostly] or Python/Django [occasionally].
Yes, that definitely depends one the languages one used to code in. I've never had anything to do with Ruby or Python but used a lot of C/C++/Obj-C/Java/Javascript/PHP all of which except Obj-C have a very similar, C-like syntax.
 

ArtOfWarfare

macrumors G3
Nov 26, 2007
9,564
6,062
Yes, that definitely depends one the languages one used to code in. I've never had anything to do with Ruby or Python but used a lot of C/C++/Obj-C/Java/Javascript/PHP all of which except Obj-C have a very similar, C-like syntax.

I expect that most developers in the world are like you, and so they will need additional guidance to Swift. This language is definitely better than all of the ones you know so far, except perhaps PHP which I'm not familiar with so I couldn't say for certainty (but it probably is better than that, too).

It's in the same league of greatness that Python is. The type safety is great, but a lot of the syntax looks so much more heavy and unnecessary. Why brackets all over - why can't they use Python indent/dedent system? There's a keyword that has an @ in front of its name - can't remember which, but that's freaking ugly. There's a lot of useless commas all over the language (although, to be fair, Python also has a lot of unnecessary commas). For examples of languages that demonstrate how the comma is totally worthless, see a lisp language (such as Racket).
 

CutterSlade

macrumors regular
Mar 13, 2014
161
0
Istanbul, Turkey
I expect that most developers in the world are like you, and so they will need additional guidance to Swift.
That's true, except we'll need more time to get used to it rather than guidance. I'm not having much problems understanding it, I just didn't like its syntax that's all.

This language is definitely better than all of the ones you know so far, except perhaps PHP which I'm not familiar with so I couldn't say for certainty (but it probably is better than that, too).

It's in the same league of greatness that Python is. The type safety is great, but a lot of the syntax looks so much more heavy and unnecessary. Why brackets all over - why can't they use Python indent/dedent system? There's a keyword that has an @ in front of its name - can't remember which, but that's freaking ugly. There's a lot of useless commas all over the language (although, to be fair, Python also has a lot of unnecessary commas). For examples of languages that demonstrate how the comma is totally worthless, see a lisp language (such as Racket).

Well, these are all subjective and different people might have different preferences when it comes to a language depending on the programming practices and patterns they use. There's no right or wrong here.

I agree that there are way too many unnecessary commas in Swift but can't say the same thing about the brackets. I think that an indentation based system makes things harder to read.

Btw, I think that the keyword you were referring is @lazy
 
Last edited:

whooleytoo

macrumors 604
Aug 2, 2002
6,607
716
Cork, Ireland.
That's true, except we'll need more time to get used to it rather than guidance. I'm not having much problems understanding it, I just didn't like its syntax that's all.



Well, these are all subjective and different people might have different preferences when it comes to a language depending on the programming practices and patterns they use. There's no right or wrong here.

I agree that there are way too many unnecessary commas in Swift but can't say the same thing about the brackets. I think that an indentation based system makes things harder to read.

Btw, I think that the keyword you were referring is @lazy

Or @final!

I do agree on the indenting, ever since Fortran I've been distrustful of code where formatting changes could lead to compilation or runtime errors. :)
 

firewood

macrumors G3
Jul 29, 2003
8,109
1,346
Silicon Valley
Are there a few people from the developer community out there who can explain the change to us as if they're talking to a 5 year old?

Programming and programming languages in general are hard to explain to a 5 year old. I'd say the Objective C was like a toolbox used to solve problems and make apps.

But these tools were getting rusty and old-fashioned looking, and programmers more than occasionally cut themselves while using them. Swift is a toolbox of new, shiny, tools (also for saving the same kinds of problems and making the same kinds of apps) that are safer to use, and easier to play with to learn how to use them. And in need of less typing with those silly punctuation keys.

(corresponding to more compile time checks, the Xcode REPL/Playground, and briefer, less noisy syntax...)
 
Last edited:

ArtOfWarfare

macrumors G3
Nov 26, 2007
9,564
6,062
The swift is very good at flying. It spends all of its time in the air.

Read more about Swift on The Simple English Wikipedia Page

simple.png


Also this
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.