[erlang-questions] Re: OOP in Erlang

[Ulf Wiger]

黃耀賢 (Yau-Hsien Huang) wrote:
> 
> Recently I read the book
> "Design Patterns Explained," which hints that OOP/OOD is to treat
> everything, including primitive datatypes, as object.
> And he explained how abstraction
> is different from implementation. Then I thought that Erlang
> treats everything as function or process, but really?

Yeah, well, I've had some pretty interesting discussions with
proponents of that view, and I would rather say that it is
possible to deal with abstractions as wholly separate from
implementation, but it is wrong to say that it holds in general
(at least for any useful definition of implementation).

The idea, as I understand it, is that you want to adapt to
the common pattern that you have separate teams that handle
requirements, architecture, and programming (oh, and yet
another team doing testing, usually). I am very well familiar
with that way of working, and will go as far as saying that
it can sometimes be extremely difficult to avoid.

The real danger with that setup, and the viewing of abstraction
as somehow separate from implementation, is that you tend to
to do "abstraction" for its own sake. The quotation marks are
there because in many cases, people confuse drawing visual
symbols with abstraction; while it may be in some dimension,
it is not abstraction in any useful sense for a programmer.


"The purpose of abstraction is not to be vague, but to create a
new semantic level in which one can be absolutely precise."
Edsger W. Dijkstra, "The Humble Programmer", October 1972


To do abstraction in the way Dijkstra intends, you should have
a very good intuition about implementation issues. You might
say that abstraction grows from implementation.

The key here is that you need to *pick* your abstractions
carefully based on your understanding of the domain *and*
details, opportunities and limitations of the implementation
layer. Erlang provides some abstractions that are a bit
unusual, but have been found in practice to work exceedingly
well in some domains.

Some of those abstractions tend to be sub-optimal if your
aim is to write computational code that goes blazingly
fast. OTOH, some of the abstractions that have traditionally
fared well in that regard are suffering now, as the
hardware becomes increasingly parallel - something that
happens to suit Erlang just fine.

Programming is all about abstraction - layers on top of
layers of abstraction, reaching all the way deep down into
the hardware your program runs on.

> Abstraction: it's separated from implementation. Abstraction
> is done in Erlang by hot code replacement.

No. Abstraction is when you make a model of something by
hiding underlying details. Abstraction is all over the place
in programming. Any Erlang data type is an abstraction - as
Erlang doesn't allow you do address memory directly, you
cannot control how many bits are assigned, how the data is
laid out, where it is, whether it is shared, etc. Nor are you
supposed to care.

"Programming is both a top down activity from requirements and
overall structure of the system and a bottom up activity based
on the abstractions provided by the programming language.
Abstractions such as modules, processes, higher order
functions, etc. are to the programmer like transistors,
capacitors, resistors, etc. to the hardware designer.
It is important that the abstractions be few, simple to
understand and yet powerful and provide the needed
functionality. For example, if the application is inherently
concurrent it would be very dfficult to program without
some process concept. In that case the application program
itself would have to include some form of scheduler.
Distribution, error handling, and hot code loading are
extremely complicated requirements and the support for them
provided by Erlang enables the programmer to concentrate on
the application rather than on the basic programming technology."

(Bjarne Dacker, http://www.erlang.se/publications/bjarnelic.pdf,
pg 26)

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
http://www.erlang-solutions.com