I agree that it’s not a “real” advantage, but, in my experience, the intensity of people’s passion for a feature is often inversely proportional to its computational importance.
The “has a” relation problem is very close to the issue of delegation that’s come a bunch of times before. At some point I think we have to come up with a solution to this problem. — John On Jan 8, 2014, at 8:05 AM, Tobias Knopp <[email protected]> wrote: > Well, I mean some "real" advantages beyond this small syntactical difference. > In C++ there is a lot of mix between class methods and regular functions and > it is good practice to only use class methods if this is really necessary, > i.e. if access to private members is required. > > One issue Julia seem to have is that it is not possible to subclass final > types. This can be solved by turning the "is a" into a "has a" relation but > currently there seem to be no way to carry over all generic methods from the > member to the parent type. > > Am Mittwoch, 8. Januar 2014 16:47:50 UTC+1 schrieb John Myles White: > I think part of the appeal of dot-notation OO is that it reads left-to-right, > which helps to make the code seem to read in the same order as the sequence > of actions taken. > > — John > > On Jan 8, 2014, at 7:45 AM, Tobias Knopp <[email protected]> wrote: > > > Would be interesting to see some use cases where "Java-like" OO better fits > > than Julias OO. In C++ one can use both and usually choses based on whether > > the dispatching can be done at runtime or at compile time (i.e. classes > > with virtual function for runtime decisions and templates for compile time > > decisions). > > There are many situations where I would have liked to use generic > > programming in C++ but it was not possible as the type was only known at > > runtime. In Julia this is no issue which makes it such a joy to use. > > > > > > Am Mittwoch, 8. Januar 2014 14:17:20 UTC+1 schrieb Stefan Karpinski: > > It's a bit hard to say whether Julia is object-oriented or not. I suspect > > that for a lot of people, object-oriented means "do you write `x.f(y)` a > > lot?" By that metric, Julia is not very object oriented. On the other hand, > > everything you can do with single-dispatch o.o. in C++ or Java, you can > > easily simulate with multiple dispatch, but you'll have to get used to > > writing `f(x,y)` instead of `x.f(y)`. If your notion of object-orientation > > has more to do with encapsulation and/or message passing, then we start to > > look pretty non-o.o. again. > > > > > > On Wed, Jan 8, 2014 at 5:25 AM, Matthias BUSSONNIER > > <[email protected]> wrote: > > > > Le 7 janv. 2014 à 21:48, Erik Engheim a écrit : > > > >> Thanks for the nice comments all of you. I guess I have to keep writing > >> more about my Julia experiences after this ;-) > >> > >> On Tuesday, January 7, 2014 9:39:05 PM UTC+1, Ivar Nesje wrote: > >> Great post, it sums up very well the things I think is the strengths of > >> Julia. > >> > >> A few notes: > >> Julia does not look up the method at runtime if the types of the arguments > >> to the function can be deduced from the types of the arguments to the > >> surrounding function (but it behaves that way for the user, unless he > >> redefines the method after the function was compiled #265). > >> > >> > >> That is cool I didn't know that. I assume this can make quite a big > >> difference in performance for tight inner loops. > > > > > > Some misc comment too : > > > > > Julia is not object oriented > > > > Is that True ? From the manual : > > > > > It is multi-paradigm, combining features of imperative, functional, and > > > object-oriented programming. > > > > I consider that Julia can be OO, the code just look different than in other > > languages. > > > > > > Typo ? > > > Polymorphis lets you > > Missing m ? > > > > Liked the blog post too otherwise thanks, I would also have mentioned > > code_lowered, code_llvm and code_typed > > not everyone is fluent assembler and those tool are really useful to, > > especially in metaprogramming. > > > > -- > > M > > >
