Hi Nathanael,

> > Simplicity through reduction is irrelevant.
> > If we obtain simplicity at the cost of loosing diversity of
> > expression or loosing differentiation of culture accepted
> > elements, we imho are going in the wrong direction.
>
> If this is the case, modern programming languages such as ST, Squeak,
> C#, Java, etc. are all irrelevant! Just think, there are tons of
> previously well accepted concepts in C and C++ that are reduced away in
> all these languages:

I may say that advances in all OOLanguages are irrelevant
under Object Technology because they are only object ORIENTED. [*]
Squeak is an Smalltalk, and it is not only an OOL.
Squeak is different from C#, Java, because it is a medium
to handle complexity (a virtual medium, not a language).
Self and Smalltalk was environments used in the last decades,
but now, Smalltalk is the only OE used commercially.
[*] As OOL you can only use declarative expressions and formal objects.

> - Pointers
> - Multiple inheritance
> - Virtual inheritance
> - Explicit memory managment
> - etc.
All this topics are irrelevant under Object Technology
and under the use of Object Environments to solve real
world problems.
Object Technology (Object Environments as a medium)
let us work with objects and with its emergents. It let us
work without defining what/how the things are/work
and also work object oriented (reducing the problems
to mere objects and declarations of it's interaction
through messages).
The use of computers and declarative languages is only
one alternative of work to apply Object Technology.

> Yes, and ST even achieved a lot more simplicity by getting rid of types,
> encapsulation, mathematically correct precedence rules, etc.
Smalltalk is an environment where you can manage complexity.
The important point (for me) is to handle complexity not simplicity.
I may say "for me", because we must have present that provably Smalltalk is
used under a huge number of points of view (and it reveals the possibility
to handle complexity).
For example, to express al the elements in an environment as objects (e.g.
behavior as an object!) can be interesting for someone that want to "define"
the virtual world describing all its parts; but it is irrelevant for someone
that understand that an ambient is not a container.
It does not minimize the value of the study of any person, :-)
it only defines it's point of view.

> Are you really saying that the simplicity achieved by Smalltalk is
> irrelevant because Alan reduced (i.e., unified and abandoned) a lot of
> the diversity/complexity of earlier programming languages?? Similarly,
I think that Smalltalk is an Ambient obtained by many persons that
collaborate in the building on a medium (the syntax was important in the
´70s, now we can start to think not only in formal specifications and start
to think in "building/working activities in an environment"). The idea has
changed during the last 30 years. Most of the topics specified in the Dan H.
Ingalls paper about "Design Principles Behind Smalltalk" remain there (in
the smalltalk environment) but, I think that has been more contributions to
OT and works in Ambience (real ambient, not only "virtual" ambient
constrained to computer programs), and we must review how they can be
injected in our Smalltalk to be used not only for specification of programs.

> is the simplicity of Java and C# over C++ irrelevant because the
> developers reduced and unified a lot of the diversity/complexity of
> these languages??
The problem is not what they write/code, the problem
are the effects of running the code.
An environment let you feel what are you doing with your hands.
A language only let you think that you are thinking ok (no feedback on the
effects of your definition or its instantiation in a context/medium).

> I guess you are then one of the people who is really sad about the
> diversity of expression we lost in all these modern programming
> languages. How terrible that we can't express type casts and "pointers
> to pointers" in ST. And even worse, this eval thing called garbage
> collector even takes away the joy of deleting unused objects from the
> ST/Java programmers! Isn't it barbaric to loose all of this wonderful
> diversity just to achieve irrelevant simplicity?
Oops! No I am not so innocent.
One thing is diversity and other different thing is garbage.
The difference is not contained in the objects, it is contained
in what you can do with them.

