Earlier quoted context omitted.
Swift uses a special "bridging header" to expose Objective-C code to Swift. This header will presumably be processed by the Swift compiler. In the other direction, XCode will automatically generate an Objective-C header to expose your Swift code to Objective-C.
The ibooks guide references a "Using Swift with Cocoa and Objective-C" document. Is that where you got your information?
The Swift Programming Language
721–730 of 970 posts
Re: The Swift Programming Language
#722Just glanced thru the Swift book in about 3 hours. Conclusion: all your programming language are belong to Swift, mostly stolen good ideas, some innovations, a few gripes. I can say Swift takes inspiration and improves on at least these languages: C: typealias struct control structures labeled statements AKA gotos varargs C++: default arguments class instance construction syntax // comment superclass, implementing pr…
> break-less switch, optional fall-thru
Like Go and Dart?
Re: The Swift Programming Language
#723Earlier quoted context omitted.
This is not accurate. SpiderMonkey and V8 still retain the entire outer scope if any of the variables are used. See here for an example: https://www.meteor.com/blog/2013/08/13/an-interesting-kind-o... This bug is still not fixed. There's an issue open for it on the V8 tracker, I believe. It seems to have not gotten fixed in either engine because it's a difficult problem that affects a small subset of JS applications.
So go ahead and run his test. Things have changed :). Memory builds up 1mb/second, then after a few seconds, you'll see it drop back to zero, as the GC runs. V8 has seen a lot of really nice optimizations to closures over the last year. My favorite is that closures are no longer considered megamorphic.
Oh wow, when did that land? I was getting hit by that leak with JSIL in the last couple months. Can you link to the commit?
Re: The Swift Programming Language
#724Earlier quoted context omitted.
Oh hello again, Pacabel. I'm familiar with your game by now. :) We're not scared in the slightest. I'll reconsider when Swift has inline ASM, allocators, linear types, move semantics by default, region analysis, and a type system that guarantees freedom from data races (oh, and when the code is open-sourced, and targets both Linux and Windows as a first-class citizen). Swift isn't intended to be a systems language: i…
It's interesting that inline assembly is your first bullet point, since there's nothing I can think of that ruins a code file more than inline assembly in a host language. Put that crap in a .S file and link it in like everything else, for crying out loud. The one time you need inline assembly is when you don't want to build a function frame, such as a tight loop, but come on. Also, even in systems, I can think of ab…
> The one time you need inline assembly is when you don't want to build a function frame, such as a tight loop, but come on.
This is hilarious. Like anyone would ever use inline assembly in a tight loop.
Re: The Swift Programming Language
#725Earlier quoted context omitted.
Oh hello again, Pacabel. I'm familiar with your game by now. :) We're not scared in the slightest. I'll reconsider when Swift has inline ASM, allocators, linear types, move semantics by default, region analysis, and a type system that guarantees freedom from data races (oh, and when the code is open-sourced, and targets both Linux and Windows as a first-class citizen). Swift isn't intended to be a systems language: i…
My apologies, I didn't realize that expecting a programming language to have a stable syntax, stable semantics, a stable standard library and at least one stable and robust implementation before using it seriously in industry was merely a "game". Perhaps this is news to you, but those of us who work on and are responsible for large-scale software systems tend to take such factors very seriously. This may sound harsh,…
>My apologies, I didn't realize that expecting a programming language to have a stable syntax, stable semantics, a stable standard library and at least one stable and robust implementation before using it seriously in industry was merely a "game"
You also didn't realize that you just built the biggest strawman ever in the above sentence.
Enough with the "I want a stable Rust now". Rust, like any other language, takes years to stabilize. You just happen to see it happen in the open, whereas most other languages you get them at their 1.0 release.
>This may sound harsh, but it really doesn't matter what features and benefits Rust could potentially bring to the table if the lack of stability makes it unusable in practice today. A programming language that can't be seriously used might as well not even exist.
They could not give a flying duck about it being "seriously used today".
They'll start to care AFTER they release it as 1.0. They only released this 0.x versions to solicit ideas and improvements, not to get programmer's to adopt it.
Re: The Swift Programming Language
#726There's one thing that bothers me about Swift, and I feel like I must not be getting it. For the most part it looks like a very well-designed language, and the choices they made are extremely pragmatic. But the way collection mutability is determined seems positively insane. You can't have a mutable reference to an immutable array, or vice-versa. I don't get the reasoning behind that.
I can't check it, but i presume you can do something like Rust and redefine immutable variables.
Re: The Swift Programming Language
#727My first instinct was to be cautious about new languages from Apple - Dylan was supposed to be something awesome until Apple cancelled it. But I only learned of the existence of Dylan years after it was cancelled. Looked awesome, but it was so niche I didn't want to spend time learning it.
So I took a moment to look at why Dylan was cancelled.[1] Veryin interesting stuff. What it came down to was:
- Apple was in dire financial straits
- Apple needed to axe all projects that didn't show commercial viability
- At the time, when Apple was transitioning to PowerPC, Dylan was 68K only, and needed another year or two to be ported
- Most damning, the project was not finished - it wasn't even in the optimization stage.
I'm really curious now about two (unrelated) things:
1) is this good enough to build web apps with? 2) how would one manage the transition of an Obj-C based project to a Swift-based one? Assume I don't have the budget or manpower to perform a ground-up rewrite.
[1] http://en.wikipedia.org/wiki/History_of_the_Dylan_programmin...
Re: The Swift Programming Language
#728Earlier quoted context omitted.
The similarity to Rust should scare the hell out of Rust's creators and proponents. Swift could very well render Rust almost totally irrelevant within the OS X and iOS sphere of software development. If we end up eventually seeing Swift implemented for other platforms, then the chances of Rust's long-term success diminish even more. Things might have been different had a stable, even if somewhat imperfect, initial ve…
Oh hello again, Pacabel. I'm familiar with your game by now. :) We're not scared in the slightest. I'll reconsider when Swift has inline ASM, allocators, linear types, move semantics by default, region analysis, and a type system that guarantees freedom from data races (oh, and when the code is open-sourced, and targets both Linux and Windows as a first-class citizen). Swift isn't intended to be a systems language: i…
[deleted]
Re: The Swift Programming Language
#729I don't have access to a machine with the new Xcode yet, but reading the book in iBooks, I found:
NOTE
For the best experience, open this chapter as a playground in Xcode.
Playgrounds allow you to edit the code listings and see the result immediately.
Does that mean that playgrounds can be used for literate programming?
Re: The Swift Programming Language
#730I'm impressed that it looks like they're turning Bret Victor's demo into a reality with playground. Check out his demo if you haven't: https://www.youtube.com/watch?v=PUv66718DII Really, really interested and excited about learning Swift.
Wouldn't say I'm impressed but definitely really excited. BVictor is pretty amazing. Anyone who hasn't seen should check out either these talks. There're great for getting extra inspired about coding or the coding life, and great for perspective too:
The Future of Programming: http://bit.ly/1pNtKMh Inventing on Principle: http://bit.ly/1opRrJp