The cadence of Software Engineering.

Alejandro F. Reimondo aleReimondo at sugarweb.com
Sat Dec 19 23:18:13 UTC 1998


Smalltalk is not a language. Smalltalk is a place.

It may take one hour or +ten years to know what a "place" means.
This topic is the most difficult thing to communicate
 in the computing community, because people thinks in terms of
 a language to talk to the computer.

Smalltalk is not a language. Smalltalk is a place.

It may take one hour or +ten years to know what a "place" means.
This topic is the most difficult thing to communicate in the computing community, because people think in terms of a language to talk to the computer.(1)
Smalltalk makes real a new perception of computer, been a place where things are sub-created by a men. (2)

What can be better than Smalltalk?
If Smalltalk is a place with things (an environment with objects)... then a better Smalltalk is a Smalltalk with better objects... :-)

The great work to be done is in the creation of better objects and ways to evolve our environment in a more "natural" way (w/ evolution & selection).
The dilution/missing of the machine & the language is very important to the humman-object relation.
The better operating system is the OS that does not exist. (3)
The better database is the database that does not exist.
What about the better language ?

Holiday greetings to all.
Ale.

(1) the conventional paradigm treats the computer like another human, and the programmer talk to it! In an Object Environment the machine is a place where things are living.
(2) sub-creation understood as the activity of creation been done by humans; as the Creator, but in their imagination. J.R.Tolkien 
(3) please read "not exist" as "is transparent" to human.


----------
De:     	Bill Cattey[SMTP:wdc at MIT.EDU]
Enviado: 	Sábado 19 de Diciembre de 1998 12:56
Para:   	squeak at cs.uiuc.edu
Asunto:     	The cadence of Software Engineering.

Although I have been aware of Smalltalk for a very long time, (I
mentioned it in my Undergraduate Thesis in 1983) I've not been at all
serious in my study of it until I learned about Squeak this past
October.  For the past 15 years, I'd been doing what I'll call
'conventional' software engineering -- taking on multi-month and multi
year projets to get something done.

Reading Dan Ingalls note about the Squeak 2.3 timeline, I suddenly found
myself in a universe with a VERY different sense of how long things take
to do.  As I've chatted with Squeakers over the past couple months, I
understood that my sense of what to do when and how long it took was
different, but it seems that it's much more different than I imagined.

Let's take a moment to savor how Squeak is changing how we think about
what is possible.

-wdc





More information about the Squeak-dev mailing list