1. 13

  2. 3

    That was fast. I didn’t understand the point of this at the time anyway, we already have Python and Julia for this area.

    1. 3

      It is always an over-ambitious project with the real possibility to fail. The “innovation” is to have autodiff done within the compiler so every program can be differentiated with the compiler. In that scenario, libraries like TensorFlow won’t need to handle autodiff at all, they just need to provide accelerated computation on tensors.

      That has been said, maintaining a fork of a compiler toolchain with a fast-moving upstream is risky. Considering Swift still in the progress of adding language constructs such as async / await, maintaining S4TF fork must be of very high cost.

      Maybe, just maybe, if Swift supports a stable compiler plugin interface, S4TF can co-evolve with the mainline, and there will be a lot of community participation. Personally, I never wanted to use S4TF toolchain because I had other development in my local environment and would love to keep it in sync with the latest mainline toolchain.

      1. 2

        I won’t pretend to understand it fully, but it looks like a very complex language extension that’s only useful in one specialized area (machine learning, maybe some other parts of mathematical computing.) So it doesn’t seem like a good fit for a general purpose language like Swift.

        1. 2

          Julia is a pretty fledgling language, even at this point. The beginnings of differentiable programming in Swift are a lot earlier.

        2. 2

          And this is why you don’t let buzzword kids/scientists push new language features into your language.

          They will be gone, and you’ll be stuck doing maintenance of these features forever.

          1. 4

            It is still in Pitch stage: https://forums.swift.org/t/differentiable-programming-for-gradient-based-machine-learning/42147

            The things got in, such as the DynamicMemberLookup, dynamicCallable, callable are generally useful. The PythonKit binding is actually pretty brilliant. The swift-jupyter notebook integration is passable and generally just wraps the main Swift REPL.

            Overall, I don’t think Swift as a language carried much baggage due to the ambition of S4TF.

            1. 4

              buzzword kids/scientists

              Are you referring to Chris Lattner as a buzzword kid? He created LLVM and Swift.

              1. 2

                Remember how Guido joined dropbox and dropbox started working on some SOOPER FAST python version which they later killed after they couldn’t make it work? And unless I’m outdated they still haven’t completely migrated from py2 -> 3? Chris Lattner isn’t the buzzword kid, it’s the fans.

                1. 2

                  I believe pyston is developed outside of Dropbox now, and it seems to be a python3 compatible implementation.

                  source: https://blog.pyston.org/2020/10/28/pyston-v2-20-faster-python/

                  1. 2

                    But it’s also closed-source, so it might as well be dead. They’re no longer contributing to the rest of the community.

                    I think that the parent post’s point was that corporate development of Python JITs seems to have a lot of conceptual overlap with corporate development of automatic differentiation; it’s useful technology in a particular climate, but requires a long-standing community tradition in order to stay maintained, and involves deep knowledge of how to write interpreters for the complete language under study.

                    1. 1

                      Right, they last sponsored the project in 2017. My point was that the project probably gained steam because the language designer was there.

                  2. 1

                    No, why?

                  3. 1

                    It wasn’t ever mainlined, right? Differentiable Swift was a first-party sanctioned fork afaik.