CACM Erlang article by Joe Armstrong

http://cacm.acm.org/magazines/2010/9/98014-erlang/fulltext

by angstrom • 16 years ago

42 9 16 years ago

cacm.acm.org

That's a really nice introduction to Erlang and much better than the management cruft that usually fills CACM. Although, I haven't read it for about a year (due to the aforementioned cruft,) is this article indicative of an improvement of the computer science content?

gjm11• 16 years ago

Yes, CACM is less crappy in that respect than it used to be. There's still a fair amount of cruft, though. (Queue has more non-cruft, but it's now online-only.)

sgt• 16 years ago

Dugg.

anonymousDan2• 16 years ago

One of the things he mentions that I found interesting is in relation to Erlang's type system; more specifically, he claims static type checking would have made dynamic code upgrade virtually impossible. Can anyone shed some light on why this is the case, or perhaps give me a reference to a good paper on the topic? From looking at the example he gives it seems to me all you need is first class functions.

alavrik3• 16 years ago

For example, over time you dynamically upgrade a module going from version 1 to 2 and, later, to version 3.

During the first module upgrade, data types from the newer module (2) can be incompatible with the data types from the older module (1).

Such incompatibilities are resolved dynamically during the upgrade procedure (implemented as a part of v2) which knows about type incompatibilities between versions 1 and 2.

After the upgrade from version 1 to 2, any subsequent module versions (e.g. 3) doesn't have to know anything about types from the initial module (1).

anonymousDan2• 16 years ago

So would I be right in saying that to update a function from v1 to v2, in a statically typed language I can't change the function prototype, whereas with a dynamically typed language I can? Would I not still be somewhat limited in the latter case (e.g. I'd have to have the same number of arguments)?

sausagefeet• 16 years ago

Isn't this still a problem in a dynamic language? For example in Erlang let's say my state is the 2-tuple. In version 2 I make it a 3-tuple but it stays the same in version 3 so it has no upgrade code. Consider the same situation with any code where the middle version update adds data to your state.

I'm not sure why being statically typed would make hot code loading impossible. Can't you always interject some transformation function between updates? At the very worse you could have code to serialize your data structure right before update, then another function after the update to deserialize and turn it into the new structure. Am I missing something?

CACM Erlang article by Joe Armstrong

Related Stories