5 ms·

>aside from performance magic. It seems so klunky to actually use what's the interface magic in Python? Class inheritance? I suppose you know that multi-dispat

by moelf 4y ago

>aside from performance magic. It seems so klunky to actually use what's the interface magic in Python? Class inheritance? I suppose you know that multi-dispatch is basically strictly more generic than Class-based OOP, so if you want to lock yourself down in Julia and have less composability that's always an option.

bobbylarrybobby 4y ago
Python has pseudo interfaces via the typing module. Julia really has nothing resembling interfaces -- you just have to keep in your head all the methods that are expected to exist for a given type. The closest thing are abstract classes, which are used exclusively for dispatch, but you can only have a single superclass so they don't compose like interfaces do.
- tomkwong 4y ago
  > you just have to keep in your head all the methods that are expected to exist for a given type. Technically, you don't need to keep that in your head :-) The general approach is to define generic functions and also write docs about how to extend those functions to satisfy interface requirements. Perhaps not too surprisingly, many of the Julia community people also want to have some official interface support directly from the language. Before that, several open-source projects were spawned to address that gap e.g. here is a shameless plug about my package: https://github.com/tk3369/BinaryTraits.jl https://github.com/tk3369/BinaryTraits.jl
dragonwriter 4y ago
> what's the interface magic in Python? Class inheritance? Protocols. Though, yes, you can also use class inheritance. > I suppose you know that multi-dispatch is basically strictly more generic than Class-based OOP, Python is flexible enough that multiple dispatch can be done as a library without being a language feature.
- adgjlsfhk1 4y ago
  this last point is misleading enough to be basically false. python has a library to do multiple dispatch, but the hard parts of multiple dispatch isn't the feature, it's making it fast enough to be usable. the python library only works at run time, which means ever function call using it will take at least a few microseconds. this is ok for niche use cases, but it's 1000x too slow for general use. the reason multiple dispatch in Julia is actually powerful is that the compiler can resolve almost all of the dispatches at compile time, so you don't have to pay for them at runtime.
- JustFinishedBSG 4y ago
  > Python is flexible enough that multiple dispatch can be done as a library without being a language feature. So using a library to add multiple dispatch to Python is fair game but using one of the various Traits library in Julia to enforce interfaces isn't ? Why ?
adenozine 4y ago
I don’t need interfaces in Python because I can just write or extend a class. Multiple dispatch is a bad fit for most problems. It’s the hard truth many Julia users won’t swallow because LLVM can give them such good performance with such low programmer effort. I’ve read some Julia source and its an awful experience trying to figure out what method is actually going to get executed because of multiple dispatch. It’s maddening. It’s the direct reason why so many Julia programs are unwieldy, and it leads to poor programming practices. I’ve seen plenty of mathematicians write shitty Python/Octave/R etc, I’m not saying that it can necessarily be prevented. Like I said, I’ve read a lot of shitty mathematician Python, and I can at least build the class hierarchy and transformations in my head and annotate my way to understanding. With Julia, I have to think multiplicatively about every call site because it could get called with a million different methods. It’s so annoying. I don’t think Python will ever be half as fast as the fastest Julia programs, but that’s okay. A hell of a lot more games/products/everything has been shipped with it than ever will be with Julia 1.*
- JustFinishedBSG 4y ago
  > I don’t need interfaces in Python because I can just write or extend a class. Which is strictly less powerful than creating a subtype...
- kwertzzz 4y ago
  > I’ve read some Julia source and its an awful experience trying to figure out what method is actually going to get executed because of multiple dispatch. This is the purpose of the @which macro: julia> @which diag(randn(3,3)) diag(A::AbstractMatrix) in LinearAlgebra at /opt/julia1.7.2/share/julia/stdlib/v1.7/LinearAlgebra/src/dense.jl:249 It gives you filename, line number and function signature.
- sundarurfriend 4y ago
  > I’ve read some Julia source and its an awful experience trying to figure out what method is actually going to get executed because of multiple dispatch. I totally get where you're coming from, as this is how I felt when I started out exploring Julia code. In previous languages, I preferred to use the simple tools I was familiar with (my editor and ack/ag/rg) to explore code, but that workflow was a frustrating no-go in Julia. The usual alternative in those languages was to change my entire coding experience with an IDE, or to accept some (slight) additional complexity with things like ctags. In Julia, neither of those is necessary, as the inbuilt tools like @which, @edit, methods(), and methodswith() do a good job of providing a non-intrusive, simple alternate set of tools. (Shoutout to the InteractiveCodeSearch.jl package too, which provides a nice interactive interface over these that sometimes comes in handy.) Now, generated functions and @eval-ed functions, those are a bane of readability when you're new to the code. Thankfully, those are rare enough and usually in deep enough parts of the code that this does not pose a significant problem. [1] https://github.com/tkf/InteractiveCodeSearch.jl/ https://github.com/tkf/InteractiveCodeSearch.jl/

