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.
On Thursday, October 22, 2015 at 4:00:36 PM UTC-4, vav...@uwaterloo.ca
wrote:
>
> 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
>
>
> On Thursday, October 22, 2015 at 12:02:21 PM UTC-4, ggggg wrote:
>>
>> 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.
>>>
>>>>
>>>>
