Registered: Dec, 2006
Re: Cedric Beust on Programming Erlang
Posted: Oct 4, 2007 11:36 AM
> > > #1 - some times I want to have one more function for
> > > data type I don't have the source code; impossible
> > > OOP, easy with the 'classic' approach.
> > That does not make OO 'suck'. It just makes it not
> > suitable for every purpose and in every circumstance.
> > for example, allows you to extend the class interface
> > a non-member function.
> Which defeats the whole concept of "methods together with
You use namespaces in C++ to group non-member functions
with related types.
> > > #2 - the strict classification of data types into
> > classes
> > > creates many problems in many real world problems.
> > > Entities may be customers, customers may be persons,
> > but
> > > later customers can be companies, for example. Trying
> > to
> > > model that with classes asks for trouble.
> > How do you model that, trouble-free, with functions?
> A type is defined by its role. If I have an item which
> quacks, and a list of duckies, I don't care if item is a
> duck, because it quacks.
> So there are two solutions:
> 1) structural subtyping
> 2) multimethods
> In both cases, I can use a type for whatever purpose I
> want without a strict classification.
Structural subtyping is possible in both C++ and Ruby.
I can see your argument against static typing,
but not against OO here.
And you can still do that with Java-style OO - just implement Customer interface. Refactoring is possible in OO too!
> But today's OOP is nothing like that: it's full of
> factories, interfaces, concepts, abstractions, patterns,
> etc. A nice and small idea has turned into a nightmare.
> Look at every Java library out there: incredibly complex.
> Even the simplest of tasks, like reading a few bytes from
> a file, requires lots of complicated steps to achieve.
> A few moons ago I downloaded a Java library for a very
> simple task: FTP management (connection, disconnection,
> downloading, uploading etc). I was expecting a simple and
> basic interface, but the library had over 100 types and
> classes to learn!!! shock and awe.
> And it's not the first example of that happening. In my
> company, we have abandoned the whole J2EE stack (JSPs,
> servlets, struts, xml, hibernate, whatever) and made a few
> simple data-aware widgets for ULC (www.canoo.com) where
> with a few lines of code many types of data driven
> applications can be easily built. And it works like a
Java is hardly the poster child of OO languages.