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