3 ms·

I have to confess to some confusion about how all these Tensorflow for Swift changes work. Is this being built into a tensorflow-ey fork of Swift? Is it on th

I have to confess to some confusion about how all these Tensorflow for Swift changes work. Is this being built into a tensorflow-ey fork of Swift? Is it on the roadmap for being incorporated into the core language? How does one tell from these Github manifestos?

afthonos 8y ago
Swift for Tensorflow adds language-level support for Tensorflow to Swift. It does start in the fork, but the ultimate goal is for all changes to be merged upstream. Some aspects, like dynamicLookup[0], which allows dot syntax for methods resolved at runtime, are already in the language. Others, like dynamicCallable[1] are accepted proposals. [0] https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md https://github.com/apple/swift-evolution/blob/master/proposa... [2] https://github.com/apple/swift-evolution/blob/master/proposals/0216-dynamic-callable.md https://github.com/apple/swift-evolution/blob/master/proposa...
- saagarjha 8y ago
  > It does start in the fork, but the ultimate goal is for all changes to be merged upstream. Some aspects, like dynamicLookup[0], which allows dot syntax for methods resolved at runtime, are already in the language. Personally, I feel like it would be unwise to merge in all of TensorFlow's requirements into Swift. Many features, such as the ones you mentioned, are actually useful to outside of the context of machine learning, so it does actually make sense to make them generally available. But compiler support for something as specific as @differentiable seems like an anti-goal for Swift.
  - bmc7505 8y ago
    The idea is that in the not-too-distant-future, differentiable programming will become much more mainstream. c.f. https://medium.com/@karpathy/software-2-0-a64152b37c35 https://medium.com/@karpathy/software-2-0-a64152b37c35
    - saagarjha 8y ago
      Ok, but to use terms from that article, Swift is still very much "Software 1.0". It's a general-purpose programming language meant to be written by people. Sure, it's good that people are trying to extend it to fit their specific needs, but I don't think that Swift (or any commonly used language today) is anywhere near being "good" for these types of tasks.
    - wool_gather 8y ago
      > Neural networks [...] represent the beginning of a fundamental shift in how we write software. That's an...interesting statement, considering that neural networks are nearly as old as software itself. The original Pitts-McCulloch paper was published in 1943. Active use of them has certainly been ongoing longer than that blog author has been alive.
      - tree_of_item 8y ago
        And yet it's true, since they haven't been used in the way they are now. There was no DeepMind in 1943. Computer science stuff usually takes a few decades to mature.
- paultopia 8y ago
  Thank you. It's weird---Swift is a beautiful language as a language, but all these ecosystem things make it really really hard to use. (The worst IMO is package management---like, some libraries require cocoapods, and some work with swift package manager, but swift package manager for swift 3 and 4 are totally different, and how does Xcode vs command line fit into all of this and libraries vs frameworks and COME ON IT SHOULDN'T BE THIS HARD!)
  - skohan 8y ago
    As someone who wants to see Swift succeed as a main-stream language I could not agree with you more. I can forgive the API differences between SPM for swift 3 and 4, after all the ecosystem is evolving and I'm a fan of iterating interfaces early rather than having to keep early mistakes in the spec _forever_ for the sake of backward compatibility. But the Package Manager is still pretty far from being nice to use. In several of my projects which are using it, I also have a custom CLI implemented to streamline some of the worst pain points. As far as dependency management, I think a huge issue is the lack of proper support for Swift Package Manager for iOS projects. Apple's 1st class solution for including software modules in iOS projects is "Just drag the framework into your XCode project", which is of course an absurd solution for any serious workflow. Cocoapods (and to a lesser extent Carthage) have stepped in to fill the gap as 3rd party solutions, but there's still no real way to use Swift Package Manager to manage the dependancies for an iOS project. As a result a lot of libraries don't even bother with SPM support since the largest portion of their target audience will never use it. And thus adoption is slow, so there's not a large user-base demanding improvements.

afthonos 8y ago

Swift for Tensorflow adds language-level support for Tensorflow to Swift. It does start in the fork, but the ultimate goal is for all changes to be merged upstream. Some aspects, like dynamicLookup[0], which allows dot syntax for methods resolved at runtime, are already in the language. Others, like dynamicCallable[1] are accepted proposals. [0] https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md https://github.com/apple/swift-evolution/blob/master/proposa... [2] https://github.com/apple/swift-evolution/blob/master/proposals/0216-dynamic-callable.md https://github.com/apple/swift-evolution/blob/master/proposa...

saagarjha 8y ago
> It does start in the fork, but the ultimate goal is for all changes to be merged upstream. Some aspects, like dynamicLookup[0], which allows dot syntax for methods resolved at runtime, are already in the language. Personally, I feel like it would be unwise to merge in all of TensorFlow's requirements into Swift. Many features, such as the ones you mentioned, are actually useful to outside of the context of machine learning, so it does actually make sense to make them generally available. But compiler support for something as specific as @differentiable seems like an anti-goal for Swift.
- bmc7505 8y ago
  The idea is that in the not-too-distant-future, differentiable programming will become much more mainstream. c.f. https://medium.com/@karpathy/software-2-0-a64152b37c35 https://medium.com/@karpathy/software-2-0-a64152b37c35
  - saagarjha 8y ago
    Ok, but to use terms from that article, Swift is still very much "Software 1.0". It's a general-purpose programming language meant to be written by people. Sure, it's good that people are trying to extend it to fit their specific needs, but I don't think that Swift (or any commonly used language today) is anywhere near being "good" for these types of tasks.
  - wool_gather 8y ago
    > Neural networks [...] represent the beginning of a fundamental shift in how we write software. That's an...interesting statement, considering that neural networks are nearly as old as software itself. The original Pitts-McCulloch paper was published in 1943. Active use of them has certainly been ongoing longer than that blog author has been alive.
    - tree_of_item 8y ago
      And yet it's true, since they haven't been used in the way they are now. There was no DeepMind in 1943. Computer science stuff usually takes a few decades to mature.
paultopia 8y ago
Thank you. It's weird---Swift is a beautiful language as a language, but all these ecosystem things make it really really hard to use. (The worst IMO is package management---like, some libraries require cocoapods, and some work with swift package manager, but swift package manager for swift 3 and 4 are totally different, and how does Xcode vs command line fit into all of this and libraries vs frameworks and COME ON IT SHOULDN'T BE THIS HARD!)
- skohan 8y ago
  As someone who wants to see Swift succeed as a main-stream language I could not agree with you more. I can forgive the API differences between SPM for swift 3 and 4, after all the ecosystem is evolving and I'm a fan of iterating interfaces early rather than having to keep early mistakes in the spec _forever_ for the sake of backward compatibility. But the Package Manager is still pretty far from being nice to use. In several of my projects which are using it, I also have a custom CLI implemented to streamline some of the worst pain points. As far as dependency management, I think a huge issue is the lack of proper support for Swift Package Manager for iOS projects. Apple's 1st class solution for including software modules in iOS projects is "Just drag the framework into your XCode project", which is of course an absurd solution for any serious workflow. Cocoapods (and to a lesser extent Carthage) have stepped in to fill the gap as 3rd party solutions, but there's still no real way to use Swift Package Manager to manage the dependancies for an iOS project. As a result a lot of libraries don't even bother with SPM support since the largest portion of their target audience will never use it. And thus adoption is slow, so there's not a large user-base demanding improvements.