5 ms·
> Instead of my_array.length you have length(my_array). In my personal preference the method call is just a nicer way of doing the same thing. Well...they're b
by jhgb 6y ago
> Instead of my_array.length you have length(my_array). In my personal preference the method call is just a nicer way of doing the same thing.
Well...they're both method calls, aren't they? (So they're both the nicer way?)
- leephillips 6y agoThose 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']
- deetsb 6y agoAs 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.
- leephillips 6y agoIt’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.
- leephillips 6y agoHere 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.
- diarrhea 6y agoThe Python FAQ itself adresses this: https://docs.python.org/3/faq/design.html#why-is-join-a-string-method-instead-of-a-list-or-tuple-method 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.
- leephillips 6y agoNot convincing exactly, but I’m glad to know the thinking behind it, thank you. How are you torn?
- deetsb 6y agoThat’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.
- jhgb 6y agoMultiple dispatch is usually class-based as well.
- leephillips 6y agoNot in Julia.
- jhgb 6y agoIt doesn't have named types on which methods get dispatched?
- leephillips 6y agoYes, but those are not classes, in the sense of Python or other OOP language classes.
- jhgb 6y agoNamed 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.
- leephillips 6y agoIn 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-effectiveness-of-the-julia-programming-language/ https://arstechnica.com/science/2020/10/the-unreasonable-eff...
- 6y ago
- nostoc 6y agoThat'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.
- duckerude 6y agoIf 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.
- leephillips 6y agoThe Julia join function works on any iterable whose members are or can be converted into strings.
- adgjlsfhk1 6y agoThat requires multiple dispatch.