by moelf 4y ago

bobbylarrybobby 4y ago

Python has pseudo interfaces via the typing module. Julia really has nothing resembling interfaces -- you just have to keep in your head all the methods that are expected to exist for a given type. The closest thing are abstract classes, which are used exclusively for dispatch, but you can only have a single superclass so they don't compose like interfaces do.

tomkwong 4y ago
> you just have to keep in your head all the methods that are expected to exist for a given type. Technically, you don't need to keep that in your head :-) The general approach is to define generic functions and also write docs about how to extend those functions to satisfy interface requirements. Perhaps not too surprisingly, many of the Julia community people also want to have some official interface support directly from the language. Before that, several open-source projects were spawned to address that gap e.g. here is a shameless plug about my package: https://github.com/tk3369/BinaryTraits.jl https://github.com/tk3369/BinaryTraits.jl

dragonwriter 4y ago

> what's the interface magic in Python? Class inheritance? Protocols. Though, yes, you can also use class inheritance. > I suppose you know that multi-dispatch is basically strictly more generic than Class-based OOP, Python is flexible enough that multiple dispatch can be done as a library without being a language feature.

adgjlsfhk1 4y ago
this last point is misleading enough to be basically false. python has a library to do multiple dispatch, but the hard parts of multiple dispatch isn't the feature, it's making it fast enough to be usable. the python library only works at run time, which means ever function call using it will take at least a few microseconds. this is ok for niche use cases, but it's 1000x too slow for general use. the reason multiple dispatch in Julia is actually powerful is that the compiler can resolve almost all of the dispatches at compile time, so you don't have to pay for them at runtime.
JustFinishedBSG 4y ago
> Python is flexible enough that multiple dispatch can be done as a library without being a language feature. So using a library to add multiple dispatch to Python is fair game but using one of the various Traits library in Julia to enforce interfaces isn't ? Why ?

adenozine 4y ago

I don’t need interfaces in Python because I can just write or extend a class. Multiple dispatch is a bad fit for most problems. It’s the hard truth many Julia users won’t swallow because LLVM can give them such good performance with such low programmer effort. I’ve read some Julia source and its an awful experience trying to figure out what method is actually going to get executed because of multiple dispatch. It’s maddening. It’s the direct reason why so many Julia programs are unwieldy, and it leads to poor programming practices. I’ve seen plenty of mathematicians write shitty Python/Octave/R etc, I’m not saying that it can necessarily be prevented. Like I said, I’ve read a lot of shitty mathematician Python, and I can at least build the class hierarchy and transformations in my head and annotate my way to understanding. With Julia, I have to think multiplicatively about every call site because it could get called with a million different methods. It’s so annoying. I don’t think Python will ever be half as fast as the fastest Julia programs, but that’s okay. A hell of a lot more games/products/everything has been shipped with it than ever will be with Julia 1.*

JustFinishedBSG 4y ago
> I don’t need interfaces in Python because I can just write or extend a class. Which is strictly less powerful than creating a subtype...
kwertzzz 4y ago
> I’ve read some Julia source and its an awful experience trying to figure out what method is actually going to get executed because of multiple dispatch. This is the purpose of the @which macro: julia> @which diag(randn(3,3)) diag(A::AbstractMatrix) in LinearAlgebra at /opt/julia1.7.2/share/julia/stdlib/v1.7/LinearAlgebra/src/dense.jl:249 It gives you filename, line number and function signature.
sundarurfriend 4y ago
> I’ve read some Julia source and its an awful experience trying to figure out what method is actually going to get executed because of multiple dispatch. I totally get where you're coming from, as this is how I felt when I started out exploring Julia code. In previous languages, I preferred to use the simple tools I was familiar with (my editor and ack/ag/rg) to explore code, but that workflow was a frustrating no-go in Julia. The usual alternative in those languages was to change my entire coding experience with an IDE, or to accept some (slight) additional complexity with things like ctags. In Julia, neither of those is necessary, as the inbuilt tools like @which, @edit, methods(), and methodswith() do a good job of providing a non-intrusive, simple alternate set of tools. (Shoutout to the InteractiveCodeSearch.jl package too, which provides a nice interactive interface over these that sometimes comes in handy.) Now, generated functions and @eval-ed functions, those are a bane of readability when you're new to the code. Thankfully, those are rare enough and usually in deep enough parts of the code that this does not pose a significant problem. [1] https://github.com/tkf/InteractiveCodeSearch.jl/ https://github.com/tkf/InteractiveCodeSearch.jl/