iOS Starting to dig into Swift... it sucks.

[grandM]

Ok, it's been a while since I studied C++, but can't you use operator overload to add two strings using that syntax?

So Swift is changing the way C works, as C would see two pointers and add the two pointers vs Swift would look at what the pointers point to and see two string and add two strings.

Actually swift takes a more human approach. The + operator concatenates two strings as you would expect to if you were not schooled into programming. Same with dictionaries. I vaguely recall that a copy of a NSDictionary could lead to problems as pointers were still involved. Caution was advisable. In swift you seldomly must talk about a pointer. It makes sense when you think about it. The memory optimization might be less optimal the developer his life became easier. Swift should worry about the memory. Hence a logical step after ARC. An Objective-C without pointers seems hard to imagine.

 

[1458279]

One thing that I just came across with Swift is that you can go back to function based programming. I found this interesting as most languages left function based programming many years ago.

I'm actually a big fan of function based programming as most programmers didn't use OPP as it was fully intended. OPP allows a programmer to create usage rules that the compiler can enforce, like accessing data and methods (public vs private). Most programs that I've seen haven't used these well, they seem to just see the rules as something to work around.

I've always seen OPP as a solution to large complex programs. A solution where there's a set of rules for controlling access to parts of code and to encourage code reuse. However, I don't know if there is anything OPP can do that function based can't do.

It'll be interesting to see how much function based programming happens in Swift.

 

[PizzaBoxStyle]

Tim Cook: "You or I could write an app" with Swift, Apple's new developer language.

func performIntegerOperation(operation: (Int, Int) -> Int, a: Int, b: Int) -> Int {
  return operation(a, b)
}

I look forward to Tim Cook's executive summary for those three lines of code do. That's right... go on now... really... the answer is right in front of you! Silence, ayyy?

Well, let's try this one:

infix operator <==> { precedence 130 associativity left }

Not getting that one either? Yeah, I understand, Mr. Cook. Operator overloading made more sense under C++ syntax, in my own opinion.

Myself? I've done two video courses on Swift (v1 and v2), and read through most of the Swift book Apple published. But I still just can't get behind it, and I don't know exactly why, but I'll try to articulate a few of my concerns.

• When I look at everything Swift can do, all I can think is "...this is a language that is replacing words with goddamn symbols, man! It's like ASCII art in the form of executable code! WHY ARE WE MOVING TO THIS?!!!!!"
• The constant LYING coming from Apple about this language.
  • Remember when Swift was production ready, and going to instantly remake programming from day one? But then we found out that things like incremental compiling didn't make the list.
  • Remember when Apple (and then the press) said that Swift was an easy language that anyone could use? Then, surprise, it's a functional language! Real hard, makes even competent programmers cringe and sweat.
  • The fact that Apple keeps insisting that this is a good language to learn how to program on in academic environments, yet provides no Windows compiler (MS may step in to fill this role with their Islandwood (?) initiative anyway...), and does things like removing the damn FOR loop construct from Swift 3.0 (a change that took them only a matter of days to decide on). (Everything is a for-in/foreach now!)
  • "Objective-C, without the C!" Except Objective-C is an object-oriented language, and Swift seems to be going the functional route.
• Like JavaScript, it seems like this language is working in ways that people (even greenhorns who have not mastered any other language) might not be expecting. Keeping my eye out for future books with titles like "Apple Swift: The Good Parts" as well as libraries like "sQuery" to fill in and abstract all of the nasty and boneheaded things this language is doing.

I'm going to keep trying to love Swift, and maybe I eventually will. Two years in though and I still wish they had just given us a better Objective-C. An Objective-C that maybe pulled ideas from Swift, but maintained it's overall self.

 

[1458279]

Tim Cook: "You or I could write an app" with Swift, Apple's new developer language.

func performIntegerOperation(operation: (Int, Int) -> Int, a: Int, b: Int) -> Int {
  return operation(a, b)
}

I look forward to Tim Cook's executive summary for those three lines of code do. That's right... go on now... really... the answer is right in front of you! Silence, ayyy?

