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

[Richard O'Keefe]

On 5 Nov 2008, at 9:38 am, Steve Davis wrote:
> I'm not that familiar with Smalltalk but I understand that single
> inheritance and entity concepts in Java were influenced heavily by
> Smalltalk - in which case I'd have to disagree. Interfaces were the
> original "solution" (among other things, to make up for lack of
> multiple inheritance) but led to massive code repetition. Mixins were
> then tried as extensions of decorators but have their own "diamond of
> death" style issues. Traits seem to be another attempt that
> importantly *disallow access to state*. Hence my comments...

Traits don't disallow access to state.
They disallow *direct* access to state.
They can use as much state as they want,
provided they do so by calling methods from the
class they are extending.

The idea is "single inheritance for state, multiple
inheritance for behaviour".

Lisp mixins were around long before Java was dreamed
of; did Java-style interfaces come from some earlier
language?  (I used to wonder how Java could possibly
make interfaces efficient.  Then I did some benchmarking
and stopping wondering: it doesn't.)
>

> "Prefer composition over inheritance" is a useful guideline, true. But
> AOP uses bytecode injection, correct?

There's no reason why AOP can't use source weaving.

>> Does a representation of a function have identity? If so, does that  
>> make
>> it an object? :)
>
> Um... define "object" in this context. My answer is yes to the first
> and no to the second (representational entities, in my book, don't
> have to mean these should influence language entities or be allowed to
> constrain its expressiveness

It's traditional in Lisp-family languages that don't have OO already
to emulate objects with closures.  (See the "T" book.)  That's
because variables in a Lispy closure are mutable, unlike those in
Erlang funs.  Identity, (mutable) state, behaviour: that's the OO
trinity and closures have them all.