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

[Steve Davis]

On Nov 4, 1:38 pm, "Holger Hoffstaette" <hol...@REDACTED> wrote:
> On Tue, 04 Nov 2008 10:31:05 -0800, Steve Davis wrote:
> > On Nov 4, 10:04 am, Isaac Gouy <igo...@REDACTED> wrote:
> >> On Thu Oct 23 02:04:47 CEST 2008, Richard O'Keefe wrote: -snip-
>
> >> Traits?
>
> >>http://www.iam.unibe.ch/~scg/Research/Traits/
>
> > Very interesting document. My take on this is that OOP seems to be
> > struggling against its own dictum that "everything is an object that has
> > methods that define its behavior". [..]
>
> That's not caused by methods per se but by Smalltalk's single-inheritance
> nature and the concept of identity.

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...

> IIRC Self had none of the problems
> of Traits (remember they were just tacked on). Similarly, functional
> re-composition via AOP works very well even in Java, and allows introduced
> behaviour to bring its own state.

"Prefer composition over inheritance" is a useful guideline, true. But
AOP uses bytecode injection, correct? Does bytecode manipulation not
also imply that it's providing support for an inadequate language
concept(s)?

> 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. A case in point would be Erlang (either
that, or I misunderstood your last point).

/s