Well, let's try this one:

infix operator <==> { precedence 130 associativity left }

Not getting that one either? Yeah, I understand, Mr. Cook. Operator overloading made more sense under C++ syntax, in my own opinion.

Myself? I've done two video courses on Swift (v1 and v2), and read through most of the Swift book Apple published. But I still just can't get behind it, and I don't know exactly why, but I'll try to articulate a few of my concerns.

• When I look at everything Swift can do, all I can think is "...this is a language that is replacing words with goddamn symbols, man! It's like ASCII art in the form of executable code! WHY ARE WE MOVING TO THIS?!!!!!"
• The constant LYING coming from Apple about this language.
  • Remember when Swift was production ready, and going to instantly remake programming from day one? But then we found out that things like incremental compiling didn't make the list.
  • Remember when Apple (and then the press) said that Swift was an easy language that anyone could use? Then, surprise, it's a functional language! Real hard, makes even competent programmers cringe and sweat.
  • The fact that Apple keeps insisting that this is a good language to learn how to program on in academic environments, yet provides no Windows compiler (MS may step in to fill this role with their Islandwood (?) initiative anyway...), and does things like removing the damn FOR loop construct from Swift 3.0 (a change that took them only a matter of days to decide on). (Everything is a for-in/foreach now!)
  • "Objective-C, without the C!" Except Objective-C is an object-oriented language, and Swift seems to be going the functional route.
• Like JavaScript, it seems like this language is working in ways that people (even greenhorns who have not mastered any other language) might not be expecting. Keeping my eye out for future books with titles like "Apple Swift: The Good Parts" as well as libraries like "sQuery" to fill in and abstract all of the nasty and boneheaded things this language is doing.

I'm going to keep trying to love Swift, and maybe I eventually will. Two years in though and I still wish they had just given us a better Objective-C. An Objective-C that maybe pulled ideas from Swift, but maintained it's overall self.

TBH, I felt the same way about Swift. At this point, I think I came in with a chip on my shoulder. I've now gone thru a number of tutorials and started liking parts of it. It takes a bit to go back and forth between ObjC and Swift, but I can live with that.

The function part I'm ok with, I've done function based programming before and have no problem with it.

The syntax is odd, and I see no advantage to it. In fact, I'm not seeing a big advantage to Swift.

I've been programming for decades and a modern language is pretty much just for control into an API. It's great if it's fast and flexible, but most of what people do is API calls.

In one training video the guy said the language is only 20% of the code and API call are the rest.

In addition to that, you can use inline C (AFAIK). With ObjC, it was C, some say Swift is ObjC without the C, but it doesn't look like ObjC.

TBH, I'm also not a big fan of ObjC. I found it odd, but got over it.

I have to say I don't like the idea of not upgrading ObjC anymore. I just did a search the other day and it looks as if most are not going fully with Swift. There's a balance. If the jobs ask for Swift, they might not get advanced programmers. If they need advanced programmers, they might be stuck with ObjC and then they'll have legacy code that some Swift programmer won't know.

 

[eventailapp]

Tim Cook: "You or I could write an app" with Swift, Apple's new developer language.

func performIntegerOperation(operation: (Int, Int) -> Int, a: Int, b: Int) -> Int {
  return operation(a, b)
}

I look forward to Tim Cook's executive summary for those three lines of code do. That's right... go on now... really... the answer is right in front of you! Silence, ayyy?

I think it is not really Tim's job to explain programming to people, but what is the issue with those three lines? They are very simple if you know the Swift syntax. Also do not forget that for the same thing in Obj-C you would need to go look at http://****ingblocksyntax.com

Well, let's try this one:

infix operator <==> { precedence 130 associativity left }

Not getting that one either? Yeah, I understand, Mr. Cook. Operator overloading made more sense under C++ syntax, in my own opinion.

Operators have precedence and associativity. Also overloading operators was never recommended, it exists in Swift because most of the language is defined in the standard library.

