Couple of key points I’ve gleaned about Erlang as a language; first, concurrency isn’t just something it does well, it defines its overall approach to problem solving. Whereas languages like Smalltalk and Java do things by designing objects and systems of interrelated objects, Erlang breaks a problem into concurrent processes and systems of interrelated processes. So some design patterns and refactoring patterns from the Java world for instance, won’t always have a directly corresponding pattern or refactoring strategy in Erlang, BUT I think the more general principals can still be applied in at least most cases.

Tim Watson does a good job explaining how Erlang’s dynamic types are similar to dynamic types in Perl or Ruby, and also how they can be used to support a sort of polymorphism. I won’t add much here, except to say that I really like the dynamic type approach as opposed to strong static data types and all kinds of type checking.

One benefit of Erlang’s concurrency orientation is that it really promotes short functions that are very tightly cohesive, and loosely coupled with other processes. This means that each function should and typically is designed to do just one very specific job, not several; that the interface between processes is explicit, and consists just of what messages they can send and receive; consequently a process generally can’t know or depend on how another process is implemented, just on the process’ API, namely what messages it sends and receives. These things promote good software design in different ways, and while I’m still learning, I strongly suspect at this point that they’ll tend to make up for any weaknesses due to not being object oriented.

Share this: Twitter

Facebook

Like this: Like Loading... Related