My friend and former collegue, David Bergman, has an interesting take on Erlang in his blog: Erlang: the Best or Worst of Two Worlds?
In this article, David discusses Erlang's mertis as a "practical" functional language for building large-scale systems. He also points out a couple of Erlang's aspects that he doesn't like: dynamic typing and lack of currying. Clearly, the first item is the more important.
I'm a big fan of dynamic typing, less from a theortical and more from a practical point of view. I think dynamic typing speeds up development because you can easly execute statements in the shell without previously defining your types. Without dynamic typing, I also don't think I could have created Smerl and ErlyDB -- at least not so easily. At the very least, they would have required the developer to define in compile time the "types" that would be generated in runtime. That's more effort than I would like to make as an ErlyDB user. Still, David brings up some very good points about static typing and I'm not sure that I disagree with him 100% :)
David is the smartest developer (among other things) I know personally and he's the main culprit behind getting me interested in functional languages. His blog is very good. I recommend it to everyone.
7 comments:
Yes, Erlang is cute. But I tried to research about binary input-output and found nothing better than to wrap stdio.h. (The thing I need is a small footprint DB. Erlang was supposed to help out with the BTree traversing etc , plus the promising lightwait tread model. ) Did I miss anything?
Taras, I also agree with David about currying. It should just be added to Erlang. It's so simple. I bet they could add it in a few hours of work. I think the OTP team is trying to keep Erlang's semantics simple, but currying? That's a no brainer :)
Regarding type inference, I have used haXe, which supports static typing (inferred and explicit) as well as dynamic typing, and I found myself almost always sticking to the explicit static typing option. I'm not sure why. It just felt "right." But you bring up an interesting point about Dialyzer: if you autmated your build system to always use Dialyzer, would it fair to say that with Dialyzer, Erlang effectively has type inference?
New Comer -- I'm afraid I'm not an expert on your specific question. I recommend asking the mailing list, as I'm sure you'll get very good answers.
Yariv, you can get similar assurances(but weaker) about your erlang code with Dialyzer. However Erlang is designed a dynamicly typed language, so no matter how much effort is placed into Dialyzer, it would be able to match the compile-time piece of mind that a staticly typed language like OCaml provides.
Dynamic typing is not all bad, it does allow for more flexibility as you don't always have to deal with the type system bondage, so you can express crazy things like eval() which are next to impossible to do as easily in a staticly typed lang.
It's not hard to do eval in a statically typed language, if you just give it a type like String - a, and check at runtime whether the code is actually legal, and evaluating it gave you something of the type you wanted.
My problem with typing in Erlang is not with the dynamic aspect so much as the fact that there isn't any typing at all worth speaking of. For instance, while it is possible to tell the difference between an integer and a string there is no way to discover (at run-time or comple-time) whether the variable passed to a function is a string or a list; in other words the the types in Erlang are fixed, not extensible and heavily overlap. This seems to me to be the worst of all worlds.
(BTW, there seems to be a lot of confusion is over the difference between static typing, dynamic typing and strong typing. The last two are not mutually exclusive, as a lot of people seem to think)
Steve, by my experience with Erlang, if you need to distinguish the type of a parameter passed into a function, you would 'tag' it with an atom. In your example, your function would accept either {string, List} or {people, List}. In a sense, the tag is the Erlang way of indicating the 'type' of the tuple. The main reason I'm a fan of this approach is that it's very friendly to pattern matching. If Erlang had "real" types, pattern matching would be less straightforward I would think.
Post a Comment