361–370 of 458 posts
Github repo is live now. https://github.com/apple/swift First ever commit found here https://github.com/apple/swift/commit/afc81c1855bf711315b8e5...
It's really interesting that they decided to retain the full history! It also gives away some information about the initial contributors and the timeframe of when they started.
As good as Swift is, putting it by default in asinine paths like "/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin" doesn't help anybody (and a ton of stuff in OS X is like this).
A more Unixy way to do this would be /opt/swift-3.0/bin, where /opt/swift is a symlink to /opt/swift-3.0. Even Apple used to limit the path insanity to merely /Developer/usr/bin. Not sure what happened...
I would love to see Swift for Android programing. I'm already using Kotlin, a language very close to Swift, for programming our Android apps. But I find Swift niftier than Kotlin.
Earlier quoted context omitted.
Historically they haven't been, and the page about planning for Swift 3.0 says it will introduce breaking changes. (It also mentions that Swift 2.2 will be released in the interim and its compiler will try to warn about things that will be broken in 3.0 so you can get your code ready early.)
It's interesting to compare Swift 2 -> 3 to the Python 2 -> 3 upgrade experience. Apple will simply break whatever they need to break to get the improvements they decide would be valuable, move on, and anyone who doesn't follow is likely to be left in the dust. Frankly, I welcome it after years of feeling like the only Python 3 user on Earth. For the next few years, I expect Apple will wield a great deal more power o…
This is pretty awesome. If all of the platform dependencies could be abstracted away, this could form the core of yet another cross-mobile-platform development framework, but with better performance and richer tooling. I think it really depends on how much control Apple intends to exercise over the IP. Could someone fork it and use it to create a mobile platform that would be free from legal harassment if it competed…
Why not bridge the "yet another cross-mobile-platform development framework(s)" that were written for Objective-C, the same way Apple did with their frameworks? There is no need to restart them all over again in Swift to access them in Swift.
Perhaps you were attempting to suggest that no quality cross-platform frameworks ever materialized for cross-platform development under Objective-C? (there were certainly attempts, including from big players) But if that is the case, I'm not sure an arguably better, but not dramatically different, language is going to change anything.
There's one thing I can't understand about Apple's approach, and that is their pathnames. As good as Swift is, putting it by default in asinine paths like "/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin" doesn't help anybody (and a ton of stuff in OS X is like this). A more Unixy way to do this would be /opt/swift-3.0/bin, where /opt/swift is a symlink to /opt/swift-3.0. Even Apple used to limit the p…
Earlier quoted context omitted.
There's different definitions of scale. He is talking about from an engineering perspective and at Google we have seen nothing other than a few periphery sites being written in Go. I fully agree that Go is a poor language if you are building a large, monolithic application.
> I fully agree that Go is a poor language if you are building a large, monolithic application. I find that statement hilarious considering that it was explicitly one of the design considerations[1] for Go. So they either failed massively, or there's a difference in perspective on what a good language for programming in the large is. From Rob Pike's talk[1]: > Go was designed to address the problems faced in software…
Isn't it hilarious that a statement from the Go authors could be used as evidence of its awesomeness given how the authors are naturally and heavily biased?
Very nice that you can debug functions in the repl and set breakpoints: https://swift.org/lldb/#why-combine-the-repl-and-debugger I don't know any other repl that can do that. I know you can debug in (some) lisps and smalltalk, but I don't know if you can set breakpoints too. Still a nice and welcome feature.
There's one thing I can't understand about Apple's approach, and that is their pathnames. As good as Swift is, putting it by default in asinine paths like "/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin" doesn't help anybody (and a ton of stuff in OS X is like this). A more Unixy way to do this would be /opt/swift-3.0/bin, where /opt/swift is a symlink to /opt/swift-3.0. Even Apple used to limit the p…
Not defending the practice, but you can use 'xcrun' to find and run these binaries. E.g. to find swiftc, you can use 'xcrun -f swiftc', and to run it, 'xcrun swiftc'.