[erlang-questions] Intro to Erlang Exercise #1 (Was OO -> FP)

[Jay Nelson]

Recently there were questions about grokking erlang when coming from  
OO and how to design a system.  Here is an exercise to demonstrate  
some introductory erlang techniques:

1) Do the standard polygon problem by implementing a module with a  
record and a set of functions for manipulating polygons.

-module(polygon).
-record(shape, { ... }.

new(triangle) ->
    #shape{ ... };
new(rectangle) ->
    #shape{ ... };
new(square) ->
    #shape{ ... }.

delete(#shape{}) ->
    undefined.



Start out with a small set like triangle, rectangle and square before  
adding more.   Add a couple functions like perimeter and area.

2) Using the erlang shell, bind a few variables with new polygons and  
compare the results of calling the different functions.  Inspect the  
resulting records and notice how you can keep an old version around  
and compare it to a newer version.

3) Upgrade the implementation to include locations of vertices and  
the ability to move, compute center point and distance between  
centers of two polygons.

4) Add a second module which organizes a collection of polygons into  
town square with a central rectangular road and various shaped  
buildings at different addresses on the road.


This exercise demonstrates the following things about erlang:

1) Module is the fundamental form of code encapsulation
2) Records are good places to store structured data, learn how to use  
their syntax
3) Functions as transformers from old data instance to new data instance
4) Modules + records create an equivalence to getters / setters and  
manipulators in OO
5) The shell provides a dynamic way to test code and inspect structures
6) Direct translation of OO type instances is quite simple
7) How to code, debug, compile, run, etc.
8) Module composition can be used to add complexity on top of  
existing code but at a higher level of abstraction

Key understandings when comparing to OO:

1) Encapsulation is similar, but records are not opaque
2) Static data manipulation modules are useful basic abstractions  
allowing easy enhancement
3) Behavior is separate from data structure and data maintenance
4) Complex system architecture decisions can be deferred more easily


The exercise creates a representation of data instances plus  
manipulators and a coordinated higher level application.  It does not  
make any decisions about concurrency, persistence, distribution,  
versioning of instances, etc.   These are all behaviors which can be  
added by later modules -- in fact it is possible to have one or more  
modules which have differing implementations of these architectural  
decisions and have the system dynamically switch among the solutions  
as needed, all the while using the same underlying data structure  
representation.


For a bonus consider how you might solve the following problem:

1) Create a process that has a town center described
2) Enhance the polygon module to include color
3) Dynamically upgrade the process to include colors on buildings
       a) You could replace the old process with a new one
       b) You could replace the town center elements directly inside  
the original process


jay