There is not yet, because there is still not a consensus on proper style. Hopefully once we have that, it will be easier to make a julia fmt tool.
— John On Jan 8, 2014, at 6:09 PM, 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.
