Typed Systems, Type Inference, etc

Alejandro F. Reimondo aleReimondo at smalltalking.net
Sun Jul 21 21:01:39 UTC 2002


> >How about using signature revealing variable-names as Panu Viljamaa
suggests?
> >See http://members.fcc.net/panu/SmalltalkTypes.htm .
> >
> >I think it's small and integrates well, though lots of temps/ arguments
> >would have to be renamed.
>
> I'm opposed to this approach.
So do I.

> A variable name is a comment, and I say it should be
> used to indicate role, as in 'total', 'direction', 'methodNames', etc.
ok,
But I think that we do not have "variables".
We only have names for concrete objects.
Objects do not change, they are replaced as an individual. We use the same
name to refer another object, the last named object must not have the same
shape of the previous.
Our assignment expression ( := ) only says that we select a name for
concrete object (not an abstract one, as a variable points to). It is not a
"variation of data in memory".
As smalltalk is not a language (for me) but an Ambient of virtual objects
(as known in holistic and ecology) our activities are not focused on system
definition, but in system construction/"creation"/building from concrete
objects in an evolutionary process.
Then why not to have type information only in inspector and debugger? (as we
currently have). We work on concrete objects and not on "specifications" as
usual in Object Oriented Languages (like Java or C++).
With Smalltalk we have more than a language (and a virtual machine). [*]
I feel that we need more tools to handle concrete instances than to handle
abstract specifications of systems.
We need more tools to "feel" (not only "see") a system and it's emergencies.
If we focus our attention only in objects we are missing the whole.
As a system is more that its parts (Bertalanffy[67]), so we must have to
provide tools for the areas of the system that are not formalized as objects
[yet].

> The eventual goal of SmalltalkTypes is a tool that extracts
> the type signatures from the source-code into a hypertext
> "contract" -document, or into the Smalltalk browser directly
> (E.g., "browse argument types of this method")
Smalltalk systems must be learned by the interaction with it's objects, then
the tool for learning them is the debugger & inspectors, not browsers and
source (the abstractions like frameworks emerges from experience during
interaction with concrete instances [an emergent process]).
Most of the problems I see in development of smalltalk systems are related
to the writing of code and the use of abstractions without a sufficient
experience in its domain (real or virtual). People use smalltalk as a
language to write programs, and not as a support to build objects; then they
only write code and work object ORIENTED; they not build a system using the
Ambient; they specify and abstraction and only use the head (and
formalizations as classes / patterns / contracts / interfaces / etc).
Now, people know how to build components and modules, but they are not
objects. They know how to conform an interface and perform a reductionism
analysis, but they do not know what is missing when they work only with
formalization. Been more formal is not a choice to solve open systems and
Smalltalk is a very good support to learn how to work without producing
premature formalizations.

I understand that type inference is important for the VM...
but, I vote for NOT to use types (only well known names) because the real
problem for us, is not to say what is the type of an abstract entity. The
real problem in the building in an open Ambient is the cost of obtaining
concrete experience in a domain to let the system evolve without loosing
stability (we prefer a stable system, not a "correct/perfect" one; we need
that the virtual system preserve the indeterminations and divergences).
Working considering the Ambient as an open system (Smalltalk as a medium for
concrete objects) the most relevant activities are feeling the objects (not
only "reading them") to sense stability and emergencies (anecdotes, errors,
warnings, surprises) that are the minimum requirements to define the
immediate direction of change in the system.
Cheers,
Ale.
[*] Code panes in Smalltalk has a syntax and this syntax defines a language
(as gestures in scripting with morphs defines another language); but
Smalltalk is the place, "the container" of the objects, not the syntax of
the source.





More information about the Squeak-dev mailing list