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.
On Mon, Oct 19, 2015 at 8:18 AM, Abe Schneider <[email protected]> wrote: > > > On Sunday, October 18, 2015 at 9:44:21 PM UTC-4, [email protected] > 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. > > >> >> >> >> 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 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. >>> >>> >>> >>>
