Groups   101 of 99+      julia-users › Julia and Object-Oriented Programming 48 posts by 15 authors      Sisyphuss    10 18 15   When I'm learning Julia, I am always thinking what is the correct way to do OOP in this language. It seems to me that what I learned in Cpp does not apply in Julia.  It took me long to realize that the equivalent of Class of Cpp in Julia is not Type, but Module. Module is the basic function unit in Julia.  Thus, a Class in Julia is like module ClassName           class Name   using                          include              should be outside import                         include   export  function               public  function; var   1                        private static var; end                          This provides the same structure as Cpp.  However, this design has two issues: 1  The visit control is not as fine-grained as in Cpp, the encapsulation is not strict; 2  Variables at the top level of a module are global variables.  These two points are closely correlated. If we let module have private variables, then they are not too different from local variables, ans thus can be type inferred. I think this is a natural way to do OOP with Julia.        Abe Schneider    10 18 15   I would say that the module is closest to a c++ namespace, which itself can be thought of as a static class. Note, however, that in both cases you can't really have separate instances.  Because of the desire to separate dispatch from type information, Julia doesn't really follow the OOP paradigm. You can have a hierarchy of abstract types, but abstract types contain no information besides their name and place in the hierarchy. Because of multi-dispatch, functions live outside of types  i.e., because you can dispatch on all parameters, usually no one type owns that function . Finally, you can build an interface to mimic an OOP design, but each concrete type still has to re-define the variables  which, is one of the biggest advantages of an OOP design .   One of the really nice things about Julia is that you could in theory create a macro to simulate OOP in Julia:   class foo  : a, b, c   ... end  where ` class` creates a new type `foo`, which pulls in the member variables of `a`, `b`, and `c` to simulate a mix-in design.   1  0    Simon Danisch    10 18 15   This design has at least 3 issues, since you can't have instances of a module. In general: I personally would value the discussion of why Julia needs more OOP constructs much more, If one can show that there are terrible flaws in Julia's model which are swiftly solvable with OOP. My guess is, that the argument  I learned X and can't transfer it to Julia, so Julia needs to change , can't really convince anyone to start implementing something rather involved.  There are a lot of comments on people trying to bring OOP to Julia, which are best summarized by: give Julia's model a chance and don't stick to OOP - it will pay off. And this kind of comment is pretty understandable in my opinion, since Julia is quite a sophistaced language with plenty of constructs to avoid OOP. I don't see much value in OOP and Julia's multiple dispatch is actually one of the things that brought me here   I exclusively worked with OOP languages before . Besides the current flaws, I think it's a better model for numerical computing, it yields concise code, easier maintenance and it's easier to add feature to an existing code base than it is in OOP.  I think Julia should move forward by not mimicking OOP further, but instead improve the current model - there's lots to do already. Wasting time by chasing after features from other languages will make it much harder to turn Julia into a well rounded, sound language.  this only applies to feature that get chased without a concrete problem   Best, Simon   2  0    Tobias Knopp    10 18 15   Julia is fully object oriented. The core of OO is not to write a dot between an object and an associated function but that one has virtual functions. Multiple dispatch provides just that.  Cheers  Tobi   4  0    Tomas Lycken    10 18 15   I’ve never seen a problem that foo.bar x,y  can solve, but bar foo, x, y  can’t.  There are things, however, that are pretty easy to do in OO languages that can’t be done in Julia; one such thing is adding changing behavior through inheritance. That’s pretty easy to work around, though - instead of the following  which won’t work in Julia, but using Julia syntax to make comparison easier   immutable Foo     x end  foo f::Foo    f.x  bar f::Foo    2   f.x  immutable Bar  : Foo     y end  bar b::Bar    b.y   b.x where Bar has an x field inherited from Foo, and overrides behavior for the bar function, you can easily do this:  abstract AbstractFoo immutable Foo     x end  foo f::Foo    f.x bar f::Foo    2   f.x  immutable Bar     y     f::Foo end  foo b::Bar    foo b.f  bar b::Bar    b.y   b.f.x In other words, by using composition instead of inheritance, you can extend and amend the behavior of any object with all the power you have in inheritance.  You could also create an abstract type that both Foo and Bar inherits, to make them part of the same type tree and make dispatch a little simpler.  This is heavily relied on in a couple of recent additions to Interpolations-jl, that provide axis scaling and extrapolation through composition - had I written that code in Java or Clanguage   or Cpp , I probably would have used inheritance instead.  But I agree with Tobias and Simon - there is very little reason to try to make Julia more object-oriented. All the power you get from OO is still there, but you might need to think a little differently to harness it. If you have a concrete problem, along the lines of “this is how I’d do it in OO, but I don’t know how to do it in Julia”, the community is usually pretty good att figuring something out. A recent example was that someone wanted man.eat food  rather than eat man, food . A little thinking outside the box turned out the IMO superior solution - instead of changing the language to make it read better, just change the verb: feed man, food .  Julia isn’t object-oriented, and will probably never be. But that doesn’t make it less powerful :      T    1  0    Páll Haraldsson    10 18 15   On Sunday, October 18, 2015 at 1:15:50 PM UTC, Simon Danisch wrote: Besides the current flaws,  As already argued   fully OOP , just not in the traditional way syntax , not a flaw, just different   composition-over-inheritance  . Don't you agree with  no flaw ? You seem, by what you continued with..:  I think it's a better model for numerical computing,  I can also see that, from the typical example. I'm however having a hard time of thinking up an example where multiple dispatch helps otherwise.. but at least it seems it should never be worse.. Anyone have a good example, even for a business class application..?   it yields concise code, easier maintenance  Yes, that is just a feeling I also have,  more concise   compared to single-dispatch, without considering other stuff that helps , that automatically implies easier maintenance. Probably better  separations of concerns . I would like to see  design by contract , should be possible with a macro, anyone already done stuff like that?  I never looked too closely at aspect-oriented-programming  or even subject-oriented  and AspectJ  for Java , but seems like something like that would also be a candidate for a macro.  and it's easier to add feature to an existing code base than it is in OOP.  I would think..   I think Julia should move forward by not mimicking OOP further, but instead improve the current model - there's lots to do already.  Do not know what you mean by  lots  left. There seem to be macro solutions already available to even more general things than multiple-dispatch   predicate dispatch  . Do you want some things already implemented with a macro included in Julia's syntax without a macro needed?  Wasting time by chasing after features from other languages will make it much harder to turn Julia into a well rounded, sound language.  this only applies to feature that get chased without a concrete problem   For me, I'm not sure adding much more syntax is needed, maybe just add some macros already implemented into Base? If not there, or people not aware of, then Julia might seem less powerful.  --  Palli.   0  0    vav... uwaterloo.ca    10 18 15   Going a bit on a tangent, I claim that object-oriented programming, at least as embodied in Cpp, is not really suitable for scientific computing and in fact has led certain codes to go astray.  To give a simple example, suppose you are told to write a 'matrix' class in Cpp that contains all the usual operations.  You finish writing your class, and a week later, you are told to derive 'symmetric matrices' as a subclass of 'matrices'.  This is trouble!  Unless you wrote your original matrix class in a very particular way, you will have a hard time writing a symmetric matrix class that inherits from a matrix base class.  This is not just a theoretical example; I saw someone try to do this  unsuccessfully  in a code he had written.  The problem with object-oriented programming is that you have make design decisions when you write the base classes that lock you into a certain path.  This path may not be compatible with the flexibility needed for scientific software projects.  I for one am glad that the designers of Julia decided not to make Julia an object-oriented language, at least not in the Cpp sense of the term.  -- Steve Vavasis     On Sunday, October 18, 2015 at 8:41:58 AM UTC-4, Sisyphuss wrote:   1  0    Abe Schneider    10 18 15   I'm not sure everyone would agree that Julia is  fully  object oriented. Usually definitions of OOP include management of the data and not just the interface. Specifically, there is no way to  currently  describe an inheritance of variables.  While I personally would like Julia to have that feature, I don't think it's necessary for languages to be fully OOP either. A lot of what's good in Cpp is functional.   0  0    Abe Schneider    10 18 15    But I agree with Tobias and Simon - there is very little reason to try to make Julia more object-oriented. All the power you get from OO is still there, but you might need to think a little differently to harness it. If you have a concrete problem, along the lines of “this is how I’d do it in OO, but I don’t know how to do it in Julia”, the community is usually pretty good att figuring something out. A recent example was that someone wanted man.eat food  rather than eat man, food . A little thinking outside the box turned out the IMO superior solution - instead of changing the language to make it read better, just change the verb: feed man, food .  Julia isn’t object-oriented, and will probably never be. But that doesn’t make it less powerful :    Of course it doesn't make it less powerful, but it also doesn't alway lead to nice code. The point of OOP isn't that it gets you more power, but it gives you more maintainable code.   0  0    Abe Schneider    10 18 15     On Sunday, October 18, 2015 at 9:44:21 PM UTC-4, vav... uwaterloo.ca wrote: Going a bit on a tangent, I claim that object-oriented programming, at least as embodied in Cpp, is not really suitable for scientific computing and in fact has led certain codes to go astray.  Cpp is purposefully a multi-paradigm language for this reason. Cpp11 added a lot of features specifically for functional aspects of the language.    To give a simple example, suppose you are told to write a 'matrix' class in Cpp that contains all the usual operations.  You finish writing your class, and a week later, you are told to derive 'symmetric matrices' as a subclass of 'matrices'.  This is trouble!  Unless you wrote your original matrix class in a very particular way, you will have a hard time writing a symmetric matrix class that inherits from a matrix base class.  This is not just a theoretical example; I saw someone try to do this  unsuccessfully  in a code he had written.   Sure, you always have the option to write bad code, but that doesn't make a particular paradigm good or bad. I think Torch7 has a good example of using object oriented programming for scientific programming.    The problem with object-oriented programming is that you have make design decisions when you write the base classes that lock you into a certain path.  This path may not be compatible with the flexibility needed for scientific software projects.  I think that's true with any language. In Julia you still have to define an interface to access the variables. Yes, there are fewer mechanisms in place that restrict access, but that isn't always a good thing. You end up trading compile-time errors for run-time errors. I much rather deal with compiler-time errors.    I for one am glad that the designers of Julia decided not to make Julia an object-oriented language, at least not in the Cpp sense of the term.   I think there is a lot to be gained from a multi-paradigm approach. Having a language that is scientific-code friendly is important, but so is integrating it into larger systems.      On Sunday, October 18, 2015 at 8:41:58 AM UTC-4, Sisyphuss wrote: When I'm learning Julia, I am always thinking what is the correct way to do OOP in this language. It seems to me that what I learned in Cpp does not apply in Julia.  It took me long to realize that the equivalent of Class of Cpp in Julia is not Type, but Module. Module is the basic function unit in Julia.  Thus, a Class in Julia is like module ClassName           class Name   using                          include              should be outside import                         include   export  function               public  function; var   1                        private static var; end                          This provides the same structure as Cpp.  However, this design has two issues: 1  The visit control is not as fine-grained as in Cpp, the encapsulation is not strict; 2  Variables at the top level of a module are global variables.  These two points are closely correlated. If we let module have private variables, then they are not too different from local variables, ans thus can be type inferred. I think this is a natural way to do OOP with Julia.     0  0    Stefan Karpinski    10 18 15  Re:  julia-users  Re: Julia and Object-Oriented Programming  It's a highly debatable claim that single dispatch class-based OO leads to better or more maintainable software designs. I grew up on these kinds of languages – Object Pascal, Cpp, Ruby, Java. Despite the ongoing rhetoric that this paradigm solves all sorts of program design problems, that's just not what I've seen. I think this style of programming has failed to be the panacea that it was promised to be. If it was really such a success, then we wouldn't be seeing a fresh crop of promising new programming languages – Julia, Rust, Go, Clojure, Scala, Elixir, Elm, Swift, etc. – not a single one of which is a traditional class-based OO language. The message is clear: we need more effective solutions. So far, Julia's multiple dispatch approach seems to me far better at addressing program maintainability and extensibility than classes ever were. Julia does still need a way of talking about interfaces and protocols in the language itself, but that's ongoing design problem, not a fundamental issue.   3  0    Sisyphuss    10 19 15   I think I am not talking about the same thing with you guys. In my definition, the difference of single multiple dispatch has nothing to do with what I am talking. What I talked about is just a suitable way for encapsulation. For example, the example code can include a type and multiple dispatch function in the module module ClassName                    class Name     using                                 include              should be outside   import                                include      type    TypeName   export  TypeName, fun                 public  fun;    var   1                               private static var;    function fun obj::TypeName, arg  end                                    In single dispatch, a class defines an object and its properties and behaviors. In multi dispatch,  a module defines a type and the functions which recognize it.   0  0    Tim Holy    10 19 15  Re:  julia-users  Re: Julia and Object-Oriented Programming  On Sunday, October 18, 2015 07:38:24 PM Abe Schneider wrote:      Julia isn’t object-oriented, and will probably never be. But that doesn’t      make it less powerful :        Of course it doesn't make it less powerful, but it also doesn't alway lead    to nice code. The point of OOP isn't that it gets you more power, but it    gives you more maintainable code.   From my personal experience, I'd say it's abundantly clear that  true OO    whatever that really means  is not more maintainable than julia's type system  + multiple dispatch. OO is great, and something you study in school because  it's been around a long time, but that doesn't mean that in 2015 it's still  the best organizing principle for code.   --Tim    1  0    Abe Schneider    10 19 15  Re:  julia-users  Re: Julia and Object-Oriented Programming  I think I agree with 90  of what you wrote. I also don't know if anyone is arguing about single or multiple dispatch. Also, while Java and Borland's Object Pascal claimed a strong OO paradigm, Cpp does does not  if you read Bjarne's design guide, he felt strongly that both OOP and functional were important . I'll note too, Java has slowly been moving towards a multi-paradigm approach by including Lambdas in the latest version.  Two of the languages you list below, Swift and Scala, also mix OO and functional programming. While Scala has a huge push for functional programming, it also provides the necessary constructs to talk about inheritance of data  while it doesn't provide multi-inheritance, it does have mix-ins .  I really like Julia's multi-dispatch approach, and have made great use of it in my own libraries. I don't think there should be any reason that classes should have to  own  the methods. However, what it currently doesn't do, is provide a method to specify the relationship of data within types between each other. You stated in the past this is because you want to keep dispatch-type separate from representation type. However, I think that's actually one of the most important aspects of OOP. Yes, you can always write an interface that assumes that each type has variable X, but I would claim ultimately that creates less maintainable code  partially because of DRY and partially because it turns what should be a compile-time error into a run-time error .   0  0    Abe Schneider    10 19 15  Re:  julia-users  Re: Julia and Object-Oriented Programming  My main argument in this thread is that I wouldn't consider Julia  true OO  in the terms many other languages would define it, but trying not to pass any real judgement of whether that is a good thing or not  I agree with Stefan that it's an interesting experiment, and the language is still a work in progress .  Julia supports the OO concept in hierarchy in dispatch-type, but not in data-type. Clearly there is benefit to providing some type of organizational framework, and a hierarchical has helped on the dispatch-front. I've heard two arguments on data-type hierarchy:  1  It's not needed, and doesn't help in any way, and  2  it's not clear how to implement it, so it hasn't been attempted yet.  I disagree with  1 . and am strongly empathetic to  2 .  I don't think that hierarchy is the only way to organize code, but that it is a good way to organize some of the code some of the time. You will find other cases where functional or aspect programming is a better fit. Thus, I think instead of prescribing the best methodology for developers, it's better to provide the tools that they can employ however they see fit.   0  0    Tom Breloff    10 19 15  Re:  julia-users  Re: Julia and Object-Oriented Programming  Here's an example where there would normally be a strict hierarchy in classic OOP:  Square  : Rectangle  : Shape   But it actually makes much more sense in Julia  why have 2 fields for Square?? :   abstract Shape type Rectangle     width::Int     height::Int end type Square     width::Int end Base.size r::Rectangle     r.width, r.height  Base.size s::Square     s.width, s.width    Now I completely agree that ensuring a compile-time agreement of interface is a valuable part of the language  but should ideally be optional .  People do see value in this, and it's an active design discussion.   search for  traits    For composition vs inheritance, I completely agree that sometimes it's nice to save code typing when you have structures with a bunch of fields that are mostly the same.  I'd argue you don't actually care about inheritance, you just want composition but without the extra layer of structure.  This might be best implemented with a macro:  type Wheel   radius::Int end type Frame   length::Int end type Seat   cushiness::Int end  compose Unicycle   Wheel...   Frame...   Seat... end  Above, a relatively simple macro can replace all the  Type...  with the fields of the composed types, applying multiple inheritance of the structures without the baggage required in classic OOP.  Then you can compose your type from other types, but without having to write  unicycle.wheel.radius ... you can just write  unicycle.radius .   also, I'm sure this sort of macro exists somewhere...        0  0    ssarkaray... gmail.com    10 19 15   I am confident that a new OOP language ScalaJulia is possible integrating syntax of both functional languages Scala and Julia. Thanks, SS   1  0    Christof Stocker    10 19 15  Re:  julia-users  Re: Julia and Object-Oriented Programming  My two favorite languages combined! Then again, I wouldn't want ice cream on my steak :-    On 2015-10-19 19:39, ssarkaray... gmail.com wrote: I am confident that a new OOP language ScalaJulia is possible integrating syntax of both functional languages Scala and Julia. Thanks, SS    0  0    Stefan Karpinski    10 19 15  Re:  julia-users  Re: Julia and Object-Oriented Programming  On Mon, Oct 19, 2015 at 11:09 PM,  ssarkaray... gmail.com  wrote: I am confident that a new OOP language ScalaJulia is possible integrating syntax of both functional languages Scala and Julia. Thanks, SS  This post wins the thread.   1  0    Abe Schneider    10 19 15  Re:  julia-users  Re: Julia and Object-Oriented Programming    On Monday, October 19, 2015 at 12:17:16 PM UTC-4, Tom Breloff wrote: Here's an example where there would normally be a strict hierarchy in classic OOP:  Square  : Rectangle  : Shape   But it actually makes much more sense in Julia  why have 2 fields for Square?? :  Unfortunately most of the classic examples are simplified to the point of not being informative. A previous example I gave was the NN design of Torch7, where each module has an `output` and a `grad_input` parameter. The forward backward ops of each module is different, but it's important to have those common variables.    Now I completely agree that ensuring a compile-time agreement of interface is a valuable part of the language  but should ideally be optional .  People do see value in this, and it's an active design discussion.   search for  traits    I did take a look at what the Traits people were doing. Unfortunately, at least last time I looked at it, it still seemed to require a lot of code copying.    For composition vs inheritance, I completely agree that sometimes it's nice to save code typing when you have structures with a bunch of fields that are mostly the same.  I'd argue you don't actually care about inheritance, you just want composition but without the extra layer of structure.   I strongly agree with this. If you hide all direct access to variables and only allow access via an interface, you can define a type as  a composition of other types and a list of supported interfaces:   compose Clanguage protocol1, protocol2   |  A, B    other::AbstractString end   Above, a relatively simple macro can replace all the  Type...  with the fields of the composed types, applying multiple inheritance of the structures without the baggage required in classic OOP.  Then you can compose your type from other types, but without having to write  unicycle.wheel.radius ... you can just write  unicycle.radius .  I suggested such a macro awhile ago  maybe a year? , and it was met with disapproval. Not that that should stop anyone from writing it, but it was deemed un-Julian  at least my take on people's responses . I think this can be seen as a type of mix-in similar to what Ruby and Scala do.   0  0    Sisyphuss    10 20 15   I'm sorry, but I didn't find the ScalaJulia project as you mentioned.   0  0    ssarkaray... gmail.com    10 20 15   It is a suggestion.  There is no project.  If some of the experts agree on such a combined language in this group, a combined grammar can be created and ScalaJulia functional language can be implemented through a project.  We need some exchange of ideas. Such a combined language has implication for Spark, Hadoop, Mlib and many other things to be integrated faster with Julia.  SS   0  0    ssarkaray... gmail.com    10 20 15  Re:  julia-users  Re: Julia and Object-Oriented Programming  Is it ice cream on steak or a new steak sauce added to streak ?   0  0    Abe Schneider    10 20 15   As for class composition, this is how Scala does it:  http:  www.scala-lang.org old node 117  I've previously suggested introducing a `trait` label as to keep type and dispatch information separate. Thus you could do:  trait A   x::Int64   y::Int64 end  trait B   z::Int64 end  type foo A, B   : bar   ... end   It would then be natural to hang interfaces on traits  thus, instead of assuming a variable exists, you could specify an interface applies to a trait     only classes that mix-in trait B can call this function get_x Clanguage  : B  b::C    b.x get_y Clanguage  : B  b::C    b.y   That's my $0.02.    0  0    Stefan Karpinski    10 20 15   ScalaJulia is a skunkworks project Martin and I have been working on for a while now. The hardest part so far has been deciding between whether to call it ScalaJulia or JuliaScala. Other names we considered: Julala, Scalia.   3  0    Brendan Tracey    10 20 15     On Tuesday, October 20, 2015 at 3:39:00 PM UTC-6, Stefan Karpinski wrote: ScalaJulia is a skunkworks project Martin and I have been working on for a while now. The hardest part so far has been deciding between whether to call it ScalaJulia or JuliaScala. Other names we considered: Julala, Scalia.   The US Supreme Court may get involved if you call it Scalia. Hard to know in which direction.    Above, a relatively simple macro can replace all the  Type...  with the fields of the composed types, applying multiple inheritance of the structures without the baggage required in classic OOP.  Then you can compose your type from other types, but without having to write  unicycle.wheel.radius ... you can just write  unicycle.radius .  As Stefan mentioned, Golang is not traditional OO. This  composition-based  approach is part of Go's OO approach. In go, a type can have named fields of different types  like most OO languages , but also has  embedding . For example, if one declared  type Unicycle struct       Wheel     Frame     Seat    then you could access the individual fields directly. So, if  u' is of type Unicycle, then you could access set u.Cushiness directly. Similarly, if the embedded types had methods, i.e. frame.Color  , they can be called directly through unicycle, u.Color  . This is similar to, but distinct from, inheritance  the difference is that the Unicycle type doesn't actually have these fields, just the ability to call them easily, which is significant because of interfaces . In the case of clashes, the program must specify which is meant, so if both Seat and Frame had a Color   method, the user would have to specify u.Frame.Color vs. u.Seat.Color. In Go, this is handled by the compiler, and would need to be handled somewhere in the Julia runtime REPL. It's a very nice paradigm, but would have to be made to fit within the broader Julia context.     0  0    Stefan Karpinski    10 21 15   On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey  tracey.... gmail.com  wrote: The US Supreme Court may get involved if you call it Scalia. Hard to know in which direction.  The watershed Scalia vs. Scalia case of 2016.  0  0    Stefan Karpinski    10 21 15   On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey  tracey.... gmail.com  wrote:    Above, a relatively simple macro can replace all the  Type...  with the fields of the composed types, applying multiple inheritance of the structures without the baggage required in classic OOP.  Then you can compose your type from other types, but without having to write  unicycle.wheel.radius ... you can just write  unicycle.radius .  As Stefan mentioned, Golang is not traditional OO. This  composition-based  approach is part of Go's OO approach. In go, a type can have named fields of different types  like most OO languages , but also has  embedding . For example, if one declared  type Unicycle struct       Wheel     Frame     Seat    then you could access the individual fields directly. So, if  u' is of type Unicycle, then you could access set u.Cushiness directly. Similarly, if the embedded types had methods, i.e. frame.Color  , they can be called directly through unicycle, u.Color  . This is similar to, but distinct from, inheritance  the difference is that the Unicycle type doesn't actually have these fields, just the ability to call them easily, which is significant because of interfaces . In the case of clashes, the program must specify which is meant, so if both Seat and Frame had a Color   method, the user would have to specify u.Frame.Color vs. u.Seat.Color. In Go, this is handled by the compiler, and would need to be handled somewhere in the Julia runtime REPL. It's a very nice paradigm, but would have to be made to fit within the broader Julia context.  I do like this approach to composition delegation, but it requires automatically adding a lot of methods to the delegator, i.e.  Unicycle in this example, from all of its components, which feels kind of nasty and dangerous, especially since we allow dynamic addition of methods after-the-fact. In other words, you might add a method to Wheel, Frame or Seat at any time, which would presumably then also apply to Unicycle objects, potentially with unexpected consequences. It would be nice if the delegation was more limited than that. Golang doesn't have this problem since you can't dynamically add methods – everything is known at compile time.  0  0    Tom Breloff    10 21 15   I think this discussion shows complementary definitions of traits: verb-based traits: a type agrees to implement all the verbs appropriate to the given  verb trait  noun-based traits: a type agrees to contain certain underlying data  and thus the getter setter verbs could be implicitly defined for those fields  Whatever the final implementation of traits in Julia, I think keeping in mind this distinction could be helpful.   0  0    ssarkaray... gmail.com    10 21 15   How is the idea that any function defined with Julia tag gets into a first class object with name Julia in a combined ScalaJulia language :  Julia function sphere_vol r        julia allows Unicode names  in UTF-8 encoding        so either  pi  or the symbol π can be used     return 4 3 pi r 3 end is translated into ScalaJulia language as:   object Julia        def sphere_vol r : Int           return   4 3 pi r 3                Object Julia will get all first level functions defined in Julia syntax.  This is the simplest way to encapsulate Julia functions and inherit in other Scala objects or classes in ScalaJulia language.     This will preserve simplicity and performance of Julia functions.  SS   0  0    Stefan Karpinski    10 21 15   Excellent idea. You should make a PR against the Scala GitHub repo and see how it goes.   0  0    vav... uwaterloo.ca    10 21 15   Earlier I posted a statement in this thread that object-oriented programming is in many cases not suitable for scientific software because it forces the designer to make decisions too early in the design process that become unwelcome constraints as the project progresses.    If I understand what people are saying about traits, they may pose the same danger.  Just to give a simple example, suppose you are designing a class for univariate polynomials over a ring K.  You might expect that you will need both dense and sparse  i.e., most coefficients 0  polynomials, so you might create an abstract class for both dense and sparse polynomials.  In current Julia you might write:  abstract UnivariatePolynomial T   where T is the underlying ring.  You would specify nothing else.  Now if 'traits' were available as a language feature, you might create a member function  obtainCoefficient  that would work properly for both sparse and dense polynomials.  But the next week, someone asks whether you can handle polynomials specified as p x  det A-x B , where A and B are n-by-n matrices.  For polynomials in this format,  obtainCoefficient  is expensive and would not be regarded as a simple  getter  operation.  If many people had already written functions invoking the 'obtainCoefficient' method, then you would be stuck.  You would retrospectively realize that the obtainCoefficient member function was not a good idea.  This example is typical of open-ended scientific software projects.  So again, I would be wary of adding object-oriented features to Julia, at least until the language matures a bit more mature.  I have been on the other side of this fence already: I wrote the code for SortedDict in DataStructures-jl.  I had a mandate from Kevin Squire to make SortedDict a drop-in replacement for Dict.  Since there is no formal interface for 'Dict' defined, and indeed, Julia does not have a  means to specify interfaces, this means that I actually have to read all the code in associative-jl and dict-jl in order to carry out Kevin's mandate.  But this turns out to be not so hard!  -- Steve Vavasis   0  0    ssarkaray... gmail.com    10 21 15   Both Scala and Java are object oriented programming languages.  These OOP languages were used to build Hadoop Map-Reduce, Spark, Mlib and many other big data programming   tools framework. Julia should be seamlessly integrated with these mainstream big data and machine learning frameworks  for analyzing large volumes of data in parallel, using Statistics, Calculus, Linear algebra and other computing models. Combining Scala and Julia  can be a step towards this direction.   0  0    Abe Schneider    10 22 15   I think this is generally in-line with what I've been advocating for, and not that different from Scala's mix-ins:  trait Wheel        ...    trait Frame        ...    class Unicycle extends trait Wheel, Frame         ...    is essentially doing the same thing  i.e. copying the member variables and methods over .   As Stefan mentioned, Golang is not traditional OO. This  composition-based  approach is part of Go's OO approach. In go, a type can have named fields of different types  like most OO languages , but also has  embedding . For example, if one declared  type Unicycle struct       Wheel     Frame     Seat    then you could access the individual fields directly. So, if  u' is of type Unicycle, then you could access set u.Cushiness directly. Similarly, if the embedded types had methods, i.e. frame.Color  , they can be called directly through unicycle, u.Color  . This is similar to, but distinct from, inheritance  the difference is that the Unicycle type doesn't actually have these fields, just the ability to call them easily, which is significant because of interfaces . In the case of clashes, the program must specify which is meant, so if both Seat and Frame had a Color   method, the user would have to specify u.Frame.Color vs. u.Seat.Color. In Go, this is handled by the compiler, and would need to be handled somewhere in the Julia runtime REPL. It's a very nice paradigm, but would have to be made to fit within the broader Julia context.     0  0    Brendan Tracey    10 22 15    I do like this approach to composition delegation, but it requires automatically adding a lot of methods to the delegator, i.e.  Unicycle in this example, from all of its components, which feels kind of nasty and dangerous, especially since we allow dynamic addition of methods after-the-fact. In other words, you might add a method to Wheel, Frame or Seat at any time, which would presumably then also apply to Unicycle objects, potentially with unexpected consequences. It would be nice if the delegation was more limited than that. Golang doesn't have this problem since you can't dynamically add methods – everything is known at compile time.  Yea, it's this kind of thing that makes it tricky in Julia. The obvious problem is that you add a method  say cushiness to Frame  which makes dispatch ambiguous. One could add higher-level dispatch rules, but that's likely to add a lot of complexity.    On Thursday, October 22, 2015 at 7:03:43 AM UTC-6, Abe Schneider wrote: I think this is generally in-line with what I've been advocating for, and not that different from Scala's mix-ins:  trait Wheel        ...    trait Frame        ...    class Unicycle extends trait Wheel, Frame         ...    is essentially doing the same thing  i.e. copying the member variables and methods over .   I'm not familiar with Scala, so sorry if I'm telling you something you know, but in go the member variables and methods are not copied over. The Unicycle struct in go does not itself have those fields, the fields of the struct do. In other words, defining  type Unicycle struct       Frame     Wheel     Seat     Is exactly like declaring   type Unicycle struct      Frame Frame    Wheel Wheel    Seat    Seat     except that in the former case one can call unicycle.Cushiness   , and in the latter one must call unicycle.Seat.Cushiness  . In particular, if you swap out one Frame in the unicycle for a different Frame, the field values change  the methods won't, since methods are with a type .  0  0    ggggg    10 22 15   What is the other option here? It seemed like with the OO Julia way you are complaining about you at least have working  but slow  code handling your new polynomial type. In a case where your new type doesn't work with  obtainCoefficient , it won't  work with any of your other code either. You would just have no working code with your new polynomial type. How is that better?  But the next week, someone asks whether you can handle polynomials specified as p x  det A-x B , where A and B are n-by-n matrices.  For polynomials in this format,  obtainCoefficient  is expensive and would not be regarded as a simple  getter  operation.  If many people had already written functions invoking the 'obtainCoefficient' method, then you would be stuck.  You would retrospectively realize that the obtainCoefficient member function was not a good idea.  This example is typical of open-ended scientific software projects.   0  0    ssarkaray... gmail.com    10 22 15   This is where Object Oriented programming can be useful.  If you define a Trait and then several abstract classes extending the trait at many levels, it will be possible to define complex polynomial   p x  det A-x B    specific abstract classes at deeper levels for computing coefficients. OOP constructs will make super-classes and traits to be reusable for lower level abstract classes.  A type or operations on a type can both be abstract.  Mathematicians can exploit the power of OOP if the nested structures in mathematical expressions are understood properly for writing programs.   On Wednesday, October 21, 2015 at 12:43:17 PM UTC-7, vav... uwaterloo.ca wrote:   0  0    ssarkaray... gmail.com    10 22 15   I found that you are one of the core developers of Julia language. Could you please explain how Julia compiler and executor can be called through APIs ?  Are there any documentations for APIs.  Is it possible to call Julia compiler and executor through programming interfaces from Scala compiler   executor ?  I am  trying to understand broad strategy for possible implementation of ScalaJulia language.   0  0    Spencer Russell    10 22 15   Julia has a well-developed Clanguage API, so you can embed it inside other applications. Info on using it is here: http:  docs.julialang.org en release-0.4 manual embedding   -s   0  0    vav... uwaterloo.ca    10 22 15   One way to build a code-base that everyone can share is to specify interfaces to datatypes as in methods in Cpp base classes.  Another way is for each individual to write his her own code, and then read everyone else's code, and then meet at coffee shops and talk on the phone to get things to work together.  I am claiming that the second way is better for scientific software than the first way because scientific software is more open-ended than, say, systems software.  I am claiming that specifying interfaces from the outset can lead to prematurely locking in design decisions, and that I have seen examples of this in the real world.  Keep in mind that Julia is being touted as a suitable language for both the initial and the later phases of scientific software development.  In the event that Julia adds new OO or other interface-specifying features, obviously it would be possible for a team to ignore them, at least initially.  But I have also seen in previous projects that there is a tendency for people  including me  to jump onto the fanciest possible solution offered by the programming language to solve a software design problem.  -- Steve Vavasis   0  0    ssarkaray... gmail.com    10 22 15   Thank you for the link. I guess an intermediate layer of Clanguage application should be written for specific function calls, parameter passing and result set accumulation or manipulation. From Scala compiler  and executor  this application can be accessed through Native Interfaces  JNA4Scala !! . I am going to explore the documentation to see how GC works  important  and how DataFrames   DataArrays are stored in cache when called from Scala through Native Interfaces  JNA4Scala ! .   Please provide any other important links.    0  0    ssarkaray... gmail.com    10 22 15   It is very nice to exchange thoughts with mathematicians. If classes, instances, types, inheritance, polymorphism and many other things in OOP were derived from concepts in mathematics then there should be no contradiction between scientific computing and OOP.  It is just matter of correct interpretation to relate mathematical model to programming model.   0  0    Abe Schneider    10 23 15   Ah, okay, that is different then. What's the advantage of creating a new method versus copying the fields? I would imagine there is a penalty with each deference you have to follow in order to make that work.   I'm not familiar with Scala, so sorry if I'm telling you something you know, but in go the member variables and methods are not copied over. The Unicycle struct in go does not itself have those fields, the fields of the struct do. In other words, defining  type Unicycle struct       Frame     Wheel     Seat     Is exactly like declaring   type Unicycle struct      Frame Frame    Wheel Wheel    Seat    Seat     except that in the former case one can call unicycle.Cushiness   , and in the latter one must call unicycle.Seat.Cushiness  . In particular, if you swap out one Frame in the unicycle for a different Frame, the field values change  the methods won't, since methods are with a type .  0  0    Abe Schneider    10 23 15   An OO approach is really just specifying an interface in a formal manner. The second you write any type of interface, you always risk making a choice that will haunt you down the road. I don't see the difference between:  class Foo     float getX     ...     float getY     ...      and:  type Foo   ...   function getX f::Foo  -  float   ...   function getY f::Foo  -  float   ...    except that an instance of `foo` is being passed implicitly in the first case. To that extent, I would say Julia OO  i.e. on the dispatching . Where it is not OO is in the layout of the data.  It is true that with a more OO language, because of its formalism, you run the risk of declaring variable types in a parent class that might not be correct in the child classes, so some planning is required. However, what you gain is better code in the long run. For example, I might have:  abstract Baz  type Foo  : Baz     x::Float    type Bar  : Baz     x::Float    and an interface:  getX T  : Baz  b::T  -  Float   b.x   which works fine, except maybe someone else comes along and writes:  type Blob  : Baz     myX::Float    Now to fix your interface, you have to write a separate `getX` for `Blob`. This might not seem like a big deal, except you might not catch this issue until run time  I don't think there is a way a static-checker could identify the problem . Imagine a large library or base of code, with many people working on the code, and you suddenly are exposed to a large number of issues.  This is why people advocate OOP. In the first definition of `Foo`, I know it will always have an `x`, and I can easily see the interface necessary to access it.  So, yes, an OO usually requires more work up-front. If Julia is meant to be purely scientific language which requires a code rewrite for real-world use, then I won't argue with not having a way to compose the data. However, in any project of medium to large complexity, it will make life much more difficult not having that capability.   0  0    Brendan Tracey    10 23 15     On Friday, October 23, 2015 at 7:22:28 AM UTC-6, Abe Schneider wrote: Ah, okay, that is different then. What's the advantage of creating a new method versus copying the fields? I would imagine there is a penalty with each deference you have to follow in order to make that work.  The advantage is simplicity. A unicycle is a Frame, a Seat, and a Wheel, no more, no less  unless we added more to the definition of course .  Inheritance gets complicated fast in Cpp  again, can't speak for Scala  with virtual functions, virtual vs. nonvirtual descructors. Additionally, Unicycle doesn't inherit from anything. It's not a subclass of anything. It can be used however.   As to dereferencing, types in Golang are not boxed like in Java  for example . We could construct Unicycle as  type Unicycle struct        Frame      Seat      Wheel    or as  type Unicycle struct         Frame       Seat       Wheel    or any combination you'd like. In the latter case they are pointers, and in the former they are not. So, first of all you can avoid the dereferencing by not having pointers. Secondly, in Golang all of the types are known at compile type, so I believe you can call the function without going through extra deferencing, even in the case where they are pointers.  0  0    Brendan Tracey    10 23 15   On Friday, October 23, 2015 at 7:38:37 AM UTC-6, Abe Schneider wrote: An OO approach is really just specifying an interface in a formal manner. The second you write any type of interface, you always risk making a choice that will haunt you down the road. I don't see the difference between:  class Foo     float getX     ...     float getY     ...      and:  type Foo   ...   function getX f::Foo  -  float   ...   function getY f::Foo  -  float   ...    except that an instance of `foo` is being passed implicitly in the first case. To that extent, I would say Julia OO  i.e. on the dispatching . Where it is not OO is in the layout of the data.  In some  languages there is no difference. In Go, a method is exactly a function that can be called with a special syntax. One can do  c :  mat64.NewDense 5, 5, nil  c.Mul a, b    or one can do   mat64.Dense .Mul c, a, b   There aren't many cases where one would actually want to do the latter, but it makes the definition of behavior clear.  I think the difference in Julia would be the interaction with multiple dispatch. In the former case, it seems like getX would live in its own namespace  only accessible through the Foo class , while in the latter case it would add to the many definitions of getX.   It is true that with a more OO language, because of its formalism, you run the risk of declaring variable types in a parent class that might not be correct in the child classes, so some planning is required. However, what you gain is better code in the long run. For example, I might have:  abstract Baz  type Foo  : Baz     x::Float    type Bar  : Baz     x::Float    and an interface:  getX T  : Baz  b::T  -  Float   b.x   which works fine, except maybe someone else comes along and writes:  type Blob  : Baz     myX::Float    Now to fix your interface, you have to write a separate `getX` for `Blob`. This might not seem like a big deal, except you might not catch this issue until run time  I don't think there is a way a static-checker could identify the problem . Imagine a large library or base of code, with many people working on the code, and you suddenly are exposed to a large number of issues.  This seems more like an issue of compiler vs. no compiler issue than one with OO vs. multiple dispatch.   You can do OO without inheritance  or OO like things if your definition of OO includes inheritance . In Go, one would define   type GetXer interface        GetX   float64    I could then write a function func SquareX g GetXer  float64        v :  g.GetX        return v   v    Now, any type that has a GetX method can be passed to SquareX. There is no inheritance necessary to make this happen.   0  0    ssarkaray... gmail.com    10 23 15   Inheritance should be understood in terms of properties  and operations on properties  of a classes and sub-classes.  In functional programming language, application of functions like func_1 x, y, func_2 z, p   is implicitly exploiting the idea of inheritance. Making such relationships explicit in programming languages will lead to much less errors at run time with compile time   definition and declaration   checks.   0  0    Abe Schneider    10 24 15   Swift has an interesting take on composition via protocols  note, it also has the concept of single inheritance :  https:  developer.apple.com library ios documentation Swift Conceptual Swift_Programming_Language Protocols.html  it avoids copying anything into the child class, but rather sets up both the variables and methods that a child class should support. How the variable is actually implemented in the class is up to the class  which I think is the nice part . Thus you can do:  protocol Foo     var x:Int   get set      x must evaluate to an Int, and can be both 'get' and 'set'    class Bar: Foo     var x:Int    treat it as a simple Int    class Baz: Foo     var x_latent:Int       x is a 'functional' variable where we explicitly define how it is get'd and set'd   var x:Int       get         return x_latent 2           set         x_latent   2 x         While it does involve rewriting code  which I don't love , it importantly protects the developer from making mistakes  i.e. it will complain that `x` is not defined, and will force `x` to be of type Int .  Swift also has the concept of generics. You can make Protocols generic, so in theory you could make X of any type. Unfortunately, there appears to be a gap in the language  like Julia, it is still an evolving language , and making variables in the protocol appears to create issues down the line.  0  0