> Now, please tell me why you are at all using Squeak? Regarding your
Because Squeak (as any Smalltalk environment) can be used to manage
complexity and build open information systems using evolution (not only
change in it's definition).
Under this point of view simplicity is only a curiosity and most of the time
reveals the application of reductionism to build an abstraction that have
less information value and more instantiation cost.
For example to say that "behavior is an object" (so it can be defined by an
expression)
is a simplification (a reduction) and is valid for teaching objects but if
you really think that behavior can be encapsulated it reveals that use only
Cartesian theory.

> quote, I would really have expected you to be a die-hard C, C++ fan who
> loves to use all this diversity of expression that got unfortunately
> reduced in these evil higher-level languages. Finally, virtuall all the
> simplicity of these languages is irrelevant because achieved through
> reduction.
In the last 15years I have used Smalltalks during more than 6 days a week,
and in the same time I have not written more than 1000 lines of C++ code.
It takes me more than 5 years to know what an Ambient is and to understand
that is not anObject (most Smalltalkers think that the Ambient is
aSystemDictionary... we must work hard to teach what an Ambient is, because
most Smalltalkers feel that it is an object).
Also takes me more than 7 years of work embedded in the environment to know
that it is not it's definition nor all the objects it contains.
If you say "Smalltalk is a place full of objects" it is true and didactical,
but it is not enough because people think that anAmbient is aContainer...
then can be reduced to anObject and be managed as any object...
As anEnvironment is not it objects, nor the code that describe them; I think
that the "great advances in OOLanguages" are irrelevant.
I can mention some studies on Ambients in the real world, but they are in
Spanish :-(
They are in Spanish because they are written for Latin-American people that
are involved in Ambiental problems where we can help (my feeling) with our
Object Technology.
They are not constrained to computers, their work are related to real object
systems (teaching and social effects of reductions and formalizations on
people and it's training).
For the interested people that can read Spanish, the papers can be found at
http://www.smalltalking.net/Papers/Educación%20en%20Ambiente/index.htm
I am interested in the use of an object environment to know
how to work with more that objects.
You can see the page about schooling and emergent behavior
to see an example of emergent behavior without defining it.
Studies like this or others about obtaining "behavior"
without defining it are interesting for me.
http://www.smalltalking.net/Goodies/VisualSmalltalk/Files/Genesis3D/Boids.ht
m
And are interested if applied in virtual or real worlds.
More links on development without reductionism:
(Gordon Pask works are dated on 1950)
http://homepage.mac.com/cariani/CarianiWebsite/PaskDevice93.pdf
http://www.pangaro.com/CCS/CCS-History/CCS-Cariani-Ear.html

> I'm glad that there have always been and still are innovative people who
> don't seem to agree to what you said.
I have seen "innovative people" doing things because
they feel clever, but they was not here when the
effects can be observed.
>Otherwise, we would probably only
> have programming languages that would consist of tons of accumulated
> diversity that noone wants to unify/reduce/abandon/improve just because
> they don't want to sacrifice all this wonderful cultural heritage.
>
> What a wonderful world this would be...
This is the other side of the same coin.
I do not say that you must not use reductionism.
A good idea is a good idea, but it is different of the result of its
instantiation.
If you want to eliminate instance variables, and think that only messages
are required; ok, eliminate them in your smalltalk; feel what happens with
10-100 people producing systems using this smalltalk in some projects and
then share it with us.
But you can't ask us if it will be better for us, because we (and you) can't
know it in advance.
If there are elements of reduction present in Self that has not been adopted
in the last decades, it can be interesting to study why they has not been
survived during time and what was the emergencies of this kind reduction.
Any investigation considering evolution must start on the history of similar
environments.
I think you have Self as the most similar environment where this approach
has been applied (consider the effects of the idea of eliminating i.v. on
Self and it's people and about what they think about behavior and state).
The emergence of a reduction must be analyzed in relation with the
destination environment (the virtual OE and the people interacting with it,
because the image is not the objects limit), so you must apply the changes
to a local community to show the effects of applying the change to smalltalk
and how the change *really* do the life better for an Smalltalker, now in
the 2000's and not in the '80s.
Simplicity is not enough, the evaluation of effects must be considered.

cheers,
Ale.


----- Original Message -----
From: "Nathanael Schärli" <n.schaerli at gmx.net>
To: "'The general-purpose Squeak developers list'"
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, April 12, 2003 6:12 AM
Subject: RE: Need feedback on simple idea


> Alejandro,
>
> > Simplicity through reduction is irrelevant.
> > If we obtain simplicity at the cost of loosing diversity of
> > expression or loosing differentiation of culture accepted
> > elements, we imho are going in the wrong direction.
>
> If this is the case, modern programming languages such as ST, Squeak,
> C#, Java, etc. are all irrelevant! Just think, there are tons of
> previously well accepted concepts in C and C++ that are reduced away in
> all these languages:
>
> - Pointers
> - Multiple inheritance
> - Virtual inheritance
> - Explicit memory managment
> - etc.
>
> Yes, and ST even achieved a lot more simplicty by getting rid of types,
> encapsulation, mathematically correct precedence rules, etc.
>
> Are you really saying that the simplicity achieved by Smalltalk is
> irrelevant because Alan reduced (i.e., unified and abandoned) a lot of
> the diversity/complexity of earlier programming languages?? Similarly,
> is the simplicity of Java and C# over C++ irrelevant because the
> developers reduced and unified a lot of the diversity/complexity of
> these languages??
>
> I guess you are then one of the people who is really sad about the
> diversity of expression we lost in all these modern programming
> languages. How terrible that we can't express type casts and "pointers
> to pointers" in ST. And even worse, this eval thing called garbage
> collector even takes away the joy of deleting unused objects from the
> ST/Java programmers! Isn't it barbaric to loose all of this wonderful
> diversity just to achieve irrelevant simplicity?
>
> Now, please tell me why you are at all using Squeak? Regarding your
> quote, I would really have expected you to be a die-hard C, C++ fan who
> loves to use all this diversity of expression that got unfortunately
> reduced in these evil higher-level languages. Finally, virtuall all the
> simplicity of these languages is irrelevant because achieved through
> reduction.
>
> I'm glad that there have always been and still are innovative people who
> don't seem to agree to what you said. Otherwise, we would probably only
> have programming languages that would consist of tons of accumulated
> diversity that noone wants to unify/reduce/abandon/improve just because
> they don't want to sacrifice all this wonderful cultural heritage.
>
> What a wonderful world this would be...
>
> Nathanael
>
>
> > -----Original Message-----
> > From: squeak-dev-bounces at lists.squeakfoundation.org
> > [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
> > Behalf Of Alejandro F. Reimondo
> > Sent: Freitag, 11. April 2003 23:37
> > To: The general-purpose Squeak developers list
> > Cc: Smalltalking Worldwide
> > Subject: Re: Need feedback on simple idea
> >
> >
> > Nathanael,
> >
> > > > It shows, though, that it's possible to have a very
> > > > simple rule that would give us the same kind of privacy
> > as we have
> > > > for our instance variables right now.
> > >
> > > I absolutely agree with you. The main goal is to have a *simple* and
> > > *uniform* mechanism that addresses the dynamic nature of Smalltalk.
> >
> > Simplicity through reduction is irrelevant.
> > If we obtain simplicity at the cost of loosing diversity of
> > expression or loosing differentiation of culture accepted
> > elements, we imho are going in the wrong direction. Object
> > technology must evolve to handle complexity, like non
> > reductionistic approaches in Ecology and other Ambient
> > related disciplines; not in decomposition of atomic/simple
> > elements like in Physics or other hard sciences constrained
> > to reductionism. So, I think it is more convenient to learn
> > from experiences in holistic approaches and try to move our
> > object environment to be used not only Object Oriented
> > (formal, simple and clever definitions) e.g. be used not only
> > by reduction of things to objects. Simplicity, complexity and
> > beauty only defines a point of view and reveal culture
> > constrains that we can't evade. I feel the elimination of a
> > concept commonly accepted in the community like a missing of
> > difference, a loose in diversity. A term exist not only by
> > it's observed use. It exist to differentiate from the others
> > and the difference is not reducible nor merged in an abstract
> > concept without loosing something in the process ;-) For
> > example, I see that is a common practice in Squeak not to
> > comment accessors... I comment all the messages. YES! ALL the
> > messages. Because I have learned to get the value of the
> > times "spent" in commenting messages (also when stupid
> > methods implements the message). Most the time I see that
> > people want to produce software at top speed... They think
> > that they waste their time if they must wait... [*] If you
> > learn how to get value from building software objects at your
> > "normal" speed, the stress is reduced and software become
> > more understandable. One of our main topics, I think, is to
> > obtain a medium to build software at normal/human rate. I do
> > not mean that we must insert delays in the browser nor in the
> > compiler (to be similar to C++ compilers+linkers) ;-) I mean
> > that we must consider the time that take a human to
> > "understand" what their hands are doing... cheers, Ale. [*]
> > typing speed is not important to build better software.
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Nathanael Schärli" <n.schaerli at gmx.net>
> > To: "'The general-purpose Squeak developers list'"
> > <squeak-dev at lists.squeakfoundation.org>
> > Sent: Friday, April 11, 2003 5:22 PM
> > Subject: RE: Need feedback on simple idea
> >
> >
> > > Adam,
> > >
> > > > It shows, though, that it's possible to have a very
> > > > simple rule that would give us the same kind of privacy
> > as we have
> > > > for our instance variables right now.
> > >
> > > I absolutely agree with you. The main goal is to have a *simple* and
> > > *uniform* mechanism that addresses the dynamic nature of Smalltalk.
> > >
> > > - Simple means that it should be easy to use and understand.
> > >
> > > - Uniform means that it should be applicable to both state and
> > > behavior. As I pointed out in my earlier post, it's not
> > worth anything
> > > if we have a mechanism that only allows one to declare encapsulated
> > > state, but not encapsulated methods. And because I don't
> > like the idea
> > > of having different encapsulation mechanisms for methods
> > and state, I
> > > suggest a uniform mechanism.
> > >
> > > > I'd really like to hear more about Nathanael's idea.
> > >
> > > I'll post more about that as soon as I have some more time
> > to really
> > > work on this (probably in a couple weeks). Then, I'll also be very
> > > interested in hearing more opinions and comments from the list.
> > > Finally, ideas are not born perfect ;)
> > >
> > > Thanks,
> > > Nathanael
> > >
> > >
> > > > -----Original Message-----
> > > > From: squeak-dev-bounces at lists.squeakfoundation.org
> > > > [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
> > Behalf Of
> > > > Adam Spitz
> > > > Sent: Freitag, 11. April 2003 18:02
> > > > To: The general-purpose Squeak developers list
> > > > Subject: Re: Need feedback on simple idea
> > > >
> > > >
> > > > Tim Rowledge wrote:
> > > >
> > > > > On a more practical point, the idea of using self-like
> > messages to
> > > > > define instance variables would be acceptable IFF those
> > > > messages were
> > > > > properly private. In order to provide this privacy one
> > > > would need to
> > > > > implement some mechanism to allow properly private methods
> > > > and the same
> > > > > mechanism would (very likely) solve the worries about overly
> > > > > public methods already in the system. I'd be quite happy to see
> > > > such a privacy
> > > > > mechanism if anyone has good ideas.
> > > >
> > > > I don't have any *good* ideas. :) But here's what someone
> > else did:
> > > >
> > > > The Ruby language allows "self" to be left out when it's the
> > > > receiver (just as Java and Self do). Ruby also has a
> > simple privacy
> > > > mechanism: you can mark a method as being private, and private
> > > > methods can only be accessed by messages sent using the "implicit
> > > > self" syntax. (Is that right? My Ruby is rusty.)
> > > >
> > > > It's an ugly hack in a lot of ways, and I don't really
> > mean it as a
> > > > serious suggestion. (I'd really like to hear more about
> > Nathanael's
> > > > idea.) It shows, though, that it's possible to have a very
> > > > simple rule that would give us the same kind of privacy as we
> > > > have for our instance variables right now.
> > > >
> > > >
> > > > Adam Spitz
> > > >
> > >
> > >
> > >
> >
> >
>
>