But Erlang itself? It's too weird, and in my brief experiments, the implementation shows its age; we have in fact learned some things about software since way back then.
--Tim Bray, Prognostication
I'm just quite new to Erlang and read through Chapter 10 of Programming Erlang so far. The language really expand my mind greatly, with its pattern-matching capability (even for a Haskell user), and of course concurrency oriented programming. Inter-process communication, even across different machines, is a quite simple task in Erlang. However, as stated by Tim Bray, Erlang is too weird. In the following, I will list some weird things I met when studying Erlang. The focus is mainly on syntax, which seems to be non-essential but should have been easily improved (if backward compatibility is not an issue).
Usage of punctuation
A newcomer to Erlang will almost forget to type period after an expression one or more times. Why do we need such punctuation even in an interactive shell? I admit that using period, semicolon and comma in Emacs makes source editing more automatic, but I prefer not using them at all. Erlang should learn something from the elegance of Haskell in this aspect.
Awkward functional programming with fun
There is no fun when using fun. When writing an anonymous
function, one have to use fun and append
end. Even when calling a named function within a higher
order function, one has to use fun like this
lists:map(fun math:sqrt/1, [1.0, 2.0, 3.0]). This is
awkward and Haskell way is way better again.
Handling Records
Although records are tuples in disguise, they are treated in a C-style way: i.e. if one record definition is to be used by multiple source files, it has to be put into an include file. Weird.
Macro
Fans of C/C++ may applaud when they learn that Erlang provided similar macro facilities. However it is doubtful whether this controversial feature is needed for such a functional programming language.
Makefile
Again advocates of C/C++ might be pleased to know that Erlang also relies on makefile for package management/build. Shed by the light of Haskell/Cabal, Common Lisp/ASDF or X/Y (put your favorite language and package management system here), one may expect that Erlang has a more modern way?
Conclusion
Apparently, above weird aspects are not show-stopper for the popularity of Erlang. However, appreciating the Ruby principle of Least Surprise, I cannot help but rant my impressions gathered when climbing the mind-blown-away learning curve.
Posts
My personal experience is that you quickly go over the weirdness of the syntax. After a while you actually start to like it. Punctuation for instance actually helps to remove a bunch of typing mistakes at compilation time.
ReplyDeleteBy the way, Erlang syntax is naturally (see Erlang history) closed to Prolog.
Compared with other languages (Ruby, Smalltalk, Haskell, Scala, ML, Lisp, Oz), I found Erlang one of the easiest to learn (but I guess it depends on how many languages you have jumped upon before Erlang).
My sole concern about the syntax is the fact that communication protocol (what kind of messages processes expect from each others) might not be explicit enough. You might have to dig into the source to know which messages are valid. I don't have enough practical experience with the language to know if this is a real issue.
Learning new languages is really interesting. Personally I believe Java verbosity for instance is much more a problem than Erlang syntax weirdness ...
Pierre: thanks for your encouraging comments. When I learned Erlang, I just compared it with Haskell (due to the similarity in syntax), and felt that Haskell syntax is somehow more succinct (that is the rationale behind complaint #1 and #2).
ReplyDeleteWhen I first met Lisp (actually Emacs Lisp), I felt that the parentheses are really absurd. But I soon liked them. I guess this will sure happen for Erlang too.
The reason for the "fun" is that without it the name of the function you are specifying will be interpreted as a standard atom. In Erlang an atom literal is used to store "names" and since the atom can refer to a function, a process, a module, or just be an atom it is harder to distinguish among the various usages (unlike Haskell, which uses a variable to store a function.) The explicit use of fun makes the parser's job easier but it has a cost in the syntax (yeah, it sometimes bothers me too, but like the other syntax bits you eventually get over it...)
ReplyDelete