Myself? I've done two video courses on Swift (v1 and v2), and read through most of the Swift book Apple published. But I still just can't get behind it, and I don't know exactly why, but I'll try to articulate a few of my concerns.

• When I look at everything Swift can do, all I can think is "...this is a language that is replacing words with goddamn symbols, man! It's like ASCII art in the form of executable code! WHY ARE WE MOVING TO THIS?!!!!!"

There is not that much symbols. Since first class functions are a thing in Swift it makes sense to have symbolic representation of their type.

• The constant LYING coming from Apple about this language.
  • Remember when Swift was production ready, and going to instantly remake programming from day one? But then we found out that things like incremental compiling didn't make the list.

I do not remember saying them that. I remember them saying that they offer binary compatibility and that is that, no promises and also an express warning that the syntax will change.

• Remember when Apple (and then the press) said that Swift was an easy language that anyone could use? Then, surprise, it's a functional language! Real hard, makes even competent programmers cringe and sweat.

Functional languages are the new gold. They are safer and simpler to understand than imperative languages (for beginners). They can also be faster. I know many competent programmers that would like to write everything in functional, if only they bosses would let them. In any case this is also quite a matter of taste.

• The fact that Apple keeps insisting that this is a good language to learn how to program on in academic environments, yet provides no Windows compiler (MS may step in to fill this role with their Islandwood (?) initiative anyway...), and does things like removing the damn FOR loop construct from Swift 3.0 (a change that took them only a matter of days to decide on). (Everything is a for-in/foreach now!)

