Re: [9fans] gcc on plan9

["David Leimbach" <leimy2k@gmail.com>]

> >
> > OOP isn't pointless - but most supposed OOP code is just a poor
> > excuse not to understand your flow control.  My annoyance is that the
> > cult of re-use that is associated with most OOP proselytization makes
> > the code bloat hugely - I'm as guilty of that as the next guy.
> > Compare the STL hash implementation with the the elf hash table
> > implementation - the latter works in 20 lines of code, the former
> > requires 769 lines of near-opaque code.  Sure, it extends to any
> > object you have, but the development cost was huge.  It's good to
> > have it, but then people mimic that style with substantially less re-
> > usable constructs that aren't nearly as functionally stable as
> > hash_map and hash_set.
>
> you're really on to something here.
>
> 768/20  ~= 40.  that may be a good proof that hash tables can't be abstracted from
> the stuff hashed.
>
> i'm not convinced by OOP -- at least in the sense that leads to STL hash tables.

I don't understand why people say OOP and STL in the same sentence.
Just because code is encapsulated and isolated to a class, does not
make that code OO.

In fact, currently, none of the STL classes are even safe to derive
new classes from, based on the fact that none of them have virtual
destructors.

I'd call STL containers and algorithms an attempt at parametric
polymorphism which has been handled better in almost any Functional
Programming language I've ever seen than in C++.

>
> interfaces like those provided by plan 9 fileservers are much more compelling.
> /dev/draw seems to me much more object-oriented than anything i've seen in
> c++ or java.  it's ironic that the oop crowd seems to be the biggest poo-pooers
> of plan 9.
>

I know people who think files should be for files, and that's it.
That abstracting the filesystem to mean anything else is almost as bad
as overloading operators in C++.

I can kind of understand the complaint.

in C++ for example you've got things like

C = A + B;

If A and B are objects of classes, this could mean a lot of different
things as you must define operator + for that class.  A and B don't
even have to be of the same classes, and the same goes for C.  Without
knowing about the data types, it's not really possible to know all the
possible side effects, exceptions, allocations (needless copies that
might be immediately thrown out and how different compilers might
interpret those) etc for a single expression.  In fact there are a lot
of different function calls and code paths that could imply.

The same might be said (though I think with less confusion) when someone says:

echo eject > /dev/<blah>

could be confusing because the file interface and syntax by which we
operate on it is also overloaded.

Now think about Mac OS X again.  Sure it's unix underneath, but does
grandma even know or care about that?  Probably not.  One of my best
friends is a graphic artist who uses it every day.  He asked me about
Terminal.app one day (which would get him a shell and expose him to a
whole other world of functionality).  I told him to ignore it, that
for him, it'd be opening up the wrong can of worms.

For some, ignorance really is bliss.  And never needing to touch the
shell and still be productive is actually a dream come true.

Dave

> - erik
>