I haven't started writing my erlang inverted index yet, since I'm still reading the copious documentation. I'm planning to make my inverted index be a process, and internally it will use either ets, dets, or mnesia to store the actual inverted index data.
Since I come from an OO background, I immediately noticed that ets, dets, and mnesia all presented roughly the same API. However erlang requires that all function calls be prefixed by their module, so I can't just write lookup(MyIdx, Key). Instead I have to write ets:lookup(MyIdx, Key), or mnesia:lookup(MyIdx, Key). This seems really unfortunate to me. Yes, it improves readability because there is no indirection involved, but it also decreases maintainability because if I want to switch from one implementation to another, I have to modify every function call.
I had been expecting something more along the lines of Ruby's "duck typing", especially since Erlang is dynamically typed. I can of course simulate the effect by using what Erlang calls "funs", but that would be against the Erlang mindset, and it's clunky to pass around multiple funs.
Apparently the "real" way to do polymorphism in Erlang is at the process interface level. However this begs the question of why there's a distinction between values versus processes, and messages versus functions. I suppose Smalltalk wins here for being more consistent; in Smalltalk, there is no distinction between these things (although Smalltalk objects aren't asynchronous the way Erlang processes are).
I want to point out that I think I do understand the "Erlang way" of doing polymorphism via processes. That's why I intend to make the inverted index a process (although I'm wondering about the performance overhead of passing long lists between processes). The problem that I'm running into is that the Erlang libraries are not designed to be polymorphic. The libraries use functions instead of messages, and so they lose in this respect. I assume that the reason for this is due to performance overhead.
It's not until you find yourself in a language without inheritance, type classes, or multimethods (all of which attempt to provide basically the same feature) that you realize how nice they are. On the other hand, other people have gone through the same learning process I'm going through now, and discovered at the end that they didn't miss polymorphism.
WikiWiki has a discussion of polymorphism in Erlang, as does the Erlang wiki.
Posted on May 24, 2003 07:30 PM
More languages articles
The cost of passing a large list in erlang is barly anything. Since all objects are immutable there is no need to copy it. Processes are values, a pid as far as any process is concerned and it has 1 function call, send. All you are sending is data objects to a process. You never explicitly call a function in another process, you send it data telling it what function you wish to execute.
Posted by: orbitz at February 8, 2005 04:26 PMets, dets, etc. are just atoms. You should be able to do
M = ets,
M:lookup(MyIdx, Key)
Eshell V5.4.12 (abort with ^G)
1> M = timer.
timer
3> M:now_diff(erlang:now(), erlang:now()).
-13
Ah! That's much nicer, and it makes perfect sense. I wonder why none of the links I found when I was looking into this issue mentioned you could do that.
Posted by: Kim at January 13, 2006 03:35 PMerlang uses 'behaviour' as its proxy for polymorphism. You pass in the atom representing a module when you make an instance of a process. As long as the interfaces are the same you can use interchangeable modules. No inheritance, but runtime swappable instantiation. Sort of like making an instance of an object factory.
As to the no copying of data, as soon as you move to distributed nodes on multiple machines it will of course have to copy. But one node on one machine lets you think about processes as if they are data structures. Don't worry about the performance until it is a problem. If you use a multi-core CPU you will get a nice boost.