1. 8
  1. 4

    I don’t understand this at all. Admittedly I haven’t worked with commercial AI implementations but this whole “differentiable programming” thing seem like a bizarre misplacement of responsibility. Computing a differential is hardly ever a problem, especially not one that requires new syntax and buzzwords.

    Am I mistaken? Do people who implement AI algorithms really benefit from this addition? How?

    1. 3

      Don’t you worry, I am on the same page. I fail to understand Software 2.0 and how would it apply outside of machine learning. I also do not understand the hype that is surrounding machine learning (or we should call it San Francisco flavoured statistics). The example they gave in the article absolutely lacks any details that would make it understandable for people outside of the ML bubble what is going on.

      1. 3

        I’m actually on a slightly different page. I don’t see how this helps people inside machine learning. I’m fairly confident it won’t help researchers much, but it might help people who implement things. I just wonder how.

      2. 1

        a bizarre misplacement of responsibility

        It’s nice when responsibility is with “algorithms” rather than engineering teams, especially when things go south.

      3. 3

        Without a corresponding announcement from JetBrains, this kinda feels like a hostile fork, especially given how the article lacks any kind if info about its future relationship with “JetBrains Kotlin”.

        The extensions themselves … look a lot like they were done by people with little design experience, opting for the “let’s add keyword and special syntax all over the place”.

        1. 2

          We will see in the next a few days whether it is in collaboration with JetBrains. But yes, the whole announcement looks weird. It seems take very similar design points from Swift for TensorFlow and transplanted to Kotlin. Maybe it is a PyTorch v.s. TensorFlow rivalry thing again? But there is no mention of PyTorch as well. Given a few days with their code release would clarify a lot of things.

          1. 1

            let’s add keyword and special syntax all over the place

            Supporting that, wouldn’t it be much nicer if every function was “differentiable” by default and the compiler decides to remove the attribute if not applicable instead of explicitly specifying it? Or if it has to remain, kotlin already has the decorator syntax.

          2. 2

            So with async/noasync functions we’ve got red/blue functions, now with differentiable/non-differentiable do we go all the way to CMYK functions? 😂