Depends on what you mean with legibility. For example (and not at all related to x.f(y) vs f(x, y)), if I look at my experience with the Go programming language, once you get used to its imposed One True Way of formatting it really makes reading other people's source code a lot easier. And talking about spending energy on the subject of legibility: setting up my editor to use go-fmt (the autoformatting tool) when building/saving code means I don't have to spend any time thinking about it when writing my own code either; it will automatically get fixed.
It's one of those things the Go developers are very enthusiastic about, and at first you go "really? *That's* a killer feature?" but after using it you do start to miss it in other languages. Speaking of which, is there an autoformatting tool for Julia? That might seem like a tiny thing, but those two things add up. On Wednesday, 8 January 2014 23:58:19 UTC+1, Daniel Carrera wrote: > > I don't know... is legibility a "real" advantage? A lot of the energy > spent in designing languages goes into making them feel natural or > clear in some sense. People have different views on what that means, > and so languages proliferate. Although I do not use OOP, I would not > dis anyone for wanting to write code in the form Subject+Verb+Object. > I think it is legitimate for someone to argue that this feels more > natural. For some kinds of problems I might even agree. > > Cheers, > Daniel. > > > On 8 January 2014 17:19, John Myles White <[email protected]<javascript:>> > wrote: > > 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]<javascript:>> > 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 > >> > > >> > > > > > > -- > When an engineer says that something can't be done, it's a code phrase > that means it's not fun to do. >
