Ed B.
unread,Jan 6, 2011, 6:58:05 PM1/6/11Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to erlangcamp
So I've been comparing OTP and Scala's respectful plagiarism, trying
to get a grip on the underlying abstractions.
At first, it seemed to me that Scala had gotten the Actors part, but
not the OTP (obviously non-standard libraries like Akka had and still
have more before Scala 2.8). But I realised this was a very naive
interpretation as I worked my way through the various traits and
subclasses.
It looks like Scala was able to capture most of OTP in their traits
(modules/classes) and through subclassing. Maybe this is obvious to
everyone else, and I'm just late to the party.
What that really made me realise was that the OTP gen_x design pattern
is like a Scala trait, which is essentially a Java interface on
steroids (okay, that's so simplistic it almost makes it untrue).
So I see this (naive/simplistic?) mapping of Erlang to OOP:
Process (Actor) : Very heavyweight object (process dict as members,
messages as messages, etc). I know this is not a new observation--a
number of blogs, and for the last couple years Joe Armstrong have been
making that comparison.
Gen_x modules: Traits (sort of interfaces mixed with abstract classes
with more meat)
ETS: Shared heap.
What do other people think? Is this a worthwhile or deceptive road to
go down? What does this give us in thinking about architecture and
design patterns? Can we use this semi-inheritance constructively if
we think about it that way?
BTW, Scala is also copying other languages' features into their
libraries, like channels (Go, Occam, etc) and futures. Pretty sweet.
What they're missing is the amazing pattern matching of Erlang,
especially !!! bitmatching (it seems to me that parser combinators are
a poor replacement), the per-process heaps and resulting memory
locality and reliability, and the distinct binaries memory space
(although I guess you could use the JVM's interned strings memory
structure?). I simply love the way Erlang manages and works with
binaries.
R/
Ed Browne