[erlang-questions] Design methodology going from Object oriented to functional programming?

[YC]

Actually, at the level you are describing, there should be no difference
between FP and OOP.

While OOP definitely emphasize data and relations, it is not the only
paradigm that does so - and given your background you should be experienced
with the relational paradigm, which has even heavier emphasis on data and
relations, but is not OOP.

To leverage your knowledge on relations - you can pretend sql queries are
functions, i.e. select is a function, update is a function, and insert is a
function.  Then instead of writing

object.insert()

you write

insert (object) - which looks a lot like the sql query insert into table ...


That's it.  In the Java style OOP the head of the statement is an object,
and in FP the head of the statement is a function name.  But in either case
you need to model the same world.

An extremely crude way of thinking about FP is that it decouples the data
from the function (or vice versa, that OOP couples functions and data).
That means some facilities that you've taken for granted in OOP, such as
inheritance, polymorphism, etc., will no longer be available.  But FP have a
different approaches to address these problems, and that's where the rubber
meet the road.

Erlang's process model is basically the Actor model - the idea of everything
is an actor feels similar to everything is an object in OOP.  So as others
have alluded to instead of thinking in objects you can think in processes.
But Actor model is independent of FP or OOP, so you would still have to get
used to the FP part in Erlang.

You might want to check out http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
<http://www.math.chalmers.se/%7Erjmh/Papers/whyfp.html>.  A higher level
introduction is http://www.defmacro.org/ramblings/fp.html.

Cheers,
yc

On 10/22/07, Alexander Lamb < alexander.lamb@REDACTED > wrote:
>
> Hello list,
> I am trying to understand what is the design process (intellectual, that
> is) when building a program in Erlang.
>
> Indeed, in the object oriented world, I would start by finding what my
> classes might be and the relationship between them. Gradually I would add
> functions (class or instance methods) to the classes in order to provide
> solid foundations on top of which I can write an application.
>
> For example, I could have PERSON, PROFILE, ROLE, FEATURE, etc... and
> decide a PROFILE is a collection of FEATURES. A PERSON can have 0 or many
> ROLES. A ROLE is a PROFILE on a given area (a department for example) for a
> given time. I would then add functions such as "give all the active roles
> for the user" or "what features give that profile" or "does the user have a
> given feature for that department".
> I admit it is more complexe than that, but you get the idea.
>
> Obviously, this doesn't seem to be the way to go with Erlang. Intuitively,
> I would start making a list of all the functions which will allow me to
> interract with my application. In that case I could have "give me all users
> with an active role on that department", etc... Then by implementing those
> high level functions I would split them into pieces by calling smaller
> simpler functions. The underlying data structure will "just follow" or
> "appear" naturally.
>
> Hence: object oriented design is "data structure and relationships first,
> functions second" and functional design is "functions first, data structure
> second".
>
> Am I being over simplistic here. Are there some guidelines as to how one
> can approach a problem when creating a new program? Especially programs
> which deal with persistent data, not protocole analysers or socket servers!
>
> Thanks,
>
> Alex
>   --
> Alexander Lamb
> Founding Associate
> RODANOTECH Sàrl
>
> 4 ch. de la Tour de Champel
> 1206 Geneva
> Switzerland
>
> Tel:  022 347 77 37
> Fax: 022 347 77 38
>
> http://www.rodanotech.ch
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20071022/0fc13763/attachment.htm>