"The limits of my language mean the limits of my world." -- Ludwig Wittgenstein
I've started looking at Erlang a bit. Erlang is a functional programming language that is very unlike the imperative languages which I, and many others, are most familiar. Learning a new programming language and especially a fundamentally new programming paradigm really changes the way you think about solving problems. If the linguists are to be believed, it fundamentally allows you to have no thoughts and ideas. This is what makes it so valuable for software developers to look at new languages. I thought I would share some tidbits.
Erlang Variables Aren't VariableErlang only allows you to set the value of a "variable" once. If you try to set it more than once the language actually throws an error.
At first this sounds like a huge limitation to my imperative mind. In many imperative it probably would be. In Erlang it ends up not being much of an issue. In many ways it's one of the things that forces you do more idiomatic, functional Erlang.
Side Effect FreeNot being able to modify variables is one of the things that helps keep Erlang programs side effect free. Side Effects make programs harder to understand and can make them more error prone. A side effect free method is one that is "idempotent", a fancy term that means every time you call it with a given value, it will return the same result.
Thinking of side effects and how they can be reduced or removed from imperative programs can make those programs easier to understand and test.
Pattern Matching as PolymorphismTo my imperative brain that grew up mostly on Object Oriented programming languages Polymorphism and related abstraction are notions of classes and types. Erlang changes this abstraction into one of Pattern Matching. Erlang's pattern matching is almost a declarative construct like you would find in XSL. When you find call to a function that matches this pattern, use it, otherwise try the next function until you find one that matches.
To compute a Factorial, you can use 2 function signatures. The first *fac(0)* is called whenever the function is called with the integer value of zero. If the value is not zero, then that pattern is not matched and the next version is tried. In that case *fac(N)* where N is any value other than 0 is evaluated.
In a slightly more complex example, you can actually pass a keyed Tuple. The key, in Erlang speak, is an atom, very similar to a Ruby symbol. Those atoms are used as part of the pattern matching to determine which function to execute.
Thinking about abstractions beyond types or classes in your Object Oriented programs could open you to some interesting new solutions
Distribution Should be Explicit, Not Necessarily HardDistributed computing takes more work than assuming all your code will be running on a singe machine, in the same process. The Fallacies of Distributed Computing are all about the assumptions we make when we try and hide the complexity of distribution from the caller. With Java and .NET, for example, remote calls can become so hidden that they look like just another method call within the local VM. While this is convenient, it also can lead to serious problems when users don't take into account the overhead and the extra things that can go wrong with remote calls.
Erlang makes concurrent programming and spawning lots of processes to do work a very natural part of the language. Part of the language then is how to deal with the problems that arise when you run into issues talking to a remote process. The language has exception handling, it can be set up to receive a response, only wait for a timeout, etc.
The biggest thing that Erlang does is not try to hide the fact that you are communicating to a remote process (whether that process is in the same node, a different node, or a different machine). It gives you the programmer the tools to decide what conditions you need to handle based on how your program is built and deployed. All those scenarios are easy, but it's still explicit that you are talking to a different process.
Think about how you can make your distribution explicit and not hidden from callers who could make bad assumptions.
I'm finding Erlang and really trying to think in a functional programming language very interesting right now, so I'll probably post some more about it. I think it will allow me to talk more intelligently to Grant at least.