[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Erlang type system and static vs. dynamic types

I was referring to application-level boundaries and modules.  Such
boundaries typically fall along the module lines of the type system,
but the converse is not always true.  I had in a mind a module as a
unit of a program that is written and maintained by one person or as
one component of a system.  More like apache modules rather than
java packages.

In my comment about such module systems being more important I meant
that I would prefer a system that makes it easy to divide an
application into pieces with a clean boundary between them.
Sometimes this is accomplished in the type system, but sometimes
another abstraction is added (like in apache or the linux kernel
where C doesn't provide anything suitable).  I'm quite enchanted by
the way Erlang makes it easy to divide a process into threads and
easily migrate them to other machines with the same semantics.  RMI
in Java fails at this (because of copy-by-value) or you pay a
significant performance hit when you emulate the RMI semantics in a
local process.  EJBs have similar issues.

I think it's often a good rule of thumb when defining the API of a
component to assume that it will live on a different machine than
the rest of the system and make sure that the API is not cluttered
with lots of local state being passed around unnecessarily.  I
wonder if any benefits would be realized by actually developing an
application that way and then moving all the pieces onto the same
machine for deployment (hopefully with a system that can
automatically exploit shared memory, etc.).

- Russ

On Sat, May 03, 2003 at 05:55:24PM -0700, Steve Dekorte wrote:
> Could you please define what you mean by "abstraction boundaries" and 
> "module systems"? I know of a number of ways in which these terms are 
> used and most are either unrelated too or suffer when used with static 
> typing.