4 ms·

I personally don't like the fact that you have structs but no classes and no instance methods, but I know this is personal and don't want to start a religious w

by make3 8y ago

I personally don't like the fact that you have structs but no classes and no instance methods, but I know this is personal and don't want to start a religious war this morning

pjmlp 8y ago
Multi-methods are much more powerfull than instance methods, but yeah lets agree to disagree. :)
- veddox 8y ago
  Sorry to continue, but could you elaborate on that? I understand both concepts, but not their relative merits...
  - pjmlp 8y ago
    Instance methods are bound to a specific object definition, thus they can only be applied to instances of that specific object or its descendants. Also in static languages, the set of available instance is closed and extending it requires approaches like extension methods now available in a couple of OOP languages. Whereas multi-methods are dynamically dispatched taking into consideration the whole set of parameters, and can be defined after the fact. Meaning that they aren't necessarily written in the same module that defines the respective data structures, which opens the door to more extensible designs. Taking the Alan Perlis' quote "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." to the next level. Because not only can you define all those functions that operate on one data structure, they actually apply to the tuple made by the dynamic type of all parameters at call site. Naturally it also might make it harder to follow what actually happens with a given method dispatch. This is my insight from having gone through "The Art of the Metaobject Protocol" and dabbling with multi-methods in Clojure, so I might not be 100% correct here.
- yellowapple 8y ago
  I feel like they're a significant departure from the OO concept of sending a message to an object (for example, "Foo ! bar()" in Erlang or "Foo.bar()" in a more typical OO language would be interpreted as "send message bar() to object/actor/whatever Foo"). Julia's approach is more "call this function on this object", which is indeed perfectly useful, but is semantically different.
  - pjmlp 8y ago
    That OO concept is pretty much Simula specific, Lisp languages got influenced by the work done in LOOP and Flavours which lead to the design of CLOS, the origin of multi-methods idea. Building on top of your remark, Julia's approach is more "call the visible implementation of this function that better matches the types of all given parameters". And these are only two possible ways of doing OOP, there are a few other ways of approaching the ideas of writing extensible modular code with polyphormism.
    - yellowapple 8y ago
      That OO concept is also what Alan Kay et. al. were envisioning when they coined the term "object-oriented". It's all about message passing between blackboxed instances with isolated/private states. Multi-methods and such are cool and useful, but they're kinda secondary to that core concept (which Julia doesn't really have, to my knowledge at least). In other words: object orientation != strong typing (even if they do tend to go hand-in-hand).
      - pjmlp 8y ago
        I never said that object orientation == strong typing, rather that Smalltalk/Simula OOP isn't the only way of doing OOP. CLOS, Beta, SELF, Oberon (the first version), Component Pascal all have explored different ways of doing OOP.
SiempreViernes 8y ago
Don't worry, someone started a war over the 1-indexing so you likely won't get enough attention that it counts as a war :)
mac01021 8y ago
You mean you don't like that the methods are declared outside of the struct? Or that you have to say foo(x) instead of x.foo()? The latter makes writing code using autocomplete less doable, but reads more naturally in many cases. I can't think of compelling pragmatic reason to mind the former, but if you have one I'd like to hear it.
- Tarq0n 8y ago
  Pipes are a nice compromise perhaps. x |> foo(). You get the clear left-to-right flow and easy autocomplete.
- Iwan-Zotow 8y ago
  class methods provides namespace and scope
outlace 8y ago
With multiple dispatch, if a library has a function that just works on abstract array types, then you as the user could write your own sub-type of the abstract array and it will still work with the library function.
lewis500 8y ago
I think this mainly makes a difference with regard to reading the code. I'm looking at a struct in someone's code and ask myself "How does this thing get used?" With classes I'll be able to see its methods right away, and if it had inherited then I could see right away which parent to go check. But the problem is not that big. Maybe the methods are right next to the struct, or if I search the codebase for the struct I can find which methods use it. Still, would be cool if Juno had some feature like "show which methods use this."

