3 ms·

> It's not just C interop, but the presence of mature dataframe libraries, a linear algebra layer (that doesn't involve direct calls to BLAS or Lapack), etc. A

by skohan 8y ago

> It's not just C interop, but the presence of mature dataframe libraries, a linear algebra layer (that doesn't involve direct calls to BLAS or Lapack), etc. Actually I think thst's something which is very strong about the TensorFlow for Swift effort: it allows you to call Python out of the box, so all the Python tooling which is currently available to data scientists is immediately available. It seems the goal of the project is to allow users to immediately take advantage of the convenience of swift (especially the type system) in an incremental way, leaving most of their workflow intact. They're also already bringing a lot of numerical computing utilities into the language itself. It already has native linear algebraic operators like dot product built in, and automatic differentiation is coming. > I use Windows at work (because bigcorp) and there's currently no officially sanctioned Swift I can install, but there's an official Julia binary. So I currently experiment with it using Docker, which you could do on Windows. I know that's not as good as official support, but it is possible. Anyway, I haven't worked with Julia beyond playing with the REPL a bit, and maybe it would have also been a great choice for TensorFlow. At the same time, I do wonder if there's an irrational component to the reticence around Swift for TensorFlow based on the fact that people still identify it as a somehow proprietary language. I find it very nice to work with and I would be happy to use it in more places where Python is currently the main option. Also the TensorFlow team seems to be doing some very interesting things with it.

wenc 8y ago
Thanks for your thoughts and for the additional info. > At the same time, I do wonder if there's an irrational component to the reticence around Swift for TensorFlow based on the fact that people still identify it as a somehow proprietary language. I'm sure there's some of that, but my feeling is -- and I speak only for myself and maybe some in my tribe -- that it isn't so much the perception of Swift as a proprietary language but more that it isn't a language designed for DS/ML/applied math and maybe the Swift community doesn't really get our needs, whereas Julia is and does. Python feels like the latter too -- it was swiftly adopted in DS/ML because it was already used heavily in scientific computing, which is part of the same family. The community vibe alignment isn't quite there with Swift -- it has no history in numerical computation and it came into the scene because a team at Google said so, whereas Julia and Python grew organically from the communities that do the same work we do, and were trying to solve the same problems we were. There's skin in the game and a kind of depth as it were. But it's just a feeling. I will leave it at that.
- skohan 8y ago
  > The community vibe alignment isn't quite there with Swift -- it had no history in numerical computation and it came into the scene because a team at Google said so, whereas Julia and Python grew organically from the communities that do the same work we do, and were trying to solve the same problems we were. There's skin in the game and depth as it were. It's an interesting perspective, and I think my own tribal bias as a software engineer plays in to my gut feeling on the topic. To me it's natural to see it in these terms: who's going to make a better saw: a metal worker or a wood worker? The woodworker might know exactly what he wants out of a saw, but the metal worker is a heck of a lot better making things out of metal. But that's just my biased opinion.
  - wenc 8y ago
    To use your analogy: A good saw is spec'ed by a woodworker and made by a metalworker. A great saw is made by a metalworker who is also a woodworker. This latter bit is true for the Python community, at least for the people and companies who write DS/ML tooling in Python. Excepting hobbyist/academic tooling, Python has some really high-quality DS/ML tooling built by people who know software and the problem domain. Julia seems to following the same path though it's not as far along as Python, but from what I've seen, Julia folks are numerical computation folks who also really understand software. At present, Swift is like a metalworker who's seen saws used by woodworkers but isn't really into woodworking (yet) and doesn't have a whole lot of experience with the woodworking craft.
    - skohan 8y ago
      > A good saw is spec'ed by a woodworker and made by a metalworker. So this is what I see in the TensorFlow for Swift project. If you look at the core contributors, you have a team of ML experts, as well as the original creator of the language. It still remains to be seen how it will go, but it seems like the right group of people to go about this effort. > Python has some really high-quality DS/ML tooling built by people who know software and the problem domain. See that's where you lose me a bit. There is a lot of really exceptional work done in Python, but in my view that's in spite of the language. Python strikes me as as a language which has been adopted in the scientific community because it's low barrier to entry makes it approachable to non-expert programmers, but comes up lacking when compared to modern programming languages. Between the version fragmentation, environment management, type system and the nature of runtime errors there are a lot of pain points which are already solved problems in other languages. When I have to work in Python, I am not particularly happy to do so. Maybe Julia solves these problems. But I also wonder whether the scientific/ML community really knows what they're missing.

by skohan 8y ago

wenc 8y ago

Thanks for your thoughts and for the additional info. > At the same time, I do wonder if there's an irrational component to the reticence around Swift for TensorFlow based on the fact that people still identify it as a somehow proprietary language. I'm sure there's some of that, but my feeling is -- and I speak only for myself and maybe some in my tribe -- that it isn't so much the perception of Swift as a proprietary language but more that it isn't a language designed for DS/ML/applied math and maybe the Swift community doesn't really get our needs, whereas Julia is and does. Python feels like the latter too -- it was swiftly adopted in DS/ML because it was already used heavily in scientific computing, which is part of the same family. The community vibe alignment isn't quite there with Swift -- it has no history in numerical computation and it came into the scene because a team at Google said so, whereas Julia and Python grew organically from the communities that do the same work we do, and were trying to solve the same problems we were. There's skin in the game and a kind of depth as it were. But it's just a feeling. I will leave it at that.

skohan 8y ago
> The community vibe alignment isn't quite there with Swift -- it had no history in numerical computation and it came into the scene because a team at Google said so, whereas Julia and Python grew organically from the communities that do the same work we do, and were trying to solve the same problems we were. There's skin in the game and depth as it were. It's an interesting perspective, and I think my own tribal bias as a software engineer plays in to my gut feeling on the topic. To me it's natural to see it in these terms: who's going to make a better saw: a metal worker or a wood worker? The woodworker might know exactly what he wants out of a saw, but the metal worker is a heck of a lot better making things out of metal. But that's just my biased opinion.
- wenc 8y ago
  To use your analogy: A good saw is spec'ed by a woodworker and made by a metalworker. A great saw is made by a metalworker who is also a woodworker. This latter bit is true for the Python community, at least for the people and companies who write DS/ML tooling in Python. Excepting hobbyist/academic tooling, Python has some really high-quality DS/ML tooling built by people who know software and the problem domain. Julia seems to following the same path though it's not as far along as Python, but from what I've seen, Julia folks are numerical computation folks who also really understand software. At present, Swift is like a metalworker who's seen saws used by woodworkers but isn't really into woodworking (yet) and doesn't have a whole lot of experience with the woodworking craft.
  - skohan 8y ago
    > A good saw is spec'ed by a woodworker and made by a metalworker. So this is what I see in the TensorFlow for Swift project. If you look at the core contributors, you have a team of ML experts, as well as the original creator of the language. It still remains to be seen how it will go, but it seems like the right group of people to go about this effort. > Python has some really high-quality DS/ML tooling built by people who know software and the problem domain. See that's where you lose me a bit. There is a lot of really exceptional work done in Python, but in my view that's in spite of the language. Python strikes me as as a language which has been adopted in the scientific community because it's low barrier to entry makes it approachable to non-expert programmers, but comes up lacking when compared to modern programming languages. Between the version fragmentation, environment management, type system and the nature of runtime errors there are a lot of pain points which are already solved problems in other languages. When I have to work in Python, I am not particularly happy to do so. Maybe Julia solves these problems. But I also wonder whether the scientific/ML community really knows what they're missing.