Yeah closures are a bit tricky. However they make code so much nicer, especially trailing closures, which makes things such as completion handlers much cleaner.
Object owning I understand, it confused me too in the beginning.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Releases First Preview of Swift 3.0 for Developers [Update: Not Available]
- Thread starter MacRumors
- Start date
- Sort by reaction score
Yeah closures are a bit tricky. However they make code so much nicer, especially trailing closures, which makes things such as completion handlers much cleaner.
Object owning I understand, it confused me too in the beginning.
It is interesting to see how many people in this thread are mentally stuck in the 70-ties in regards to compiler technology. There is so much misinformation and naive half-truth going on here. I'll just make a few points:
1. After it matures, Swift will be faster than Objective-C, there is no question about it. Swift is an explicitly typed language, which allows the compiler more then enough opportunity opportunity for dramatic optimisations. These optimisations are not possible in Objective-C, as it uses dynamic call mechanisms. The cost of an indirect call in Swift is the same as the cost of indirect call of C++, and Swift provides more type information on top.
2. Iterator-style for loops in Swift can in most cases be optimised to the same machine code as a regular C loop. E.g.
for x in elements { doSomeThing(with: x) }
will, after some trivial transformations, be expanded by the compiler to something like
for(int i = elements.startIndex; i < elements.endIndex; i++) {
doSomeThing:with(elements._buffer)
}
which is compiler to a regular loop with counter and a pointer access. There is an iterator indirection, which can be completely optimised by the compiler. Its nothing complicated. The theoretical basis for these trivial code transformations was established decades ago.
3. Swift offers full pointer arithmetic and access. Everything you can do in C/C++ with pointers, you can do in Swift. Its a bit more verbose, but not difficult at all.
That said, when I write performance-critical code, I use C. The Swift compiler is not yet 100% mature and there are things that are simply very difficult to implement properly, for example complex data structures. But for trivial algorithms like 99% of the commonly written code, Swift is ore then adequate and offers a much more pleasant programming experience than most other languages.
1. After it matures, Swift will be faster than Objective-C, there is no question about it. Swift is an explicitly typed language, which allows the compiler more then enough opportunity opportunity for dramatic optimisations. These optimisations are not possible in Objective-C, as it uses dynamic call mechanisms. The cost of an indirect call in Swift is the same as the cost of indirect call of C++, and Swift provides more type information on top.
2. Iterator-style for loops in Swift can in most cases be optimised to the same machine code as a regular C loop. E.g.
for x in elements { doSomeThing(with: x) }
will, after some trivial transformations, be expanded by the compiler to something like
for(int i = elements.startIndex; i < elements.endIndex; i++) {
doSomeThing:with(elements._buffer)
}
which is compiler to a regular loop with counter and a pointer access. There is an iterator indirection, which can be completely optimised by the compiler. Its nothing complicated. The theoretical basis for these trivial code transformations was established decades ago.
3. Swift offers full pointer arithmetic and access. Everything you can do in C/C++ with pointers, you can do in Swift. Its a bit more verbose, but not difficult at all.
That said, when I write performance-critical code, I use C. The Swift compiler is not yet 100% mature and there are things that are simply very difficult to implement properly, for example complex data structures. But for trivial algorithms like 99% of the commonly written code, Swift is ore then adequate and offers a much more pleasant programming experience than most other languages.
Springsup
It seems you put a lot of faith in the compiler to fix bad/sloppy code. Never forget someone wrote the compiler and has to make some assumptions about the code as it goes through each line, while perfection will never happen good code makes things a whole lot easier.
But again iOS really doesn't matter because are code (OC or Swift) is never really very low or deep in the process. In the day our programs were almost 100% of the process, now we mostly sit and call the API when needed. I remember when the size of our .exe files and managing the memory stack actually counted.
[doublepost=1464955928][/doublepost]
Leman
You started with a statement about how people on this thread were stuck in the 70s and then ended with this:
So what is it? You trust the compilers of today to optimize code or not?
What kind of stuff do you write that needs the low level effiency of straight C?
I have seen code written for iOS and OS X that still uses fgets and really don't understand why when Apple has some really good file access stuff that makes life a whole lot easier.
It seems you put a lot of faith in the compiler to fix bad/sloppy code. Never forget someone wrote the compiler and has to make some assumptions about the code as it goes through each line, while perfection will never happen good code makes things a whole lot easier.
But again iOS really doesn't matter because are code (OC or Swift) is never really very low or deep in the process. In the day our programs were almost 100% of the process, now we mostly sit and call the API when needed. I remember when the size of our .exe files and managing the memory stack actually counted.
[doublepost=1464955928][/doublepost]
Leman
You started with a statement about how people on this thread were stuck in the 70s and then ended with this:
So what is it? You trust the compilers of today to optimize code or not?
What kind of stuff do you write that needs the low level effiency of straight C?
I have seen code written for iOS and OS X that still uses fgets and really don't understand why when Apple has some really good file access stuff that makes life a whole lot easier.
Last edited:
Oh, compilers are quite good at optimising these days, but they optimise according to specific rewrite invariants. They usually can't guess the intent of the programmer. The advanced optimisations are very good at removing abstractions and reshaping the code into an optimal form, but it is still your code that restricts the final result. There is always a class of problems that can be solved more efficiently with a more involved engineering approach. To put it differently, the compiler is not aware of all the invariants in your data structures and algorithms if they are complex enough, so it can't be expected to find the optimal solution. Usually, a correct problem statement helps. But sometimes there are simply no means to specify the problem statement fully, because that is not something that the language supports. This is where 'hacking' comes in handy.
For example, I recently implemented a complex data structure for my game engine that consists of a series of interconnected graphs with a superposed state machine. I did write the prototype code in Swift, using recursive enums and structs. Writing the prototype was a pleasure, because I could use type abstractions that resulted in compact and expressive code, which helped me to see and approach the problem much better. However, the performance is lacking because the data structure is simply too complex to implement in Swift efficiently. At least, I couldn't figure out how to do it. Instead, I had to give up the type safety of Swift and 'go dirty', relaying on invariant enforcement through my code. I am currently rewriting the algorithms in hand-tuned platform-independent C that heavily relies on tricks like compressed pointers, conditional bitfields, packed cache-aware data structures and so on.
Swift works very well for most programming tasks, but some things are simply cannot be achieved efficiently within its safety harness. I don't see any issue with that. Different tools for different problems.
For a different example, see here: http://article.gmane.org/gmane.comp.lang.lua.general/75426
Leman
So there you go, proving what I stated way back, high level languages are not as fast as the low level stuff, coding is an art and sloppy coding can't be left up to the compiler to fix.
But object oriented languages were never meant to be fast, they were meant to ease the burden of coding the UI stuff and mundane tasks which required too many lines.
What are you working on and have you got any games published we can see?
So there you go, proving what I stated way back, high level languages are not as fast as the low level stuff, coding is an art and sloppy coding can't be left up to the compiler to fix.
But object oriented languages were never meant to be fast, they were meant to ease the burden of coding the UI stuff and mundane tasks which required too many lines.
What are you working on and have you got any games published we can see?
I'm not sure most developers would disagree but I guess you are in the know lol
I'd be interested to check out what you've been working on too leman. Good luck on your project.
Tell that to IBM
http://www.theregister.co.uk/2016/02/23/ibm_releases_kitura_a_swift_web_server_framework_for_linux/
or google
http://thenextweb.com/dd/2016/04/07/google-facebook-uber-swift/
How about that it's the number 1 language on GitHub.
http://thenextweb.com/dd/2015/12/08...ready-the-number-one-language-on-github/#gref
or the fastest growing language ever
https://www.macrumors.com/2015/01/16/swift-unprecedented-growth/
Are you somehow in the know? lol
Last edited:
I agree with your statement here, with some reservations in regards to the 'high level is slower than low level'.
I think it really depends on what you are trying to do. For numeric code, for example, there is no reason why Swift should be any slower than C or C++ (except less mature compiler). Besides, it might be even easier to write slow code in C than with Swift in many circumstances (e.g. using ineffective malloc patterns etc.). However, if one needs to do some low-level coding, a low-level language is a better tool most of the time.
True. Which doesn't mean that they can't be just as fast, in case that the compiler can prove that some invariants will hold. The more information the compiler has, the better chances it has on outputting optimal code. A low-level language gives one a lot of flexibility in treating data, but at the same time this means that the compiler needs to be conservative with its assumptions. A good example is pointer aliasing and object lifetime analysis. In a structured, high-level language, some usage patterns can be more easy to recognise and to improve automatically.
Oh, I wish. Unfortunately, I am restricted by my real full-time job (which is also quite demanding), so I can pursue my game developing projects as a side hobby only. It will still be some time until I get anything even remotely presentable.
I never claimed to be but you sure implied you are... a few companies using it because it is what runs on Apple doesn't make it a better language, they just want to support Apple product and so does everyone else using it lol
Let's face it Swift will be a good language and maybe version 3.0 will be the one. But we all have to admit if Apple hadn't promoted it very few of us would have even known about it.
ObjectiveC was/is doing the trick for iOS and OS X programming, it was just time to update into a broader and eventually less hardware, no let me rephrase that, less OS (objectiveC really is Apple's baby) specific language. I thinks it is also what might be considered a language for "the millennials" to get behind.
There's even marketing in the languages we use.
ObjectiveC was/is doing the trick for iOS and OS X programming, it was just time to update into a broader and eventually less hardware, no let me rephrase that, less OS (objectiveC really is Apple's baby) specific language. I thinks it is also what might be considered a language for "the millennials" to get behind.
There's even marketing in the languages we use.
And nobody would know about C if UNIX were not written in it.
Swift is even more of an Apple baby than Objective-C ever was. Swift was originally designed and developed by Apple, Objective-C was not.
I would say that Apple's Swift is a lot like Microsoft's C# but there is a strong correlation between C# and Java (aside from the JVM), I thought Java would be difficult, but it's pretty much the same thing as C# aside from a few differences.
Did you even bother to read the links in the post you quote? Or are you just blurting out random stuff?
[doublepost=1465021029][/doublepost]
Swift ist very similar to Microsoft's F#. MS just never had the will to promote it more strongly. Both languages borrow concepts from ML and friends. While these concepts are very old and go back to the mathematical underpinning of programming languages (that ultimately draw from lambda calculus), they were mostly limited to the academic domain due to the practical nature of programming. Instead, mainstream languages were based on pragmatic hardware abstractions (C, Pascal etc.). It is only very recently that functional abstractions found their way into mainstream languages and the importance of Swift is that it is a first programming language of this sort to be strongly backed by a company with a lot of pull in the industry.
As to C#, it started out as a Java/Objective-C clone (there are strong rumours that Java itself was deeply influenced by Objective-C), but gained some of the functional features along the way. You are absolutely right that in its early versions, it was essentially Java — just MS pulling their old Embrace, extend and extinguish strategy in order to gain from Java's popularity.
You're conflating two issues: you're saying "high level languages are not as fast" and equating that with sloppy code. As I showed, Swift has a nifty feature (which I can't remember seeing before, but no doubt it exists in some other language) called zero-cost abstractions. Literally, you can abstract things away in to data types and instance methods with zero runtime performance penalty. The compiler will literally optimise the abstraction away, and it will be like you were operating on the raw data types with inlined functions. Both struct and enum (the value types) have zero runtime cost.
Algorithmically, of course your code makes a difference. Check out the Nibble-sort challenge in Swift; it really is a perfect example of what I'm talking about.
There is a challenge to sort hex digits in a 64-bit integer. You can port that code to Swift, and the resulting performance is almost identical to C. What you can also do, though, is model the integer as a Swift CollectionType and using any regular Swift sorting function on it and the compiler will generate excellent code. What you're saying is that you can't rely on the compiler to know that you're sorting and generate a "perfect" sorting function for you; sure, of course that's true. If you didn't tune your algorithms, performance won't be as good. But the important point is that here is that there is zero performance penalty from the abstraction.
Swift can also be used to do complex, bit-level operations. It hasn't been a big focus of the language so far because of where it's used, but just means the standard library is awkward to work with; it's not a structural deficiency of the language. As Swift develops and expands in to new areas, those parts of the standard library can be improved. It's open-source; you're welcome to suggest a better API.
Ok I showed you facts why it's so popular, yet you come back and tell me otherwise, still claiming I'm somehow in the know. What are you on about.
Some companies? IBM and Google are some companies? Lmao
The fact that's it's the number 1 language on GitHub also proves that swift is the most pupular.
It also nothing to do with supporting Apple, swift is open source.
Done talking to you as you are typical Mac rumours member, no facts just spewing nonsense. Goodbye
Last edited:
I did. The only reason people are supporting this is because it supports apple which is winning the game lol. Don't you see it or are you really that blind? None of this is an endorsement of it as a 'better' language.
[doublepost=1465051819][/doublepost]
Right, popular doesn't imply better, just more popular and i think in general if you follow the money you find the real reason. Don't let the door slam on your way out lol.
I really don't get what you are talking about. What does it have with 'supporting Apple'? You have one major company adopting Swift for developing Linux server software and another one thinking to adopt Swift for their smartphone platform (which is a direct Appel competitor). What does this have to do with 'Apple winning the game' (what game are we even talking about)? On contrary, Apple seems to be in disadvantage here, because its competitors are adopting a product that is developed by Apple and do not offer anything substantial in return.
They want this because it opens them up to a huge developer base is why. The semantics of the language have nothing to do with the decision.
That was 1995.
This is 2016.
The speed of a single processor core has pretty much plateaued over the last decade, but any modern smartphone, tablet or PC will have at least 2 processor cores - if not 4 or 8, with floating point, SIMD instructions and a GPU with 3d acceleration & the capability to do GPU-based processing (OpenCL etc). The key to high-performance software is not lovingly trimming the odd clock-cycle from your loops, but in making the most of multi-threading and fully exploiting the power of the GPU. In a multi-platform world, this also means using standard APIs and frameworks so that the hard work can be done by OS code that is optimised for the platform.
As a programmer, you don't know whether your code will run on an ARM or an x86 - the compiler does, and can potentially make use of the appropriate tricks (e.g. the ARM's barrel shifter and ability to make any instruction conditional).
Swift's strict typing, and the way it keeps a tighter reign on variables, constants and optionals, will help optimisations, as probably, will the removal of the arcane C "for" loop. While pure functional programming is strictly for the pure mathematicians, judicious use of functional programming and message-driven OOP techniques will make multi-threading much easier.
Really, C now fills the role that Assembler did a few years ago (while assembler is now strictly a last resort).
Plus, history has shown that people are incapable of writing secure code in C.
I rest my case.
http://appleinsider.com/articles/15...crown-of-most-loved-language-among-developers
Good luck in life with your mindset.
how is that proof? a biased article by the biggest apple fanboy site on the web. of course these developers are eager to use it because it is what makes them money. wow you really do your research lol
how is that proof? a biased article by the biggest apple fanboy site on the web. of course these developers are eager to use it because it is what makes them money. wow you really do your research lol
Once again, Did you even read the article?
Stackoverflow is Apple fanboys now? Facepalm.
It's official you are delusional and just like to talk nonsense.
Just thought I'd mention that some of the AAA titles coming out in 2016, still have their Engine written in C such as the Frostbite 4 engine. Mirror's Edge Catalyst dev confirmed this and this is why I mentioned that.
[doublepost=1465084400][/doublepost]
Interesting, never looked into F#, mostly for the reason you stated.