Need feedback on simple idea

Nathanael Schärli n.schaerli at gmx.net
Sat Apr 12 09:12:47 UTC 2003


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



More information about the Squeak-dev mailing list