The For-Next removal was quite straightforward. It has little use in a high level/functional language and the compiler can optimise for-each loops and high order functions better. There is no Windows compiler, yet. The language is open source and I think it is only a matter of time. Also, when I was learning programming we had both classes on Windows and Linux. Swift will be (I don't think it is there yet) a good language to learn because it is multi-paradigm and has playgrounds. Playgrounds still need more polish (I find them buggy and sluggish for now) but the "almost a REPL" experience is extremely valuable.

• • "Objective-C, without the C!" Except Objective-C is an object-oriented language, and Swift seems to be going the functional route.
• Like JavaScript, it seems like this language is working in ways that people (even greenhorns who have not mastered any other language) might not be expecting. Keeping my eye out for future books with titles like "Apple Swift: The Good Parts" as well as libraries like "sQuery" to fill in and abstract all of the nasty and boneheaded things this language is doing.

I'm going to keep trying to love Swift, and maybe I eventually will. Two years in though and I still wish they had just given us a better Objective-C. An Objective-C that maybe pulled ideas from Swift, but maintained it's overall self.

Swift does both objects and functions, what is there not to like? I am an OSX/iOS newbie but coming from C++ I really find Swift appealing. I find the strong typing and functional approach refreshing. In the end I think the most important thing is to try discovering the idiomatic Swift and ways to leverage the language. Trying to shoehorn Objective-C (or C) code in Swift is the wrong approach.

 

[bjet767]

I have been programming for decades, from COBOL, MASM, basic, C, C++, MSC, Objective C, some HTML, CSS, Java and tried Swift.

Personally I see no really good (programming wise) reason for Apple to jump on Swift other than to get a bunch of new coders for the their hardware. I don't find Swift syntax any easier or more "elegant" than Objective C, but the new young coders want to be different and innovative and this is what Swift offers. Swift actually adds some pain to the Apple process because now they have to support two languages to do the same things. Why would they want to do such a thing? Objective C is now old school and when a person is young, old school is just old school.

Basically what I am saying this, Swift is a marketing move designed to draw new blood into the Apple world.

BTW MASM was used to build tight and fast code for those old 8086 machines. It was used to write small functions which accessed hardware and memory locations directly and was not used to write a whole program.

 

[1458279]

I have been programming for decades, from COBOL, MASM, basic, C, C++, MSC, Objective C, some HTML, CSS, Java and tried Swift.

Personally I see no really good (programming wise) reason for Apple to jump on Swift other than to get a bunch of new coders for the their hardware. I don't find Swift syntax any easier or more "elegant" than Objective C, but the new young coders want to be different and innovative and this is what Swift offers. Swift actually adds some pain to the Apple process because now they have to support two languages to do the same things. Why would they want to do such a thing? Objective C is now old school and when a person is young, old school is just old school.

Basically what I am saying this, Swift is a marketing move designed to draw new blood into the Apple world.

BTW MASM was used to build tight and fast code for those old 8086 machines. It was used to write small functions which accessed hardware and memory locations directly and was not used to write a whole program.

I'm glad you posted this. IMO, a lot of new people didn't like ObjC. Apple knows that soon the phones will all start looking the same and the software will become king or at least the deciding factor.

Even if Swift were no easier to learn that ObjC, new people would see that it's at least "not ObjC" and that could be just what's needed to get them over the "fear of programming" and locked into Apple's eco system.

 

[eventailapp]

Personally I see no really good (programming wise) reason for Apple to jump on Swift other than to get a bunch of new coders for the their hardware.

I can't agree with that. Granted I have less experience than you (5 years of C++) but there are clear benefits of modern languages over the old ones. Of course you can write everything in Objective-C, or C for that matter, but then you put additional burden to the developer.

I can manage the memory but I do not want to. I can track the type of objects in my array but I don't want to do that either. Even as an experienced programmer there are lots and lots of bugs that can be avoided if your compiler is smarter. In C++ world the C++11 enabled us to have a great jump in productivity because the language simply does more.

Apple has to maintain two languages now but I don't think that is a really big deal. They share a lot of common stuff and as you said Objective-C is old school. Most of the bugs were caught and I suppose that the language will not evolve much anymore.

I also think that since the CPU architecture has evolved quite a bit during the years, the old optimisation tricks do not work anymore. Having a higher level language enables the compiler to optimise the code better.

 

[1458279]

I can't agree with that. Granted I have less experience than you (5 years of C++) but there are clear benefits of modern languages over the old ones. Of course you can write everything in Objective-C, or C for that matter, but then you put additional burden to the developer.

I can manage the memory but I do not want to. I can track the type of objects in my array but I don't want to do that either. Even as an experienced programmer there are lots and lots of bugs that can be avoided if your compiler is smarter. In C++ world the C++11 enabled us to have a great jump in productivity because the language simply does more.

Apple has to maintain two languages now but I don't think that is a really big deal. They share a lot of common stuff and as you said Objective-C is old school. Most of the bugs were caught and I suppose that the language will not evolve much anymore.

I also think that since the CPU architecture has evolved quite a bit during the years, the old optimisation tricks do not work anymore. Having a higher level language enables the compiler to optimise the code better.

In order to be fair, wouldn't you have to compare the cost of learning a new language, converting old code, etc. Vs the benefit of 'easier' code better memory mgmt, etc...

Also, could they have addressed memory management and other issues without having to move to a new language.

Is there something about one language that makesit so that it can't evolve into something that Swift can evolve into?

It wasn't all that long ago that ObjC didn't have ARC, now it does.

I see any language as just a set of instructions that the compiler converts into something else and is linked into something else.

How can one language do something that another can't? So it comes down to how easy and errors, etc... Can that not be done with changes to the current language, just like what was done with ARC?

 

[PizzaBoxStyle]

In order to be fair, wouldn't you have to compare the cost of learning a new language, converting old code, etc. Vs the benefit of 'easier' code better memory mgmt, etc...

Also, could they have addressed memory management and other issues without having to move to a new language.

Is there something about one language that makesit so that it can't evolve into something that Swift can evolve into?

It wasn't all that long ago that ObjC didn't have ARC, now it does.

I see any language as just a set of instructions that the compiler converts into something else and is linked into something else.

How can one language do something that another can't? So it comes down to how easy and errors, etc... Can that not be done with changes to the current language, just like what was done with ARC?

I agree here. There is/was a lot they could have done to Objective-C to make it great and modern without throwing it out and starting over with a weird language that can't decide if it wants to be functional or object oriented.

Look at what Microsoft has been doing. They started with two languages, C# (object oriented) and F# (functional), and are Now sanely modernizing C# and adopting ideas from the functional world. The language is growing organically.

I think that Apple very well could have done the same thing with Objective-C.

Being able to get rid of pointers and even just initialize variables like this would have done great things for ObjC:

var object = [NSObject init];
[doublepost=1455958442][/doublepost]

I think it is not really Tim's job to explain programming to people, but what is the issue with those three lines? They are very simple if you know the Swift syntax. Also do not forget that for the same thing in Obj-C you would need to go look at http://****ingblocksyntax.com

I'm not asking him to explain programming to people, I want him to stand by the claims he is making. That's my problem.

Operators have precedence and associativity. Also overloading operators was never recommended, it exists in Swift because most of the language is defined in the standard library.

Then why does it exist? Strip it away like pointers and for loops. Just more overhead and mental burden, in my own experience.

They are safer and simpler to understand than imperative languages (for beginners).

Says who?

The For-Next removal was quite straightforward. It has little use in a high level/functional language and the compiler can optimise for-each loops and high order functions better.

It may have little use in practicality, but we are talking about academic environments. I don't know about you, but for me the for loop was introduced, and later we had a discussion about why arrays are zero-based indexed and about pointer arithmetic and memory. Are we just going to stop caring and let future developers not have an understanding of the heritage of the tools and constructs they are using?

Trying to shoehorn Objective-C (or C) code in Swift is the wrong approach.

Well, that's exactly what using the system frameworks (Cocoa, Cocoa Touch) is doing.
[doublepost=1455958781][/doublepost]

I have been programming for decades, from COBOL, MASM, basic, C, C++, MSC, Objective C, some HTML, CSS, Java and tried Swift.

Personally I see no really good (programming wise) reason for Apple to jump on Swift other than to get a bunch of new coders for the their hardware. I don't find Swift syntax any easier or more "elegant" than Objective C, but the new young coders want to be different and innovative and this is what Swift offers. Swift actually adds some pain to the Apple process because now they have to support two languages to do the same things. Why would they want to do such a thing? Objective C is now old school and when a person is young, old school is just old school.

Basically what I am saying this, Swift is a marketing move designed to draw new blood into the Apple world.

BTW MASM was used to build tight and fast code for those old 8086 machines. It was used to write small functions which accessed hardware and memory locations directly and was not used to write a whole program.

This was kind of my thoughts.

I suspect that Swift was actually started as a skunkworks project at Apple by the compiler team, never to be revealed to the public and only for their own use. I mean, between the masterbatory syntax and the incoherent feature-set, it's a reasonable suspicion. But then something happened and everyone decided that Swift was the future, possibly for marketing reasons as you mentioned.
[doublepost=1455959103][/doublepost]

Also do not forget that for the same thing in Obj-C you would need to go look at http://****ingblocksyntax.com

Also, I don't see the difference between learning blocks in Objective-C and learning closures in Swift.

Yeah, blocks are ugly compared with the rest of the Objective-C syntax, but they could have probably found a better way to do them in the first place, and the end result is that you need to learn something either way.

 

[eventailapp]

In order to be fair, wouldn't you have to compare the cost of learning a new language, converting old code, etc. Vs the benefit of 'easier' code better memory mgmt, etc...

Well, yes, but there is a LOT of new code written. Also I do not think that rewriting old stuff is a good idea as you would be throwing away the fixes for edge cases and so on. However I believe that a lot of bugs are due to the fact that people comfortable with old tools treat them as a hammer. 2000 line bash scripts, networking code written in C, macros all over the place and so on.

Also, could they have addressed memory management and other issues without having to move to a new language.

Yes and no. Yes they can of course add new syntax for new types of variables and so on, but they can not remove the old stuff. Objective-C is a strict super set of C, this means that you can always shoot you in your leg with mallocs, pointer arithmetics and arbitrary casts.

How can one language do something that another can't? So it comes down to how easy and errors, etc... Can that not be done with changes to the current language, just like what was done with ARC?

Language is not just a syntax, it is the whole model underneath. If your language supports pointer arithmetics then you can have aliasing problems. If you can explicitly allocate memory on the heap then your compiler can not optimise allocations (if it would be better to allocate on the stack).

Then why does it exist? Strip it away like pointers and for loops. Just more overhead and mental burden, in my own experience.

It's a choice, I would imagine that many operators in Swift are defined in standard library. But I tend to agree that operator overloading is a dangerous feature and should really not be used.

Says who?

Says many people. From my side I would mostly cite the Hacker News crowd.

Well, that's exactly what using the system frameworks (Cocoa, Cocoa Touch) is doing.

I agree, and I think that Cocoa should evolve to embrace Swift more.

It may have little use in practicality, but we are talking about academic environments. I don't know about you, but for me the for loop was introduced, and later we had a discussion about why arrays are zero-based indexed and about pointer arithmetic and memory. Are we just going to stop caring and let future developers not have an understanding of the heritage of the tools and constructs they are using?

In our school we were taught functional programming first (with Scheme), at first I was surprised because I already knew imperative programming but then it got to me. Functional is simple because people already know functions from math.

Later we went through the memory model and so on. I agree that it is a necessary knowledge for architects and so on. But as time goes on I do not think that everybody in CS should be required to know all about the computer. Myself, I know just enough about modern microprocessors to realise that trying to micro-manage performance myself would make everything only worse. For application development I believe that a deep knowledge of the tools is not necessary.

My point is, that we have moved up the stack for a long time and I do not believe that the languages we have now are the endgame. There is a reason why JavaScript is popular - it is simpler. Google develops Go because it is faster than what they have (and they did not opt to use C because of safety). Mozilla is developing a whole new language just to make browsing safer. Clearly a lot of big companies see the benefit of moving to more modern languages and do not hesitate to build things from the ground up.

Also, I don't see the difference between learning blocks in Objective-C and learning closures in Swift.

Maybe it's a matter of taste. But I think that Swift's function syntax is very clear.

 

[AxoNeuron]

I would agree that Swift closures are pretty much just Objective-C blocks with a different name. I wish they had just kept the name 'blocks'. I think the word 'block' is a lot better at describing what they actually are. Though it would have been even better if they had just called them callbacks honestly.

 

[firewood]

Personally I see no really good (programming wise) reason for Apple to jump on Swift other than to get a bunch of new coders for the their hardware.

That's because you're seeing Swift from the wrong point-of-view. That of coders. That's a really tiny portion of Apple's customer base.

Part of the reason for Swift is not to benefit coders, but to benefit Apple's larger customer base. Remember that Swift was designed by a optimizing compiler architect. Swift was created not only to make the code more palatable for new coders, but so that their code could more often be compiled into a safer, more highly optimized and higher performance results.

Objective C requires a small runtime, thus cannot be completely optimized at compile time. And coding in hand-optimized C is often neither readable nor safe. Swift helps solve both of those sets of problems.

Thus customers end up with more apps that are more secure and eat less battery life.

On of the reasons that iOS devices and apps make so much more money is that too many Android devices and apps run like slugs. Apple is trying to create an even greater advantage in that area, not let the competition catch up.
[doublepost=1455996363][/doublepost]

I would agree that Swift closures are pretty much just Objective-C blocks with a different name. I wish they had just kept the name 'blocks'. I think the word 'block' is a lot better at describing what they actually are. Though it would have been even better if they had just called them callbacks honestly.

The term "closures" in CS predates the term "blocks" by decades. Both are different from callbacks, in standard practice.

 

[bjet767]

I also think that since the CPU architecture has evolved quite a bit during the years, the old optimisation tricks do not work anymore. Having a higher level language enables the compiler to optimise the code better.

Yes it has and even Apple has optimized its compiler by doing away with code managed memory through ARC. I love not having to un-allocate memory these days.

Remember that Swift was designed by a optimizing compiler architect. Swift was created not only to make the code more palatable for new coders, but so that their code could more often be compiled into a safer, more highly optimized and higher performance results.

I'm not sure I understand how your statement here is true. The compiler has always been the end of the line for optimization and as I mentioned from the above quote Apple appears to have continued their process of improving and "optimizing" the objective C compiler.

If we could look at the size and speed of execution would a complex code, especially calling views and API objects, would Swift be more compact and faster? Or is the optimization really in the eyes of the coder not having to write and many characters?

Not really sure the end product is better or is produced faster with Swift.

The question of optimization for the coder really comes down to the ability to do more with less. Don't write code which doesn't need to be written. Does Swift prevent or fix this? I would bet some things always stay the same regardless of the year and language things are written in.

 

[firewood]

Apple appears to have continued their process of improving and "optimizing" the objective C compiler.
...
The question of optimization for the coder really comes down to the ability to do more with less. Don't write code which doesn't need to be written. Does Swift prevent or fix this?

That process (improving their Objective C compiler technology) ended up with Swift. And yes, Swift seems to prevent and fix this far more often than other languages. How often do you read C and Objective C code that is choked full of the required (by the language definition) optimization hints? Swift code can do without a large amount of them.

 

[bjet767]

firewood

How often do you read C and Objective C code that is choked full of the required (by the language definition) optimization hints?

Thanks for the response, but I'm not sure I see any more "hints" about coding optimization with Object C over Swift. could you give some examples please.

As far as the compiler goes, could you give us some idea about where or how the Swift parser compared to the Objective C part of the compiler is more optimized? While I don't know how Apple's compiler really works I do know that typically all compilers start with some sort of parser which does a pre-proccessing function before it moves to actually build a file of machine code or some sort of low level commands which talk to the OS.

Again thanks and I'm not really debating the compiled effiency of Swift verses OC. I'm just curious what facts indicate so.

 

[firewood]

...I'm not sure I see any more "hints" about coding optimization with Object C over Swift. could you give some examples please.

How often do you see code that looks up an Objective C class method to message directly via the Obj C runtime? That reduces Obj C dynamic dispatch time from potentially many milliseconds down to a few CPU cycles. Swift doesn't need to use that sort of unreadable/maintainable code that to get deterministic method dispatch speed (e.g. go fast always, instead of just most of the time).

Read up on the Objective C internals and runtime and you will find several of these kinds of "gotcha's" that get in the way of reliable maximum performance. Very few (highly expert) coders write that kind of code in Objective C to get absolute max performance, so Swift was designed to not require such tricks for the same max performance.

 

[PizzaBoxStyle]

How often do you see code that looks up an Objective C class method to message directly via the Obj C runtime? That reduces Obj C dynamic dispatch time from potentially many milliseconds down to a few CPU cycles. Swift doesn't need to use that sort of unreadable/maintainable code that to get deterministic method dispatch speed (e.g. go fast always, instead of just most of the time).

Read up on the Objective C internals and runtime and you will find several of these kinds of "gotcha's" that get in the way of reliable maximum performance. Very few (highly expert) coders write that kind of code in Objective C to get absolute max performance, so Swift was designed to not require such tricks for the same max performance.

True.

But this performance hit is also affecting any Swift code that calls into an Objective-C API. Swift is still using reflection to map to functions/methods when it calls through the whole Objective-C bridging stuff, and will be until Apple either ports the Cocoa/Cocoa Touch APIs to Swift OR creates an entirely new set of system frameworks. I suspect/guess that they will be doing the latter, as Swift negates some of, and doesn't adhere well (IMO) the design patterns of Objective-C/Cocoa. And if they are not already planning/working on this... well, then I'd argue that the true potential of Swift may never be realized.

This is what I'm saying about the dishonesty of the marketing message Apple has been putting out. This whole use Swift with Cocoa/Cocoa Touch is just a transitional thing, but they aren't saying it and keeping everyone in the dark.

Also I seem to remember reading something in Apple documentation (or maybe it was a book) telling you to never directly dispatch messages yourself, and that the dispatcher written by Apple had been as highly-optimized as it possibly could be.

 

[firewood]

Swift is still using reflection to map to functions/methods when it calls through the whole Objective-C bridging stuff, and will be until Apple either ports the Cocoa/Cocoa Touch APIs to Swift OR creates an entirely new set of system frameworks.

No need for a new set for most of that. Most Cocoa/Cocoa Touch API operations happen at the speed of humans, which is already millions of times slower than the CPU. (Frame rate is only 60 Hz. Compare that to GHz+ arm64 CPUs.) Only the non-UI compute classes may need new faster APIs; and that's already been done for stuff like array map in Swift.

Also I seem to remember reading something in Apple documentation (or maybe it was a book) telling you to never directly dispatch messages yourself, and that the dispatcher written by Apple had been as highly-optimized as it possibly could be.

Apple's dispatch is optimized highly for the full set Obj C semantics, not when compared to special-cased assembly code compute kernels. Not recommended because it's fragile and difficult to hand dispatch correctly in all cases. Swift avoids those problems.

 

[bjet767]

Read up on the Objective C internals and runtime and you will find several of these kinds of "gotcha's" that get in the way of reliable maximum performance.

firewood:

I am interested so where in Apple's documentation or other external docs may I find such info?

And I believe all programs and apps use "runtime" modules these days when they call functions. The advantage of that type of architecture is the runtime files can be updated, improved and modified while our code stay the same. I also remember the days when we would compile stand alone programs in C for MSDOS and then along came windows with their "dlls" and "basic" runtime engines, which really weren't compiled programs at all.

 

[PizzaBoxStyle]

No need for a new set for most of that. Most Cocoa/Cocoa Touch API operations happen at the speed of humans, which is already millions of times slower than the CPU. (Frame rate is only 60 Hz. Compare that to GHz+ arm64 CPUs.) Only the non-UI compute classes may need new faster APIs; and that's already been done for stuff like array map in Swift.



Apple's dispatch is optimized highly for the full set Obj C semantics, not when compared to special-cased assembly code compute kernels. Not recommended because it's fragile and difficult to hand dispatch correctly in all cases. Swift avoids those problems.

So, the Objective-C in Cocoa/Cocoa Touch is fast enough to not be noticeably impacted by reflection, but Objective-C outside of Cocoa/Cocoa Touch is slow enough that using Swift and avoiding reflection is a boon?

How often do you see code that looks up an Objective C class method to message directly via the Obj C runtime? That reduces Obj C dynamic dispatch time from potentially many milliseconds down to a few CPU cycles. Swift doesn't need to use that sort of unreadable/maintainable code that to get deterministic method dispatch speed (e.g. go fast always, instead of just most of the time).

I'd think that if avoiding method dispatch helped performance, you'd especially want that in the frameworks that everyone calls into. But who am I to push this notion on iOS and Mac developers?

 

[firewood]

I am interested so where in Apple's documentation or other external docs may I find such info?

A simple google search turns up:

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ObjCRuntimeRef/

http://cocoasamurai.blogspot.com/2010/01/understanding-objective-c-runtime.html

https://mikeash.com/pyblog/friday-qa-2009-03-13-intro-to-the-objective-c-runtime.html

and others.

 

[bjet767]

firewood

Thanks!

But I searched for differences and come up that Swift is actually seems to be slightly slower in execution than OC.

Check this out:

http://stackoverflow.com/questions/24077639/performance-of-swift-vs-objective-c

 

[1458279]

firewood

Thanks!

But I searched for differences and come up that Swift is actually seems to be slightly slower in execution than OC.

Check this out:

http://stackoverflow.com/questions/24077639/performance-of-swift-vs-objective-c

I think it would be pretty hard to get much difference with a simple program. It might be the case that overall performance would be better in a larger program. It should be too hard to convert a med sized ObjC project over to Swift and runs some numbers.

I wonder what the memory usage is like or maybe threading.

BTW, are the Swift apps still huge downloads compared to ObjC apps? I remember someone said Swift was some 3X larger.

 

[eventailapp]

Swift apps have the whole runtime with them so updates will not break them. This will get better when the language is stable.