Julia and Object-Oriented Programming

[Sisyphuss]

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 C++ does not apply in Julia.

It took me long to realize that the equivalent of Class of C++ 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 C++.

However, this design has two issues:

1) The visit control is not as fine-grained as in C++, 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]

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.

[Simon Danisch]

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

[Tobias Knopp]

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

[Tomas Lycken]

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 C# (or C++), 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

[Páll Haraldsson]

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.

[vav...@uwaterloo.ca]

Going a bit on a tangent, I claim that object-oriented programming, at least as embodied in C++, 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 C++ 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 C++ sense of the term.

-- Steve Vavasis

On Sunday, October 18, 2015 at 8:41:58 AM UTC-4, Sisyphuss wrote:

[Abe Schneider]

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 C++ is functional.

[Abe Schneider]

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.

[Abe Schneider]

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 C++, is not really suitable for scientific computing and in fact has led certain codes to go astray.

C++ is purposefully a multi-paradigm language for this reason. C++11 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 C++ 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 C++ 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.

[Stefan Karpinski]

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, C++, 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.

[Sisyphuss]

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.

[Tim Holy]

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

[Abe Schneider]

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, C++ 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).

[Abe Schneider]

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.

[Tom Breloff]

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...)

  

[ssarkaray...@gmail.com]

I am confident that a new OOP language ScalaJulia is possible integrating syntax of both functional languages Scala and Julia.

Thanks,

SS

[Christof Stocker]

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:

[Stefan Karpinski]

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. 

[Abe Schneider]

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 C(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.

[Sisyphuss]

I'm sorry, but I didn't find the ScalaJulia project as you mentioned.

[ssarkaray...@gmail.com]

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

[ssarkaray...@gmail.com]

Is it ice cream on steak or a new steak sauce added to streak ?

[Abe Schneider]

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{C <: B}(b::C) = b.x

get_y{C <: B}(b::C) = b.y

That's my $0.02. 

[Stefan Karpinski]

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.

[Brendan Tracey]

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, Go 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.

[Stefan Karpinski]

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.

[Stefan Karpinski]

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, Go 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. Go doesn't have this problem since you can't dynamically add methods – everything is known at compile time.

[Tom Breloff]

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.

[ssarkaray...@gmail.com]

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

[Stefan Karpinski]

Excellent idea. You should make a PR against the Scala GitHub repo and see how it goes.

[vav...@uwaterloo.ca]

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

[ssarkaray...@gmail.com]

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.

[Abe Schneider]

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).

[Brendan Tracey]

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. Go 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).

[ggggg]

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?

[ssarkaray...@gmail.com]

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:

[ssarkaray...@gmail.com]

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.

[Spencer Russell]

Julia has a well-developed C 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

[vav...@uwaterloo.ca]

One way to build a code-base that everyone can share is to specify interfaces to datatypes as in methods in C++ 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

[ssarkaray...@gmail.com]

Thank you for the link. I guess an intermediate layer of C 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. 

[ssarkaray...@gmail.com]

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.

[Abe Schneider]

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.

[Abe Schneider]

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.

[Brendan Tracey]

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 C++ (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 Go 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 Go 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.

[Brendan Tracey]

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.

[ssarkaray...@gmail.com]

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.

[Abe Schneider]

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.