Invisible wrote:
> Darren New wrote:
> 
>> (I count "reuse" as the ability to take code already written and use 
>> it in ways not anticipated when it was written.)
> 
> Isn't that "extensibility", not "reusability"? You want to *extend* 
> existing software to do something it wasn't designed to do.

Well, the claims of the OO proponents were that the extensibility (via 
inheritance) would make the reusability much better. (Along with the 
encapsulation, of course.)

Extensibility is actually something different, when speaking in 
technical terms. Extensibility is the ability to add your own 
domain-specific stuff to your environment and have it have all the 
powers and basically be indistinguishable from the stuff that is 
privileged to come with the environment. E.g., there's nothing built-in 
functions can do that you can't, there's nothing programs that come with 
the OS can do that your programs can't, etc.

>> But particular OO libraries are IME limited to doing exactly what they 
>> were designed to do, without really being any more extensible than a 
>> procedural language with carefully crafted callbacks.
> 
> You're still talking about "extensible", not "reusable".

Well, no.

> With any half-decent OO language, this problem immediately goes away. 

Not really. Not in C++ or Java, for example. (Yes, you can do it in C++, 
but not because of the OO nature of it.)

> You can now write a sorting algorithm once for each container type (or 
> even once overall if you desire, but that's probably less efficient) and 
> you're done. This one sorting algorithm can then be reused anywhere you 
> need to sort data.

I can already do that in C. Look at the qsort routine. You're not 
talking about OO here. You're talking about how statically typed 
something is regardless of whether it's OO.

> These days OOP isn't the only paradigm that actually offers this 
> benefit, but the benefit is real none the less.

There are definitely benefits to OO. Being able to reuse existing code 
by subclassing it and overriding just that which isn't quite right (when 
the original designer hadn't anticipated you'd subclass it in that way) 
isn't one of them.   Certainly less so than some of the other mechanisms 
that have been invented without nearly as much hype.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   Especially in the second case the OOP aspect helps reimplementing the
> > code which receives the XML elements on a per-program basis. This is
> > reusability at its best.

> Would be funky if true.  Sadly, even the Java implementation doesn't 
> actually work right, and crashes if you use it in two threads at once, 
> which would lead one to believe it's not actually storing everything it 
> needs in the instance variables of the parser.

  Just because some library is buggy doesn't tell anything about the
reusability of OO code.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Just because some library is buggy doesn't tell anything about the
> reusability of OO code.

True. But it points out that OO doesn't solve many of the problems that 
make code non-reusable. :-)  I.e., if it's still easy to make the bugs 
that make things non-reusable, it's probably not as good for reusability 
as other paradigms that prevent such mistakes.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> Warp wrote:
>>   Just because some library is buggy doesn't tell anything about the
>> reusability of OO code.
> 
> True. But it points out that OO doesn't solve many of the problems that 
> make code non-reusable. :-)  

Well, at least, OO as implemented by Java. :-)  But we already know Java 
sucks pretty bad.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Invisible wrote:
> > You can now write a sorting algorithm once for each container type (or 
> > even once overall if you desire, but that's probably less efficient) and 
> > you're done. This one sorting algorithm can then be reused anywhere you 
> > need to sort data.

> I can already do that in C. Look at the qsort routine.

  Except that C's qsort can only be used to sort arrays, and additionally
each element must be addressable with a void*. Thus it cannot be used to
sort all possible (random access) data containers. (For example the data
container might not be a contiguous array, such as eg. a std::deque isn't,
or the array iterator might not be castable to and from void*, eg. because
it's larger than a single pointer.)

  (Not to talk about casting to and from void* is completely type-unsafe,
but that's another matter, of course.)

> You're not 
> talking about OO here. You're talking about how statically typed 
> something is regardless of whether it's OO.

  Specific algorithms are not good examples of OOP. Data containers are.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Just because some library is buggy doesn't tell anything about the
> > reusability of OO code.

> True. But it points out that OO doesn't solve many of the problems that 
> make code non-reusable. :-)  I.e., if it's still easy to make the bugs 
> that make things non-reusable, it's probably not as good for reusability 
> as other paradigms that prevent such mistakes.

  I think you are starting to stretch the argument.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Specific algorithms are not good examples of OOP. Data containers are.

OK. And yes, I'm stretching the argument a bit to see how far it can go. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Specific algorithms are not good examples of OOP. Data containers are.

> OK. And yes, I'm stretching the argument a bit to see how far it can go. :-)

  I think we can all agree that there's no silver bullet.
http://en.wikipedia.org/wiki/No_Silver_Bullet

  We can also agree that OOP did not bring the panacea it was supposed to,
after all, although it *did* bring a whole lot nevertheless. It's just not
the *ultimate* solution to all problems.

  The two main aspects of OOP are modularity and inheritance. Modularity
is a hugely useful paradigm, but inheritance, while sometimes useful, was
not after all the panacea it was supposed to be. Practice has diminished
the importance of inheritance as a tool quite a lot in the past ~20 years.

  What more or less surpassed inheritance in importance is generic
programming (by whatever means and paradigms you like). While some aspects
of generic programming are perhaps somewhat similar to inheritance, it has
nevertheless resulted to be more useful and efficient than pure inheritance
in many areas.

  Of course the definition of "generic programming" can be a bit fuzzy.
Perhaps it could be argued that C++ template metaprogramming and Haskell
functional programming are both different approaches at generic programming.
In general it could be said, perhaps a bit simplistically, that generic
programming is a way to write algorithms which will work for (almost)
any data type which meets certain criteria, without the algorithm having
to explicitly know what the data type in question is. In OOP this has
classically been achieved through inheritance, but generic programming is
often even more powerful and expressive than that (and often leads to
faster and more efficient code, both speedwise and memorywise).

  Of course this doesn't mean OOP is dead. Modularity is still, and will
always be, a hugely useful design tool. (Yes, also for reusability.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   The two main aspects of OOP are modularity and inheritance. Modularity
> is a hugely useful paradigm, but inheritance, while sometimes useful, was
> not after all the panacea it was supposed to be. Practice has diminished
> the importance of inheritance as a tool quite a lot in the past ~20 years.

I think that's basically what my original premise was to be. Well stated.

>   Of course the definition of "generic programming" can be a bit fuzzy.
> Perhaps it could be argued that C++ template metaprogramming and Haskell
> functional programming are both different approaches at generic programming.
> In general it could be said, perhaps a bit simplistically, that generic
> programming is a way to write algorithms which will work for (almost)
> any data type which meets certain criteria, without the algorithm having
> to explicitly know what the data type in question is. In OOP this has
> classically been achieved through inheritance, but generic programming is
> often even more powerful and expressive than that (and often leads to
> faster and more efficient code, both speedwise and memorywise).

I'll grant you that.  I think there are also paradigms (like what folks 
call communication-oriented programming, or functional programming, or 
"component-oriented programming", or etc) that do a better job without 
being overhyped.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

I always thought the benefits of OO were in design, rather than 
reusability.  After all, it's one thing to simplify the design of a 
complex system and save months of work in the process; OO can do this 
quite well.  It's another to combine a "BigInt" class with a "Complex" 
class.  OO doesn't necessarily help in this situation (although it can).

...Chambers

Post a reply to this message