4 ms·

Really interesting work! I'm really happy that people at MIT are pushing forward Julia. In my opinion, Julia is incredibly powerful once you understand the lang

by davnn 6y ago

Really interesting work! I'm really happy that people at MIT are pushing forward Julia. In my opinion, Julia is incredibly powerful once you understand the language. It often feels like writing pseudocode that performs like C++. The ecosystem is still pretty barebones compared to Python, but, while I'm using both tools extensively, I begin to prefer Julia over Python more and more.

adenozine 6y ago
How do you deal with multiple dispatch? It really doesn't match up to any mental metaphors for me, I've always preferred my bag-of-functions to do things. I've tried and tried with Julia, is there any good resource for how dispatch programs are supposed to be built and thought about?
- DougBTX 6y ago
  Multiple dispatch is not too different to method overloading, so you could start there for comparable examples, maybe in programming languages you are more familiar with: https://en.wikipedia.org/wiki/Function_overloading#Rules_in_function_overloading https://en.wikipedia.org/wiki/Function_overloading#Rules_in_... Bag of functions isn't a bad way to think about it, even for Julia. In some languages, only the name of the function determines which function is called. In others, the number of arguments is used too, so eg foo/1 and foo/2 may be different functions. In Julia, the types matter too, so foo(::Int) and foo(::String) are different functions ("methods" in Julia terminology), and which is used is based on the type of the argument, rather than the number. That's where the magic in Julia happens, as if you define a function foo(x), without specifying any types, then the specific functions that foo call will only be determined once the type of the arguments to foo are known. But once they are known, that type information can ripple all the way down, picking up the specific implementation for each function depending on the actual types used.
