5 ms·

Arguably it may also be because without JAOT compilation as in Julia, multiple dispatch normally comes with a significant runtime performance cost, as far as I

Arguably it may also be because without JAOT compilation as in Julia, multiple dispatch normally comes with a significant runtime performance cost, as far as I understand.

lispm 6y ago
Languages have addressed that in a variety of ways before Julia.
- eigenspace 6y ago
  I'm not aware of any that had the sort of complementary designs between the compilation model and multiple dispatch. E.g. in Common Lisp, two of the most important functions for multiple dispatch, addition and multiplication aren't generic functions and need to be shadowed and replaced by generic functions if you want multiple dispatch. My understanding is that they did this for performance reasons, but julia doesn't have any performance degradation from making literally everything other than like 5 builtins generic functions because of the way it's compilation model dovetails with multiple dispatch. I just checked in my repl and in my current session with a few packages loaded, + has 195 methods defined on it and * has 347 methods. If you look at https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_pract... they present some evidence that multiple dispatch sees far more use in julia than other languages.
  - lispm 6y ago
    Dylan was/is generic functions everywhere. > need to be shadowed and replaced by generic functions if you want multiple dispatch. yeah, but there are extensions for some Common Lisp implementations which would allow that with reasonable speed. I've seen a bunch of CLOS extensions in recent years in that direction. > ulia doesn't have any performance degradation Common Lisp generally has a different generic function model from Julia. It's extremely dynamic with an optional meta-object system. Thus its use case is different. But: for example a CLOS-based CAD system might use generic functions everywhere and needs the respective performance for that. > I just checked in my repl and in my current session with a few packages loaded, + has 195 methods defined on it and * has 347 methods. In CLOS one would not like that design. Though there also might be generic functions with many methods. My default CL has for example 84 print-object methods, some might have hundreds. Though generally it is not seen as desirable to group semantically very different operations under one name - especially given that CLOS provides different types of method combinations and a CLOS generic function might create a more complex interface. CLOS has before, after, around and primary methods for a default method combination. One can write arbitrary new combinations and have different ways to dispatch, different inheritance strategies, etc. Thus its optimization problems to provide faster dispatch is different from what Julia wants to address. Dylan then for example had to address the 'generic function everywhere' problem. There binary+ is a generic function.
    - eigenspace 6y ago
      > In CLOS one would not like that design. Though there also might be generic functions with many methods. My default CL has for example 84 print-object methods, some might have hundreds. Though generally it is not seen as desirable to group semantically very different operations under one name - especially given that CLOS provides different types of method combinations and a CLOS generic function might create a more complex interface. Totally agreed here. However, addition, multiplication and so on have a very uniform and well defined set of semantics that apply to many types from all the various representations of real and complex numbers to the many many different types of matrices in Julia's LinearAlgebra library (lots of wrappers for things like Symmetric, or Tridiagonal matrices, lazy matrix factorization objects, adjoint matrices, etc.) That's why there's so many methods on addition and multiplication in julia, and why I found it so surprising that CL doesn't do this on purpose. But I get that scientific computing isn't as big a part of the demographics in the CL community so I guess it makes sense.

Arguably it may also be because without JAOT compilation as in Julia, multiple dispatch normally comes with a significant runtime performance cost, as far as I understand.

lispm 6y ago

Languages have addressed that in a variety of ways before Julia.

eigenspace 6y ago
I'm not aware of any that had the sort of complementary designs between the compilation model and multiple dispatch. E.g. in Common Lisp, two of the most important functions for multiple dispatch, addition and multiplication aren't generic functions and need to be shadowed and replaced by generic functions if you want multiple dispatch. My understanding is that they did this for performance reasons, but julia doesn't have any performance degradation from making literally everything other than like 5 builtins generic functions because of the way it's compilation model dovetails with multiple dispatch. I just checked in my repl and in my current session with a few packages loaded, + has 195 methods defined on it and * has 347 methods. If you look at https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_pract... they present some evidence that multiple dispatch sees far more use in julia than other languages.
- lispm 6y ago
  Dylan was/is generic functions everywhere. > need to be shadowed and replaced by generic functions if you want multiple dispatch. yeah, but there are extensions for some Common Lisp implementations which would allow that with reasonable speed. I've seen a bunch of CLOS extensions in recent years in that direction. > ulia doesn't have any performance degradation Common Lisp generally has a different generic function model from Julia. It's extremely dynamic with an optional meta-object system. Thus its use case is different. But: for example a CLOS-based CAD system might use generic functions everywhere and needs the respective performance for that. > I just checked in my repl and in my current session with a few packages loaded, + has 195 methods defined on it and * has 347 methods. In CLOS one would not like that design. Though there also might be generic functions with many methods. My default CL has for example 84 print-object methods, some might have hundreds. Though generally it is not seen as desirable to group semantically very different operations under one name - especially given that CLOS provides different types of method combinations and a CLOS generic function might create a more complex interface. CLOS has before, after, around and primary methods for a default method combination. One can write arbitrary new combinations and have different ways to dispatch, different inheritance strategies, etc. Thus its optimization problems to provide faster dispatch is different from what Julia wants to address. Dylan then for example had to address the 'generic function everywhere' problem. There binary+ is a generic function.
  - eigenspace 6y ago
    > In CLOS one would not like that design. Though there also might be generic functions with many methods. My default CL has for example 84 print-object methods, some might have hundreds. Though generally it is not seen as desirable to group semantically very different operations under one name - especially given that CLOS provides different types of method combinations and a CLOS generic function might create a more complex interface. Totally agreed here. However, addition, multiplication and so on have a very uniform and well defined set of semantics that apply to many types from all the various representations of real and complex numbers to the many many different types of matrices in Julia's LinearAlgebra library (lots of wrappers for things like Symmetric, or Tridiagonal matrices, lazy matrix factorization objects, adjoint matrices, etc.) That's why there's so many methods on addition and multiplication in julia, and why I found it so surprising that CL doesn't do this on purpose. But I get that scientific computing isn't as big a part of the demographics in the CL community so I guess it makes sense.