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

[Raimo Niskanen]

On Wed, Oct 22, 2008 at 05:01:19AM -0700, Steve Davis wrote:
> 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

I am maybe missing a point here, but "the Erlang way" here
is often to assume you get what you expected, run along
and process the data, and when you get something
unexpected, thanks to the strong typing, you will
get a crashed process. And this you take care of by
using OTP supervision trees that handle the error
and restart the task.

The code you see is the code for the correct data flow.

> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB