Julia needs proper interfaces before I’d write an entire game with it.
I’ve found it strange that so many people prefer it to Python, aside from performance magic. It seems so klunky to actually use.
I’ve found it strange that so many people prefer it to Python, 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.
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:
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.
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 ?
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.*
Which is strictly less powerful than creating a subtype...
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
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.
what is this claim based on? hearsay?
> 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.
how is that difficult? you need to elaborate on that because having to "figure out" means you didn't really use Julia enough
Because python is at least 3 decades old and julia is just a decade old. even python has a "hate" phase before it got widely adopted.
> 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.
whut?? are you saying this just to sound cool? because for me this is hilarious.
Pardon me if I don’t find your input valuable. I’ll check back with you in twenty years to see if you matter. ;)
I’m not sure what you mean by “sound cool” but you have a lot to learn. Julia’s types are not like templates or generics in other languages, they can basically fit into any method-shaped hole. So, at a call site, there’s no way for me to intuitively reason about the data at play, because some_method() can be literally anything. Combine that with a lack of interfaces, and it’s just mangled up code all over the place.
I’ve worked on codebases that stretch longer than my working career, I’ve worked on code where 100+ PhDs had left their mark in gnarly R/Matlab voodoo, I’ve worked on code that transacts hundreds of billions of tax dollars in a year, and much more.
Julia is a specialized tool for HPC, and the illusion that multiple dispatch without interfaces can be used to build reliable, understandable, engineerable systems will die as surely as the sun sets each night.
I’m not sure your background, and maybe HPC is your expertise or whatever. It seems like you need some better coworkers to learn from, or at least more variety in your intellectual diet.
It is, in my view, a fundamentally different programming paradigm that most of us have no previous built-up intuition for (unless perhaps you have spent lot of time with languages like Dylan or perhaps CLOS). But it is something you can learn and develop intuition for like anything else.
For those still learning, I may also mention `@edit`, which will not just show you the method, but take you directly to the source code of the method being called -- which is something that remains quite useful even when your intuition is fully-developed.