In the spirit of rubiquity's post, I'll take a faux supervisor tree and static typing over a "real" supervisor tree (sorry, gotta scare quote it) and faux static typing.
It should be pointed out specifically that Erlang's type system is incredibly, annoyingly weak, more so than merely "weak typing". It's a language that doesn't permit any sort of user-created type whatsoever. There are good reasons for this which would be its own interesting blog post, mostly related to the need for a clear serialization for cluster communication, but I think those good reasons have been superceded by later work in the general programming world on serialization of objects and the tradeoff is wrong in 2014. (But, no sarcasm, a good one when it was created. It is no real criticism of a language to observe that it couldn't use lessons learned only a decade after it was created.)
It's a language that doesn't permit any sort of user-created object whatsoever.
I think you are misusing "object" to mean something like "class" or "type" (the two not really being the same thing except in some statically-typed, class-based, OOPLs); Erlang quite obviously allows user-created objects.
Yes, it should be "type". I've edited it, so let the record show that I did say that at first.
And of course you can use what exists to build "types", such as a dict. But it's still just a record of a certain format rather than a distinct "type"; there's no way in the core system to assert that you have such a "dict", beyond having a record.
Sure, but this isn't all that different than what you get with "tags" (dynamic types) in a dynamically-typed language, even if some of those languages have some construct for runtime type testing (Erlang doesn't, but has pattern matching which seems to provide more than dynamtic-type-testing-specific functionality would.)
If the complaint is just Erlang-lacks-static-typing, I can agree that that's a fact, but I don't see how what Erlang does give you is less useful (even though the particular structure is different) than what you get in other languages that lack static typing.
"but I don't see how what Erlang does give you is less useful (even though the particular structure is different) than what you get in other languages that lack static typing."
Well, this gets into quasi-religious debates about type systems. All I can really do is point you to the Python or Ruby class systems and ask you to compare it to Erlang. And also observe that I'm pretty tired of dynamic typing in general, and Erlang is even farther in the direction that I'm tired of than Python/Ruby/etc.
Erlang has static types, they're just (a) always open and (b) always optional. It's more or less the most dynamic static typing regime imaginable. In personal use, it's highly valuable from a documentation standpoint, but does almost nothing for safety or restricting abuse of power.
Comments
In the spirit of rubiquity's post, I'll take a faux supervisor tree and static typing over a "real" supervisor tree (sorry, gotta scare quote it) and faux static typing.
It should be pointed out specifically that Erlang's type system is incredibly, annoyingly weak, more so than merely "weak typing". It's a language that doesn't permit any sort of user-created type whatsoever. There are good reasons for this which would be its own interesting blog post, mostly related to the need for a clear serialization for cluster communication, but I think those good reasons have been superceded by later work in the general programming world on serialization of objects and the tradeoff is wrong in 2014. (But, no sarcasm, a good one when it was created. It is no real criticism of a language to observe that it couldn't use lessons learned only a decade after it was created.)
I think you are misusing "object" to mean something like "class" or "type" (the two not really being the same thing except in some statically-typed, class-based, OOPLs); Erlang quite obviously allows user-created objects.
Yes, it should be "type". I've edited it, so let the record show that I did say that at first.
And of course you can use what exists to build "types", such as a dict. But it's still just a record of a certain format rather than a distinct "type"; there's no way in the core system to assert that you have such a "dict", beyond having a record.
Sure, but this isn't all that different than what you get with "tags" (dynamic types) in a dynamically-typed language, even if some of those languages have some construct for runtime type testing (Erlang doesn't, but has pattern matching which seems to provide more than dynamtic-type-testing-specific functionality would.)
If the complaint is just Erlang-lacks-static-typing, I can agree that that's a fact, but I don't see how what Erlang does give you is less useful (even though the particular structure is different) than what you get in other languages that lack static typing.
"but I don't see how what Erlang does give you is less useful (even though the particular structure is different) than what you get in other languages that lack static typing."
Well, this gets into quasi-religious debates about type systems. All I can really do is point you to the Python or Ruby class systems and ask you to compare it to Erlang. And also observe that I'm pretty tired of dynamic typing in general, and Erlang is even farther in the direction that I'm tired of than Python/Ruby/etc.
Erlang has static types, they're just (a) always open and (b) always optional. It's more or less the most dynamic static typing regime imaginable. In personal use, it's highly valuable from a documentation standpoint, but does almost nothing for safety or restricting abuse of power.
Here's a recent Erlang type annoyance:
Given two tuples with 3 integers, {X, Y, Z}, without knowing it a priori, you can't tell which one is an erlang:now() and which is an erlang:date().