- davnn 6y ago
  First and foremost you should have a general understanding of type inference. You also have to understand the difference between a function and a method (in Julia's terms), see: Functions: https://docs.julialang.org/en/v1/manual/functions/ https://docs.julialang.org/en/v1/manual/functions/ Methods: https://docs.julialang.org/en/v1/manual/methods/ https://docs.julialang.org/en/v1/manual/methods/ Once that's understood, multiple dispatch is simply using all of a function's arguments inferred types to choose which method should be invoked.
  - StefanKarpinski 6y ago
    Maybe you’re using the term loosely, but one definitely shouldn’t have to understand type inference to write working Julia programs. Unlike static type systems like Haskel or ML where inference is part of the spec, inference in Julia is just an optimization and doesn’t affect behavior at all.
    - davnn 6y ago
      Relating to other programming languages, it was the first term that came to mind. You have to know the type before you can specialize a function, don't you? I think it's a good mental model to constantly keep the types in mind, but I have made the experience that people working exclusively in dynamically typed languages, i.e. the majority of data scientists, don't share that mental model.
- mbauman 6y ago
  I actually find it far more linguistic, that is, more akin to natural languages. In my view, it's not multiple dispatch per se that is the bigger departure from traditional OOP, it's the fact that methods are no longer contained in the classes. Julia draws a separation between data (structs: the nouns) and behaviors (functions: the verbs). Traditional OOP never really made sense to me; why should each class define and own its own methods? It feels far more sensible to me to just have global behaviors that are well defined. Those verbs can sometimes apply to _anything_ (leaning on more rudimentary operations that you need to define; duck-typing), and sometimes they require you to explicitly define your behavior, and sometimes you just want to add an additional optimization that's available in your particular situation. Once you have that mental model down, multiple dispatch is just how Julia chooses which method to call... and it's really not much different from single-dispatch.
  - snicker7 6y ago
    > why should each class define and own its own methods? State mutations. That's it. By ensuring that your data can only be mutated by a your API, it can never get "corrupted".
    - mbauman 6y ago
      Sure, there is a subset of behaviors for which this style makes sense, but it's just as well supported by simply defining your own functions alongside the struct.
- SatvikBeri 6y ago
  I found this article by Chris Rackaukas to be pretty helpful: https://www.stochasticlifestyle.com/type-dispatch-design-post-object-oriented-programming-julia/ https://www.stochasticlifestyle.com/type-dispatch-design-pos...
- ddragon 6y ago
  Objects aren't bag-of-functions though (they have state, inheritance, initializers/destructors, interface/abstract classes, classes vs objects and tons of other concepts and patterns) and any complex program can become a large hierarchic tree of classes and graph of objects that goes way beyond a simple bag-of-function. Even modules that are almost literally bag-of-functions will scale quickly to something more complex. The point is that simple concepts are nice to explain for a beginner, but what actually built your intuition in how to use objects is the years and years learning and experiencing it's benefits and pitfalls. With multiple dispatch it's the same, but since few languages use it (and even fewer, if any, pushes it everywhere like Julia does) most people didn't experience this process. For me when I'm using a function I just consider them as self-contained abstractions over the arguments. For example there are hundreds of implementations of sum (+), which in practice I ignore and only think about the concept of addition no matter what arguments I give and I trust the compiler/library to find the optimal implementation of the concept or fail (meaning I have to write one myself). If I'm writing a method (or function) I consider arguments as whatever acts the way I need so that I can implement the the concept on them (for example if I'm writing a tensor sum I just consider arguments as n-dimensional iterable arrays and implement assuming that - and declare for the compiler when my method is applicable, without having to care about all other implementations of sum - if anyone needs a scalar sum them that person can implement it and through collaboration we all expand the concept of sum). And the fact that whoever uses a function can abstract away the implementation, and whoever writes a function can abstract away the whole extension of the arguments (through both duck typing and the fact that the compiler will deal with choosing the correct implementation of the concept) means everything plays along fine without having to deal with details of each side.
dunefox 6y ago
> The ecosystem is still pretty barebones compared to Python There's help: https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaInterop/RCall.jl https://github.com/JuliaInterop/RCall.jl Works like a charm.
- davnn 6y ago
  That seems to work really well. I didn't have use cases where I would prefer to call Python from Julia instead of using Python directly. Additionally, I think you also have to think about things like Documentation and Tooling.
- swagonomixxx 6y ago
  While this is an decent interim solution, I wouldn't want to call out to Python for anything running in production from Julia. Good for prototyping at home perhaps. A lot of the "scientific" Python packages (NumPy, SciPy, etc.) actually just call out to C libraries for the majority of their computation. I imagine Julia can do that already, or it can call out to something similar in the stdlib, so it doesn't really need integration with these Python packages other than just API familiarity. But is that worth the cost in performance?
  - dunefox 6y ago
    I don't care about production or performance much; I care about data analysis and machine/deep learning for NLP. Whatever lets me use the best language and packages is best and so far it's Julia with the ecosystems and tools from Python and R. I'm very certain that you can just import the underlying packages directly but this way is easiest, especially since I'm not familiar with R.
  - amkkma 6y ago
    People definitely have used PyCall in production. Julia at this point covers everything in NumPy, SciPy and much more. For optimization, bayesian stuff, scientific, and the convergence of the above with ML, it's far ahead- https://sciml.ai/ https://sciml.ai/ Even has relatively mature web frameworks (https://github.com/GenieFramework/Genie.jl https://github.com/GenieFramework/Genie.jl)

by davnn 6y ago

adenozine 6y ago

How do you deal with multiple dispatch? It really doesn't match up to any mental metaphors for me, I've always preferred my bag-of-functions to do things. I've tried and tried with Julia, is there any good resource for how dispatch programs are supposed to be built and thought about?

DougBTX 6y ago
Multiple dispatch is not too different to method overloading, so you could start there for comparable examples, maybe in programming languages you are more familiar with: https://en.wikipedia.org/wiki/Function_overloading#Rules_in_function_overloading https://en.wikipedia.org/wiki/Function_overloading#Rules_in_... Bag of functions isn't a bad way to think about it, even for Julia. In some languages, only the name of the function determines which function is called. In others, the number of arguments is used too, so eg foo/1 and foo/2 may be different functions. In Julia, the types matter too, so foo(::Int) and foo(::String) are different functions ("methods" in Julia terminology), and which is used is based on the type of the argument, rather than the number. That's where the magic in Julia happens, as if you define a function foo(x), without specifying any types, then the specific functions that foo call will only be determined once the type of the arguments to foo are known. But once they are known, that type information can ripple all the way down, picking up the specific implementation for each function depending on the actual types used.
davnn 6y ago
First and foremost you should have a general understanding of type inference. You also have to understand the difference between a function and a method (in Julia's terms), see: Functions: https://docs.julialang.org/en/v1/manual/functions/ https://docs.julialang.org/en/v1/manual/functions/ Methods: https://docs.julialang.org/en/v1/manual/methods/ https://docs.julialang.org/en/v1/manual/methods/ Once that's understood, multiple dispatch is simply using all of a function's arguments inferred types to choose which method should be invoked.
- StefanKarpinski 6y ago
  Maybe you’re using the term loosely, but one definitely shouldn’t have to understand type inference to write working Julia programs. Unlike static type systems like Haskel or ML where inference is part of the spec, inference in Julia is just an optimization and doesn’t affect behavior at all.
  - davnn 6y ago
    Relating to other programming languages, it was the first term that came to mind. You have to know the type before you can specialize a function, don't you? I think it's a good mental model to constantly keep the types in mind, but I have made the experience that people working exclusively in dynamically typed languages, i.e. the majority of data scientists, don't share that mental model.
mbauman 6y ago
I actually find it far more linguistic, that is, more akin to natural languages. In my view, it's not multiple dispatch per se that is the bigger departure from traditional OOP, it's the fact that methods are no longer contained in the classes. Julia draws a separation between data (structs: the nouns) and behaviors (functions: the verbs). Traditional OOP never really made sense to me; why should each class define and own its own methods? It feels far more sensible to me to just have global behaviors that are well defined. Those verbs can sometimes apply to _anything_ (leaning on more rudimentary operations that you need to define; duck-typing), and sometimes they require you to explicitly define your behavior, and sometimes you just want to add an additional optimization that's available in your particular situation. Once you have that mental model down, multiple dispatch is just how Julia chooses which method to call... and it's really not much different from single-dispatch.
- snicker7 6y ago
  > why should each class define and own its own methods? State mutations. That's it. By ensuring that your data can only be mutated by a your API, it can never get "corrupted".
  - mbauman 6y ago
    Sure, there is a subset of behaviors for which this style makes sense, but it's just as well supported by simply defining your own functions alongside the struct.
SatvikBeri 6y ago
I found this article by Chris Rackaukas to be pretty helpful: https://www.stochasticlifestyle.com/type-dispatch-design-post-object-oriented-programming-julia/ https://www.stochasticlifestyle.com/type-dispatch-design-pos...
ddragon 6y ago
Objects aren't bag-of-functions though (they have state, inheritance, initializers/destructors, interface/abstract classes, classes vs objects and tons of other concepts and patterns) and any complex program can become a large hierarchic tree of classes and graph of objects that goes way beyond a simple bag-of-function. Even modules that are almost literally bag-of-functions will scale quickly to something more complex. The point is that simple concepts are nice to explain for a beginner, but what actually built your intuition in how to use objects is the years and years learning and experiencing it's benefits and pitfalls. With multiple dispatch it's the same, but since few languages use it (and even fewer, if any, pushes it everywhere like Julia does) most people didn't experience this process. For me when I'm using a function I just consider them as self-contained abstractions over the arguments. For example there are hundreds of implementations of sum (+), which in practice I ignore and only think about the concept of addition no matter what arguments I give and I trust the compiler/library to find the optimal implementation of the concept or fail (meaning I have to write one myself). If I'm writing a method (or function) I consider arguments as whatever acts the way I need so that I can implement the the concept on them (for example if I'm writing a tensor sum I just consider arguments as n-dimensional iterable arrays and implement assuming that - and declare for the compiler when my method is applicable, without having to care about all other implementations of sum - if anyone needs a scalar sum them that person can implement it and through collaboration we all expand the concept of sum). And the fact that whoever uses a function can abstract away the implementation, and whoever writes a function can abstract away the whole extension of the arguments (through both duck typing and the fact that the compiler will deal with choosing the correct implementation of the concept) means everything plays along fine without having to deal with details of each side.

dunefox 6y ago

> The ecosystem is still pretty barebones compared to Python There's help: https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaInterop/RCall.jl https://github.com/JuliaInterop/RCall.jl Works like a charm.

davnn 6y ago
That seems to work really well. I didn't have use cases where I would prefer to call Python from Julia instead of using Python directly. Additionally, I think you also have to think about things like Documentation and Tooling.
swagonomixxx 6y ago
While this is an decent interim solution, I wouldn't want to call out to Python for anything running in production from Julia. Good for prototyping at home perhaps. A lot of the "scientific" Python packages (NumPy, SciPy, etc.) actually just call out to C libraries for the majority of their computation. I imagine Julia can do that already, or it can call out to something similar in the stdlib, so it doesn't really need integration with these Python packages other than just API familiarity. But is that worth the cost in performance?
- dunefox 6y ago
  I don't care about production or performance much; I care about data analysis and machine/deep learning for NLP. Whatever lets me use the best language and packages is best and so far it's Julia with the ecosystems and tools from Python and R. I'm very certain that you can just import the underlying packages directly but this way is easiest, especially since I'm not familiar with R.
- amkkma 6y ago
  People definitely have used PyCall in production. Julia at this point covers everything in NumPy, SciPy and much more. For optimization, bayesian stuff, scientific, and the convergence of the above with ML, it's far ahead- https://sciml.ai/ https://sciml.ai/ Even has relatively mature web frameworks (https://github.com/GenieFramework/Genie.jl https://github.com/GenieFramework/Genie.jl)