by make3 8y ago

I personally don't like the fact that you have structs but no classes and no instance methods, but I know this is personal and don't want to start a religious war this morning

pjmlp 8y ago

Multi-methods are much more powerfull than instance methods, but yeah lets agree to disagree. :)

veddox 8y ago
Sorry to continue, but could you elaborate on that? I understand both concepts, but not their relative merits...
- pjmlp 8y ago
  Instance methods are bound to a specific object definition, thus they can only be applied to instances of that specific object or its descendants. Also in static languages, the set of available instance is closed and extending it requires approaches like extension methods now available in a couple of OOP languages. Whereas multi-methods are dynamically dispatched taking into consideration the whole set of parameters, and can be defined after the fact. Meaning that they aren't necessarily written in the same module that defines the respective data structures, which opens the door to more extensible designs. Taking the Alan Perlis' quote "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." to the next level. Because not only can you define all those functions that operate on one data structure, they actually apply to the tuple made by the dynamic type of all parameters at call site. Naturally it also might make it harder to follow what actually happens with a given method dispatch. This is my insight from having gone through "The Art of the Metaobject Protocol" and dabbling with multi-methods in Clojure, so I might not be 100% correct here.
yellowapple 8y ago
I feel like they're a significant departure from the OO concept of sending a message to an object (for example, "Foo ! bar()" in Erlang or "Foo.bar()" in a more typical OO language would be interpreted as "send message bar() to object/actor/whatever Foo"). Julia's approach is more "call this function on this object", which is indeed perfectly useful, but is semantically different.
- pjmlp 8y ago
  That OO concept is pretty much Simula specific, Lisp languages got influenced by the work done in LOOP and Flavours which lead to the design of CLOS, the origin of multi-methods idea. Building on top of your remark, Julia's approach is more "call the visible implementation of this function that better matches the types of all given parameters". And these are only two possible ways of doing OOP, there are a few other ways of approaching the ideas of writing extensible modular code with polyphormism.
  - yellowapple 8y ago
    That OO concept is also what Alan Kay et. al. were envisioning when they coined the term "object-oriented". It's all about message passing between blackboxed instances with isolated/private states. Multi-methods and such are cool and useful, but they're kinda secondary to that core concept (which Julia doesn't really have, to my knowledge at least). In other words: object orientation != strong typing (even if they do tend to go hand-in-hand).
    - pjmlp 8y ago
      I never said that object orientation == strong typing, rather that Smalltalk/Simula OOP isn't the only way of doing OOP. CLOS, Beta, SELF, Oberon (the first version), Component Pascal all have explored different ways of doing OOP.

SiempreViernes 8y ago

Don't worry, someone started a war over the 1-indexing so you likely won't get enough attention that it counts as a war :)

mac01021 8y ago

You mean you don't like that the methods are declared outside of the struct? Or that you have to say foo(x) instead of x.foo()? The latter makes writing code using autocomplete less doable, but reads more naturally in many cases. I can't think of compelling pragmatic reason to mind the former, but if you have one I'd like to hear it.

Tarq0n 8y ago
Pipes are a nice compromise perhaps. x |> foo(). You get the clear left-to-right flow and easy autocomplete.
Iwan-Zotow 8y ago
class methods provides namespace and scope

outlace 8y ago

With multiple dispatch, if a library has a function that just works on abstract array types, then you as the user could write your own sub-type of the abstract array and it will still work with the library function.

lewis500 8y ago

I think this mainly makes a difference with regard to reading the code. I'm looking at a struct in someone's code and ask myself "How does this thing get used?" With classes I'll be able to see its methods right away, and if it had inherited then I could see right away which parent to go check. But the problem is not that big. Maybe the methods are right next to the struct, or if I search the codebase for the struct I can find which methods use it. Still, would be cool if Juno had some feature like "show which methods use this."