Hacker News Reader

Comment by leephillips | Hacker News Reader

Those who are attached to the class-based OOP model used, for example, in Python will find the dot notation more natural. But Julia’s multiple dispatch is a superset of this, and unarguably more powerful and flexible. Python OOP leads to monstrosities like

       >>> ', '.join(['1', '2', '3'])
     '1, 2, 3'

       >>> '1, 2, 3'.split(', ')
     ['1', '2', '3']

View on HN

As I’m clearly missing the bigger picture, what do you find to be super offensive about this?

I read the first as the concat symbol applied to an iterable leads to string concated by the concat symbol.

I read the second as an iterable broken by split symbol leads to an iterable of the chunks.

It’s hard to remember what order to put things in, because the two methods follow opposite conventions. And that’s because this type of OO design has no obvious method of organization.

In the first case, I want to do something to a list: join it into a string. So, clearly, I need a list method? But no, I need to engage in some form of indirection; for some reason, I need to reach for a string method. Even if there is no string that I want to use as a delimiter. In that case, I need to use a string method on an empty string.

OK, I’ll play along. Now I want to take the string and split it into an array. Now that I’ve been educated, I know better than to try the sensible thing. Pre-enlightenment, I would have reached for a method applied to the thing that I wanted to transform. But now I know I should think backwards, and use a method applied to the delimiter. OOPs.

Here it is in Julia:

     julia> join([1 2 3], ", ")
     "1, 2, 3"


     julia> split("1, 2, 3", ", ")
     3-element Vector{SubString{String}}:
      "1"
      "2"
      "3"

Note how they are both functions. The data that they operate on is the first argument, in both cases. The optional second argument is the obvious next most important thing, the delimiter. Other optional arguments come after that. There is nothing to remember, because it makes sense.

The Python FAQ itself adresses this: https://docs.python.org/3/faq/design.html#why-is-join-a-stri...

You'll have to decide if you find that convincing. I understand your point and kind of wish I hadn't read this thread because I'm more torn than before.

Not convincing exactly, but I’m glad to know the thinking behind it, thank you. How are you torn?

That’s fair Lee. I think I’d accidentally stumbled upon the logic for .join acting on the separator rather than the iterable, but I do agree it’s awkward unless you’re trying to figure out why it is (which is poor design), and certainly not how most people think, especially with the inconsistency of split not acting on the separator.

That's not a failure of OOP, but a failure of design.

This could have easily been avoided if `join` would have been a method of the list object, not the string object. But we're stuck with this now.

If join were a method on lists then you wouldn't be able to use it with other iterables. Putting it on str is more useful, if more confusing.

Maybe it would be better as a standalone function. But then you'd either have to import it or it would pollute the global namespace.

Other OOP models offer different solutions.

The Julia join function works on any iterable whose members are or can be converted into strings.

That requires multiple dispatch.

Multiple dispatch is usually class-based as well.

Not in Julia.

It doesn't have named types on which methods get dispatched?

Yes, but those are not classes, in the sense of Python or other OOP language classes.

Named types that can be dispatched on are classes, see CLOS. Hell, even in Python, classes are pretty much the named types that you can dispatch on, although of course, in Python, you generally can't create different kinds of types that can't be dispatched on like types satisfying a predicate - at least to my knowledge you can't, so the difference is somewhat less tangible there.

In Julia they are not classes in the sense that the term is normally used in, for example, Python. Classes bind together data and methods, which is what leads to all the problems. In Julia functions are generic, and specialized to methods acting on arbitrary combinations of types; they are freed from the data.

https://arstechnica.com/science/2020/10/the-unreasonable-eff...

> Classes bind together data and methods

Not in CLOS, from which Julia's mechanisms are derived (which leads to the question why not CLOS but Python of all things should be used as a source of "normal sense" of anything Julia-related). In CLOS, classes bind together data, generic functions name abstract operations, and methods represent specific code that deals with implementing a generic function for a particular combination of type arguments.

> which is what leads to all the problems

I don't think anyone is disputing that here. There's a reason why CLOS didn't do any of that.

> In Julia functions are generic, and specialized to methods acting on arbitrary combinations of types; they are freed from the data.

...yes, just like in CLOS (unsurprisingly, given Julia's heritage), and those types are effectively CLOS classes.

Well, it seems as if we were just at cross purposes due to terminology.

Although multiple dispatch in CL (and Perl) predates Julia, I was not aware that Julia’s design derived from it. Do you have a reference that traces this?

I find it virtually certain that it does derive from it. Considering that one of the authors of Julia wrote Julia's front-end in Lisp (https://github.com/JuliaLang/julia/blob/master/src/julia-par... and some other files in the same directory), it would have been astonishing for CLOS to not have major impact on the design. There's also some relevant statements in a paper on Julia's design (https://dl.acm.org/doi/10.1145/3276490) in the part on multiple dispatch in section 7. Related Work, where CLOS and its "algebraic cousin" Dylan are mentioned. I got the impression that Julia's object system is basically CLOS without quite a few of CLOS' complexities such as inheritance (which in CLOS necessitates some advanced extension facilities to cover some corner cases if method lookup doesn't do what you want it to do if you're attempting a highly complex application model). The nice effect of those feature removals was that in many cases monomorphization of call sites in emitted native code is possible, which is presumably the other reason for those feature removals: suddenly even primitive operations such as +, * etc. can be generics without incurring (most of the time) dispatch cost at runtime. That (primitive operations being generic functions) is not the case in CLOS, although that can also very well be attributed to backwards compatibility efforts in Common Lisp.

Interestingly enough, in Julia's documentation, the section "Noteworthy Differences from other Languages" (https://docs.julialang.org/en/v1/manual/noteworthy-differenc...) compares Julia to only several relevant languages, which are: Matlab, R, Python, C/C++, and...Common Lisp, of all things. I very strongly doubt that this is a coincidence.

Thank you for that interesting reply.

Reply on news.ycombinator.com