[erlang-questions] Why isn't erlang strongly typed?

[Steve Davis]

Thanks for all the comments -- I really appreciate the quality of
these responses!

I am now receiving the following message: There isn't a simple answer.

I guess if I accept Ulf's definition of strongly typed, then it's true
that Erlang is "strongly typed", and mea culpa for using terminology
that's known to be ambiguous, but I wasn't sure that confining the
question to "statically typed" was the accurate way to phrase my query
or to elicit a useful answer/discussion.

I can see from reading Gleb and Robert's answers there would be issues
with hot code loading, and also with selective receive as Jason
pointed out. However, it seems that perhaps even these language design
issues were not insurmountable (see Michael's post and also Richard/
Joe's comments).

However, the fact remains that Erlang does essentially leave a library
user in the dark at code level, since functions may return any data
type at all depending on their arguments. When you are designing your
pattern matches to extract/unpack/*use* return values it becomes
onerous whenever the data type is non-trivial. Of course feeding in
the "right" arguments bring similar issues of how to package them
correctly. I tend to get lost quite quickly in the ream of balanced
separators required (maybe that's just me). Yes, records do help
here... perhaps they are the "right" answer, and should be more widely
encouraged.

With well documented libraries you have "spec" of course, but spec is
essentially pseudocode that shores up the (inevitable?) lack of static
typing in the code. As a result it's harder to read and breaks the
flow as it takes you away from your code for too long. Perhaps more
problematically, it takes a good deal of work to write a spec, so you
can guarantee that 99.9% of library developers will avoid doing it if
they can. Case in point - for some the the most popular and useful
third party libraries, a familiar example would be "mochiweb", there's
almost zero documentation. I suspect another reason is that it's
almost as easy to read the code as it is to read the spec - in simpler
cases it is actually *easier* to read the code than read a spec.

All in all, pushing structured data around in Erlang takes a lot more
care and thinking time than it could otherwise if there were better
support for data structures in Erlang. Of course the issue here is
what the word "better" would mean... blindly including constraints
could easily mean throwing out the baby with the bathwater.

I think I'm now resigned to the fact that this issue is not one that
Erlang does solve or will solve. Perhaps whatever language that
evolves from Erlang in the future will do so. Meantime... guess I will
just have to accept the world for what it is. It's one of the
sacrifices that must be made to get access to the enormous and
fundamental benefits of the Erlang/OTP platform.

/s