Cool
I will apply that...

On 17 mai 06, at 13:16, Ralph Johnson wrote:

> The Smalltalk environment is optimized for browsing and reading, not
> for writing.  It assumes that the author of the code didn't know how
> you are going to reuse the code, so it provides ways of searching and
> analyzing rather than ways of organizing.
>
> As an author, sometimes I wish that I could organize my code into a
> linear structure that forced the reader to follow along in a certain
> order.  But when I am reusing someone else's framework, I often know
> that I am going slightly against the authors plans.  If we provide a
> way to give a more linear narrative, we need to avoid losing the
> ability to browse and analyze.  There have been several Smalltalk
> "literate programming" tools in the past that let people create a
> narrative that was a layer above the browser.  A "literate program"
> was a sequence of method definitions, class defitions and English
> documentation.  Readers could either follow the narrative or could
> access the classes directly though the browser.  These tools never
> took off, but I thought that the general idea was good.
>
> In one of the early days of OOPSLA, someone on a panel said that
> Smalltalk programmers should spend four or five times as much time
> reading code as writing code.  Someone in the audience stood and cried
> out "Now you tell me!  I thought I was feeble-minded because I spent
> so much time reading and so little time writing!"  Smalltalk is
> different.  It is different on many levels.  When we teach people
> Smalltalk, we have to prepare them for this difference.
>
> For example, one of the people who responded to the blog message said
> "A program is text".  But in Smalltalk, a program is not text, it is
> objects.  A program is a set of classes.  The classes and methods are
> not just represented by objects in Smalltalk, they *are* objects in
> Smalltalk.  The browser is an editor of classes and methods.  Yes, we
> can export classes and methods to text files, but the text files are
> not the way Smalltalk programmers think about programs.  The browser
> is how we think about programs, and the browser is an editor of
> objects that happen to be classes and methods.  In Smalltalk, a
> program is not text.
>
> But that is just one of many differences.  Smalltalk is objects all
> the way down.  We spend more time reading than writing.  We live in an
> "image", which is an executing program.  We modify our applications in
> the middle of their execution.  There is no "main".  When we write a
> program, we are not just reusing some code that is thirty years old,
> we are making it by modifying a program that started executing thrity
> years ago and that has been changed by thousands of people ever since.
>
> When we teach Smalltalk, we have a tendency to try to relate it to the
> students by explaining it in their terms.  We tend to downplay the
> differences.  But one of the big values of Smalltalk as an educational
> tool is the fact that it is so different.  These differences have
> disadvantages as well as advantages when it comes to building systems.
> But learning new things expands your mind, so from an educational
> point of view, the differences are one of the chief advantages of
> Smalltalk.
>
> -Ralph Johnson
>
>