OO vs Erlang

[Chris Pressey]

Jay Nelson wrote:
> I haven't used ocaml or any other "object-oriented" functional
> language so I may be way off here, but thinking about it raised
> some issues for me.
>
> Chris Okasaki talks about persistence in "Purely Functional Data
> Structures".  Functional data structures are persistent, meaning
> that multiple versions can exist simultaneously, whereas imperative
> data structures are ephemeral meaning that only one version exists
> at a time.
>
> All the OO paradigms I've seen are designed around ephemeral objects,
> with the exception of versioning OO databases which are generally
> approximations since only the DB saved versions exist, not the
> temporary versions that were used to get to a save state.  In OO
> you don't have to deal with outdated copies of objects, every
> instance is ephemeral.  In erlang if you were to make some sort of
> static object, you would have to make sure that it is not modified
> in more than one process, or stashed inside some list, or else you
> have to serialize it in a server or store it in an ets table and
> always get a fresh copy (well, I guess the ets approach isn't
> even guaranteed to work).

Yep, the serialization problem draws you towards using one process per
object, so to speak - or, to start thinking in terms of servers rather
than objects.

I dunno, though - sorry if this is getting too abstract for the Erlang
list (I know of at least one other list where this would be more
apropos, and if this list is really getting too fertile, I'll happily
move it there,) but - at the risk of introducing weird concepts like
metaparadigms, I think it comes down to how the buzzwords cloud our
perceptions regarding how these various schools of programming come to
be.

Heresy follows (lovable kook that I am, I'm practically expected to
have a controversial theory or two, right?)

My current opinion is that there are really only two computational
paradigms that humanity has discovered so far - commonly called
imperative and functional, although those names aren't very
descriptive, and you almost might as well call them the Turing approach
and the Church approach - or destructive and derivational, or
persistent and emphemeral, or updatable and single-assignment.  The
basic idea is that, in a functional language, a symbol cannot take on
more than one value in a single scope, while in an imperative language,
it can.  This generally means that repetition (actually 'rechecking',
which I would claim is required for computation, although I probably
can't prove that) is done with iteration in an imperative language
(i.e. 'while', 'if-then-goto', etc), while it must be done with
recursion in a functional language (since you cannot update a counter
variable - you must enter a new scope instead.)

Further, we tend to think of object-oriented programming,
concurrency-oriented programming, logic programming, rewriting,
dataflow, automata, and the like, as seperate paradigms on par with
those two computational models, but I think they are actually
breakdowns along a different dimension, perhaps several different
dimensions.

That is to say - objects and processes don't really have ANYTHING to do
with computation.  They're not computational models - they're
*communication* models.  For that reason, you can have OO+imperative
(Java,) OO+functional (O'Caml,) CO+functional (Erlang), CO+imperative
(??? i can't think of an example offhand) and so on.

(Logic programming, OTOH, looks like a subset of functional
programming, while rewriting looks like a subset of imperative
programming - even though they otherwise seem fairly similar.  I have
yet to delve into that question very deeply.)

This also means that most of the "special" features associated strongly
with a given paradigm have little or nothing to do with that paradigm -
for example, lambdas aren't something that must exist solely in a
functional framework - an imperative language ought to be able to have
lambda procedures along the same lines.

But back to objects.  In OO, objects are often attributed with
"identity", and this directly relates to ephemeral vs persistent
(identity implies persistence.)  But while this can be useful, it's
also not strictly necessary - I don't think it's an issue in
OO+functional languages like O"Caml.  In other words, I think "object
identity" is an artefact stemming from most OO languages being
OO+imperative - and is, at it's root, more of an imperative vs.
functional issue, than anything to do with OO.  (Hell, I'm tempted to
think it has more to do with databases than anything, but after making
a wild claim like there being seperate computational and communication
paradigms, I'm a bit wary about introducing a topic like data storage
paradigms...)

> [...]
> What would you be trying to accomplish by using an OO approach?
> I think that at the fundamental roots of the language, erlang
> contains versioned data and OO is antithetical to that.  Suppose
> you have an erlang textbox UI record structure in your internal
> model.  Every time a character is added you create a new copy of the
> structure and throw away the old one.  Undo would be very easy
> if you keep all the old versions of the data.  The mixin approach of
> adding behaviour to display the data would work well (just call
> functions in a display textbox module or delegate to a single
> process), but the inheritance approach of statically structured OO
> wouldn't work as well because you would end up with multiple
> processes delegating to each other depending on the depth of the
> inheritance hierarchy just to draw the characters in the right place,
> and then you would have to communicate each version of the data
> when implementing undo, or else repeating the data versioning edit
> in all processes in the delegation chain whenever a character came
> in.

Hmm, the strength of Erlang here would seem to be how easily Erlang can
encapsulate ephemeral data (the function arguments) within a persistent
entity (the server).  Thinking about it a bit, I'm not actually
convinced that undo does become so much easier, because anything should
be able to query the value of the textbox at any time - the textbox is
persistent.  If it comes down to how I'd code it, the textbox would be
a server, which would still have to keep a list of all previous values
the textbox had, as its state - it would be nice to be able to leverage
the recursive nature of functions to implicitly store those old values,
but I don't think it could be done if that textbox could be arbitrarily
addressed by other processes (sorry, I can't think of a good way to
explain it right now, I'll have to think about it more.)

> I guess my thinking is to do two things: 1) push erlang in the
> erlang-y direction as far as I can to see what problems it is
> suitable for, and 2) state a problem and see how many approaches
> I can think of for implementing it in erlang.
>
> Use OO is not a problem, it is a solution.  What problem are you
> trying to solve?

Honestly... although I like hacking (er I mean systems engineering,
right,) in Erlang, my interest has always been in language design. 
While I support the idea of "choose the right language for the problem"
in theory (like I support the idea of reusable code - in theory -) in
practice it doesn't pan out as well as it should.  I think humanity has
been searching for a general-purpose programming language since, well,
FORTRAN, and every attempt (Algol, PL/I, BASIC, Java et al) seems to
fall way short and "niche-ify or die" quite quickly (frighteningly
enough, C, which was never intended to be anything except a
systems-construction language, seems to dominate through sheer
ubiquity)

My feeling is that Erlang, appropriately specialized though it is, is
as close to a well-designed general-purpose language as any other;
probably closer.  It has much appeal by being sheer fun to code in. 
The "problem" is that Erlang still has it's weaknesses, as would be
expected, and for it (or a descendant of it) to be applied to a greater
range of problems (such as UI perhaps), it should be open to adopting
the best features of other languages, while avoiding their weaknesses.

(So there's really no problem per se.  I'm just a nuisance.  :)

When learning Erlang - yes, throw OO out the window.  It'll just mess
you up.  But don't *abandon* OO - when you begin to master Erlang, I
think you find that, naturally, there are some things that it doesn't
do so well, that some OO languages have addressed - and it's silly to
be dismissive of something that does work, just because it's "not from
our school".  Surely the schools still have something to learn from
each other - and from schools yet to be discovered?

> Right now for UI I have taken the #2 step and am thinking hard about
> the #1 step.
>
> jay

I guess my feeling is that #1 is probably going to happen anyway, so
I'd like to promote #2 insofar as it actually results in something
useful (and isn't just a result of wanting to imitate
Java/Haskell/etc.)

More on this later, inevitably - I think it'll happen more along the
lines of small changes which make small things easier - like Vlad's
-delegate(...) proposal, rather than any Grand Reorganization Into
Objects... and I still have a whole lot of thinking about it to do...

-Chris


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca