On Sunday, July 5, 2015 at 4:24:50 PM UTC-4, Jameson wrote: > > Just to get it out of the way, I'll point out first that since all of the > aforementioned languages are turing-complete, they can all solve all of the > same programming problems. Therefore, there is never a question of whether > one language can be used to emulate the features of another language. > Instead, the question is whether one programming language makes the right > paradigms sufficiently more useful or obvious than another language, for > achieving the objectives of a particular programming problem. > > 1) OO-style dispatch is essentially single-dispatch on the first > (implicit/hidden) argument. Multiple dispatch is a strict superset of that. > So you could provide both, but there's no benefit. It complicates the > user's mental model of the language to provide these as two independent > features, rather than one unified system. > > 2) In C++ and Java, the type signature of the dispatch delegate is fully > resolved at compile time. By contrast, in Julia, the dispatch occurs at > runtime, when the actual type is known. The visitor design is exactly the > sort of anti-pattern that Julia seeks to eliminate by removing the forced > distinction between multiple dispatch functions (interfaces) and methods > associated with types (ref. question #1). > > 3) As noted by the wikipedia article, this is a design problem, not a > language problem. Some languages, like Python and Julia, therefore choose > not to hide anything from the user, but simply provide recommendations > against certain patterns. In Julia, it is generally discouraged to directly > access the fields of an object outside some set of methods that are > understood to be implementing the informal API for that type. Similarly, in > Python, the convention is to prefix private data with `_`, since in general > the dot-oriented access is the approved access API, but the general > principle is the same. >
I agree with your first two points, and find Julia to be much more powerful with multiple dispatch instead of single dispatch, however I think Julian's third point is something that is a problem with Julia (although I believe it could be solved, without too much trouble). If there were a way to have functions and types (or members of types) that are not accesible outside the module they are defined in, then one could define an interface, and not have to worry about code breaking the encapsulation. (For example, I've found hundreds of cases of accesses of .data in strings in the registered packages, as well as others in different modules in Base) Scott On Sun, Jul 5, 2015 at 3:55 PM Julian Manzano <[email protected] > <javascript:>> wrote: > >> Hi All, >> >> I have been using C++ and Python for several years and I am very curious >> about Julia, I've got the REPL working on my workstation and I am really >> impressed so far with what I've seen. >> However there are some design decisions in the language that I fail to >> understand and I would really appreciate if someone could explain the >> rationale: >> >> The main point that I fail to understand is the decision not to allow >> member functions. >> The typical explanation that I find everywhere is that Julia designers >> have chosen all the methods to be external because this is cleaner >> (specially for mathematical methods where there is no clear owner) and >> allows for multiple dispatch. >> This explanation does not convince me for the following reasons: >> >> 1) We can have multiple dispatch a la Julia and still allow types to have >> methods. These two things seeem independent to me. >> 2) Dynamic multiple dispatch can also be done as a byproduct of single >> dispatch using the visitor pattern (C++, Java, etc.), so in that sense, >> multiple dispatch is not a new feature. >> 3) Lack of member functions forces all field to be public and therefore I >> cannot understand how Julia will avoid the object orgy anti-pattern ( >> https://en.wikipedia.org/wiki/Object_orgy) >> >> But hey, Julia still looks great, it is just that I would really like if >> someone could explain away my concerns, most likely I am missing something >> here. >> Thanks! >> Julian >> >
