That's an interesting example. I don't know Go, I've only watched a couple of videos about it.
Cheers, Daniel. On 9 January 2014 03:09, Job van der Zwan <[email protected]> wrote: > 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]> 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]> >> > 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. -- When an engineer says that something can't be done, it's a code phrase that means it's not fun to do.
