71–80 of 151 posts
Earlier quoted context omitted.
My machine is too old to upgrade to High Sierra.
https://support.apple.com/kb/SP765?locale=en_US > MacBook Pro (Mid 2010 or newer) So your 2011 should be supported. If it's actually an older machine, compiling from source is an option, if slightly inconvenient.
Swift for Tensorflow might work if the scope is to create a client side model definition loader natively for various TF models.
Nobody use Swift seriously for server side training, there is no point in doing so except to add swift to the list of language that claim to do deep learning but in reality nobody will consider them.
I also wonder how much of this coincidentally lines up with Chris Lattner landing at Google. As Chris will admit, and as was left out of this analysis, Swift has also been given the humble goal of achieving world domination. All joking aside I'm very thrilled about this and have enjoyed tremendously watching the Swift language mature since its launch due in large part to the open source community and the Swift team's…
This was not in process before Chris came, it was a project he suggested and started pushing on?
What is there to be coincidental?
Earlier quoted context omitted.
More to the point static typing is just not that important for data scientists. Arguably it's not that important for backends devs either (e.g. lisp, erlang).
Should be prefaced with, "I think". Having done user research on this by speaking to data scientists, I can say that static typing is desired by a nonzero number of who practice what we would consider to be data science and machine learning. Much like how TypeScript is seen as a revelation to hordes of JavaScript programmers who have never used static types before, the ability to get some level of correctness verific…
It's interesting how it's going to play out. On one hand side, Swift is a pleasant language to work with (despite its infancy). But on the other, having a Tensorflow API doesn't suddenly give it a bunch of libraries for statistics, comp. vision, modeling, visualisation, etc. that Python/R/Julia cough MATLAB cough have. Nowadays, it's difficult enough to convince people to drop e.g. MATLAB for R or Python for Julia (l…
Their focus is more on the c bindings and allowing other people to build what they want on top of that.
Other language bindings aren't generally going to be used for anything more than inference. First class actual data science work isn't going to happen in other languages anytime soon (at least outside of julia and R which are at least trying to compete in this niche).
Earlier quoted context omitted.
Should be prefaced with, "I think". Having done user research on this by speaking to data scientists, I can say that static typing is desired by a nonzero number of who practice what we would consider to be data science and machine learning. Much like how TypeScript is seen as a revelation to hordes of JavaScript programmers who have never used static types before, the ability to get some level of correctness verific…
Correctness verification at the level that data scientists need can generally be achieved with optional typing (presuming a well designed type system)
Enter stage left: Julia
Julia is already pretty great, I'd really love to see what cool stuff we could have with a swell in community size and investment!
It's interesting how it's going to play out. On one hand side, Swift is a pleasant language to work with (despite its infancy). But on the other, having a Tensorflow API doesn't suddenly give it a bunch of libraries for statistics, comp. vision, modeling, visualisation, etc. that Python/R/Julia cough MATLAB cough have. Nowadays, it's difficult enough to convince people to drop e.g. MATLAB for R or Python for Julia (l…
Earlier quoted context omitted.
Correctness verification at the level that data scientists need can generally be achieved with optional typing (presuming a well designed type system)
> achieved with optional typing (presuming a well designed type system) Enter stage left: Julia Julia is already pretty great, I'd really love to see what cool stuff we could have with a swell in community size and investment!
On the one hand, we do want full access to the programming model exposed by the component -- its control structures, abstractions, everything else. One the other hand, these are mostly duplicated by our host programming language: it's going to have variable bindings, operators, iteration, conditionals and everything else. Doing an embedding like this is a way to expose most of the component's facilities without introducing a ton of "new syntax" in the form of combinators or having programs where a lot of the critical code is escaped in strings.
This same problem shows up in programming interfaces to RDBMSes. LINQ is a good example of the same embedding technique.