I am working now in a team of researchers that mainly use Python. How can I explain that I am happy that Julia is not object oriented?
I said that classes are replaced by structs and types. There is a type hierarchy, but no class hierarchy. But how do types and structs relate to each other?
A struct is a kind of type.
This talk by Stefan might give you some insight. It doesn’t attempt to answer exactly the question you ask, but might nevertheless be useful to you
I am not sure, if that is something which is explainable.
For me it’s even not true. I am not saying that I want OO in Julia, but I would never, e.g. say, I wish Java wouldn’t be OO, or similar. I think, this statement doesn’t make too much sense.
I like Julia as it is, and I like it more than Java, but not because of some OO paradigm. E.g. .NET C# I like too, it is OO, and I don’t know which I like more, C# or Julia. I guess it depends on the problem.
In Julia, the types can be abstract, primitives, structs (composite), and functions.
Thereis a good pretty good discussion of this and object oriented programming in the manual.
https://docs.julialang.org/en/v1/manual/types/
The main difference from object oriented languages is that functions themselves are types and do not belong to objects or structs. Rather functions have methods with different argument type signatures. Functions are first class citizens in Julia.
Python is a weird point of comparison since it is multi-paradigm. It is both procedural and object oriented.
In Python, functions are just singleton procedures.
In Julia, functions can be overloaded with both abstract and concrete types and accessed via multiple dispatch via late binding.
I know this isn’t quite what you asked, but here is a story that captures for me the problem in OO that multiple dispatch resolves.
Pandas as a number of df.to_<file format>(path) methods. If you pass a string, it treats it like a path and tries to write to it. If you have an s3 package loaded, you can pass it a string URI to a s3 bucket, and it will write to the bucket with no other configuration. Very cool.
There is a package called S3Path which aims to extend the pathlib API to URIs. But you can’t pass an S3Path object to a df.to_<file format>(path) method because Pandas doesn’t call the correct open method on the file object. There is an open issue in the S3Path github page where they lament Pandas’ poor choice.
But of course, if this were Julia, they would just define write(::S3Path, ::DataFrame) and be done with it because you can dispatch a new method on … multiple arguments.
This kind of thing happens all the time. The nature of an interaction between two or more things is contigent upon the nature of all of the objects, not just the first.
I would emphasize multiple dispatch, rather than tackle the OO question directly.
Julia doesn’t need object orientation, because (among other things) object orientation is a way to get single dispatch. You can def operation on a bunch of classes, they can inherit it, and then you have foo.operation(...), bar.operation(...) and so on.
In Julia one can write operation(a::Foo,...), operation(a::Bar, ...), and so on. We get genericity from the type hierarchy, and crucially, we have multiple dispatch across any arguments to a function.
So data types and methods which work with them are fully orthogonal. This is much more powerful than single-dispatch and inheritance, although it can be harder to work with (method ambiguities, you have to make sure that concrete subtypes interoperate manually).
Just work with them until it snaps into focus that instead of internal trees of if statements, they can write methods which dispatch on all of the types which a function might take. That’s the lightbulb moment.
Then for a bonus you can explain how this allows Julia to natively compile to machine code which can be as efficient as C or Fortran. 