Inside Swift(eswick.com)
eswick.com
Inside Swift
http://www.eswick.com/2014/06/inside-swift/
8 comments
All the 'I also _____' and 'me too me too!!!' comments are so distasteful.
"Me too"-ism? Are tutorials and articles on a new language only supposed to be written by one single person?
Or should any other who has written related material not inform HN, because someone other's articles were posted first?
Or should any other who has written related material not inform HN, because someone other's articles were posted first?
I'm new to HN, but are you new to the internet? Saurik knows a few things about iOS, google him.
Grandparent was probably out of line (saurik's comment provided useful information that went beyond me too-ism), but I can understand why one would be wary. Its hard to keep up with who is legit, and there has been a lot of me tooism lately.
At least no one has started writing any horrible books on Swift yet.
At least no one has started writing any horrible books on Swift yet.
I am not certain I understand the problem with "me too-ism". Hacker News is a discussion forum: if I go into the comments on a post, what I am expecting to find is more information about the topic written by other people... if someone links to a related project or an article with more detail, I don't see how that's a problem.
In this case, I am actually featured prominently in this article--it isn't just that I know a lot about iOS or about Swift, but as the second half of this article and arguably the whole reason it was written was to show how to use Substrate (something I wrote) with Swift, I think it would be difficult to claim anything I say on the matter is "me too"--but even if it were someone totally random, I don't see why it should ever be considered a bad thing to direct people to more information :(.
(FWIW, I actually don't consider this article entirely correct: the information here implies that the symbols are available for all functions, and that was not my experience while on stage disassembling the WWDC app. I think I may need to parse the embedded Swift modules and provide new APIs for developers to look up methods out of the vtable, but before I go too crazy with that I am interested to see where the Swift-provided Swift.reflect ends up going.)
In this case, I am actually featured prominently in this article--it isn't just that I know a lot about iOS or about Swift, but as the second half of this article and arguably the whole reason it was written was to show how to use Substrate (something I wrote) with Swift, I think it would be difficult to claim anything I say on the matter is "me too"--but even if it were someone totally random, I don't see why it should ever be considered a bad thing to direct people to more information :(.
(FWIW, I actually don't consider this article entirely correct: the information here implies that the symbols are available for all functions, and that was not my experience while on stage disassembling the WWDC app. I think I may need to parse the embedded Swift modules and provide new APIs for developers to look up methods out of the vtable, but before I go too crazy with that I am interested to see where the Swift-provided Swift.reflect ends up going.)
Pleas not I wasn't accusing you of me too-ism, I realize what I wrote was ambiguous.
I did get that, but you did say that people might should be "wary", and I found it a little confusing as I don't really understand the concept of this "me tooism" as a problem. (I also was addressing both your comment about it being difficult to keep track of people who are "legit" by pointing out my direct connection in the article, but that response was more to the thread as a whole.)
Oh they almost certainly have, they're just not finished and published yet :)
"Swift is Apple’s new programming language, said by many to ‘replace’ Objective-C. This is not the case. I’ve spent some time reverse engineering Swift binaries and the runtime, and I’ve found out quite a bit about it."
Correct me if I'm wrong (and my point certainly isn't meant to detract from the interest of looking more in-depth at Swift internals), but this article doesn't appear to support this claim at all. It seems equivalent to saying Scala isn't meant to replace Java, or C assembly, because at the end of compilation it's all just Java. Abstraction is real. Also, Apple is providing a "migration guide" for porting Objective-C apps over to Swift. Nothing is conclusive, obviously, but certainly the article does not show that Apple doesn't intend for Swift to ultimately replace Objective-C as the primary language of Mac development.
Correct me if I'm wrong (and my point certainly isn't meant to detract from the interest of looking more in-depth at Swift internals), but this article doesn't appear to support this claim at all. It seems equivalent to saying Scala isn't meant to replace Java, or C assembly, because at the end of compilation it's all just Java. Abstraction is real. Also, Apple is providing a "migration guide" for porting Objective-C apps over to Swift. Nothing is conclusive, obviously, but certainly the article does not show that Apple doesn't intend for Swift to ultimately replace Objective-C as the primary language of Mac development.
Yeah, the article's technical analysis is good but I'm not sure what this line was supposed to say: what it actually says is wrong. Swift is definitely intended to replace Objective-C.
Perhaps that line in article meant that it's not binary identical to Objective-C. Swift classes definitely use different method invocation semantics (unless you adorn the class with the @objc attribute).
Perhaps that line in article meant that it's not binary identical to Objective-C. Swift classes definitely use different method invocation semantics (unless you adorn the class with the @objc attribute).
The site appears to be down. Here is the cached version: http://webcache.googleusercontent.com/search?q=cache:rOWlIup...
I think Apple has been clear that much of the underlying mechanics of Swift remain tightly coupled with the ObjC runtime, which makes sense if you think that Swift code must interoperate with all the existing Cocoa and Cocoa Touch frameworks and third-party code written in Objective-C (thus also allowing Apple to hedge its bet in case Swift tanks with developers).
What's _really_ going to be interesting going forward is whether Apple introduces new features in the runtime that are only available to Swift code, or whether it starts making change to the runtime that favour Swift over Objective-C—and that's probably going to tell us when the latter is to be considered a legacy language.
What's _really_ going to be interesting going forward is whether Apple introduces new features in the runtime that are only available to Swift code, or whether it starts making change to the runtime that favour Swift over Objective-C—and that's probably going to tell us when the latter is to be considered a legacy language.
If you have Xcode 6 installed this is the binary to actual Swift REPL:
/Applications/Xcode6-Beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift
Interesting. So Swift's speed stems from not doing things the Objective-C way.
How well does compatibility fare?
How well does compatibility fare?
In other news, the computer serving the article has evaporated due to overheating. By browser almost died.
https://www.youtube.com/watch?v=Ii-02vhsdVk