When you think in types rather then objects it makes more sense. Or at least I think `+(u, v)` or `u + v`, is more natural then `u.plus(v)` or `u.+(v)`
I the former case u and v are of numeric types that fulfil some numeric properties, so no interfaces are necessary, they are implied.
> Or at least I think `+(u, v)` or `u + v`, is more natural then `u.plus(v)` or `u.+(v)`
I definitely agree with that, I said that object.method() style is often more natural. Typically when you have an object with some internal state and you want to send a message to it that will change its state. For example: threadPool.run(command) feels more natural than run(thread_pool, command).
People discuss certain styles as being more natural, but in nearly every case (including this syntactical debate) I assert that it is solely due to what the most mainstream languages do and thus what people are more used to seeing.
If a language makes the dot and the method invocation brackets optional, then `u + v` and `u.+(v)` would be semantically identical. The former would just syntax sugar for the latter.
It is only more natural for functions that take a single argument, which depending on your point of view and type system is of course all of them.
From a mathematical standpoint what you are doing is to consider instead of objects X themselves, arrows from some fixed object I, x : I -> X (roughly speaking the "I points of X", in the category set I could for example be the one element set), then given another arrow f : X -> Y, the composition I -> X -> Y, would be denoted x . f, and you would actually find that in familiar cases this is precisely f(x).
However for this to actually be natural, ideally you wouldn't write x . add(y), but (x,y).add and if you follow that line of thought you would probably understand why stack based languages enjoy some popularity (the stack models the cartesian product).
Object oriented languages instead have for every I point x of X, a bifunctor hom_x(,), where hom_x(Y,Z) denotes all arrows from Y to Z, that "use" the point x (usually denoted by self or this). At least in mathematics, such an arrow can sometimes be extended to an arrow in Hom_X(Y,Z). In the case of addition above, you start off with + : (X , X ) -> X and use currying to get
add : X -> hom(X,X) and pullback along x, to get $x^{\ast}add = add_x \in hom_x(X,X)$, which you then denote by x.add.
So you are right, the object method syntax is more natural and there even was a brief period in the 60s-70s when some mathematicians argued that it should be taught.
I think the point is that it special-cases the first object, at least in the syntax. You _could_ write it that way, but since the method is chosen based on all the object types, it doesn't make much sense to do so.
One could have a language where object.method(args) does single dispatch on "defined in a class" methods while method(object, object,...) does multiple dispatch on generic methods.
That could get really confusing for the language's users, though, if there were name clashes between the two, and they would be there in any reasonably large program.
And of course, argument order already gives the first and last arguments special attention.
Another way to diminish that special-casing is going to the extreme other end: object.object.object.method(). Remove the now superfluous parentheses and replace the periods by spaces and you end up with Forth.
The point was that object.method() is sometimes more readable. For example I find web_socket_manager.reconnect_if_needed() more readable than reconnect_if_needed(web_socket_manager).
That's because you are used to thinking in terms of objects, whereas in Julia the focus is on data and operations on data (the two are often conflated but they aren't the same).
Julia is really more a functional language than an object oriented one. Not saying that's not a valid point (at least to the extent that favourite paradigm is subjective) but just to point out that it's about more than just syntax.
It wouldn't really make sense for Julia to support object.method() any more than it would for Haskell to, superficial as it may seem.
I've seen julia described as "functional" a lot, but is that accurate? There are first-class functions for sure, but the "idiomatic julia" approach to a lot of problems is to allocate a large block of memory, pass around a reference to it and mutate it in place. i.e. all side effects. My terminology might be off, but that's not usually what I think of when I think of functional programming.
I think there's a distinction between idiomatic code and code written for performance. Performance-conscious code looks a lot like C in most languages, not just Julia. Julia just happens to have a lot of that kind of code because it makes it easy to write.
But look at the high-level, user APIs and you tend to see the more functional side – `fft(x)`, `plot(y)` etc., all pure functions which return expressions. Mutation is possible but discouraged via the `!` modifier.
Functions are the primary unit of abstraction – larger programs tend to be designed as collections of functions as opposed to object hierarchies. Higher-order functions like map and filter (aka "functionals") are encouraged.
So I tend to view Julia as a nice functional language which lets me drop down easily when I need to.
I recently started a project in Julia and, excited by the prospect of a smart JIT compiler, wrote everything in a declarative function style with maps, reduces, and filters. The result was slower than than equivalent Python code. I swallowed my aesthetic sense and rewrote every function imperatively, with for loops updating some mutable array, and now it is quite fast. But I am no longer enjoying coding as much. I switched to Julia for speed, but that speed seems to come at the cost of having to write very imperative code.
In terms of day-to-day programming, I'm not sure what makes Julia a better functional language than Python or Ruby. From my limited experience, it isn't speed.
I understand that work is under way to speed up anonymous function calls and to improve type inference on arrays resulting from `map`, etc. Once that is done then I will consider Julia a nice functional language.
"Idiomatic" might have been the wrong way for me to put it, but it seems like one of the biggest advantages and fundamental design decisions of Julia is that it makes numerical computing through side effects _very easy_. Most performance-conscious code doesn't just look like C in other languages, it is C! So I see your point, but I still wish there were a better way to convey exactly the mix of high and low level code that Julia's aiming for.
I wish there was a language like Julia but with a first-class OOP support. Sometimes the OOP approach is more readable and easier to reason about than functional approach.
Believe it or not it's actually perfectly feasible to implement first-class objects and inheritance on top of Julia. You can even integrate it with multiple dispatch (via some metaprogramming and manipulation of the type system) and get object~method(x,y) syntax.
I didn't want it enough to flesh out the prototype (and would argue that Julia's native approach is better anyway) but it's inevitable that someone will do this eventually.
In particular I'm thinking of things like Dylan or CLOS. When people from the more typical OOP backgrounds see stuff like that often their heads explode.
I recently got into an argument with some coworkers over type classes. My argument was that it all made sense when viewed from the Dylan/CLOS/S4/etc lens, and that this was very much OOP, just not what they were used to. Many of them weren't buying what I was selling, but IMO they were using too strict a definition of OOP.
I tried CLOS, not a fan to be honest. OOP (or functional) isn't a very well-defined concept... I like what languages such as Ceylon, C# or Julia (to an extent) are doing - solid support for both OOP and functional styles. Because you typically need both, some problems are more readable and natural in OOP, others in FP.
On that I fully agree. And going back to your statement that it isn't a very well-defined concept, I think that the two concepts aren't nearly as orthogonal as many would have you believe, it's just that the ways that the two communities have solved similar problems over the years appear to be alien to each other.
Julia supports multiple dispatch OO, which is more powerful than what you get from traditional OO languages. Or do you purely mean the x.foo(y) syntax rather than foo(x,y)?
Check out the PyCall[1] and PyPlot[2] packages, then. Julia has pretty good integration with python. I've been pretty happy calling matplotlib from julia. (You probably already know about these packages, but just in case you didn't...)
- It doesn't use the object.method() syntax, which is often more natural and readable than method(object).
- Support for interfaces but I'm not 100% sure about that.