A Lisper asks, "Am I supposed to like Smalltalk?"

> While keeping your hands on the keyboard should in theory be more efficient,
> I have found that the presentation/treatment of methods as separate units of
> work has more benefit than cost.  Having all the source in one long
> scrolling text area (as in Java or C#) results in a very different coding
> style and organization that is not as productive (at least for all those I
> know have used both environments at the master level).
>
> Michael
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Chris
> Patrick Schreiner
> Sent: Tuesday, May 16, 2006 11:40 PM
> To: The general-purpose Squeak developers list
> Subject: Re: A Lisper asks, "Am I supposed to like Smalltalk?"
>
>
>>First of all is the environment/IDE. With Lisp/Emacs/Slime, or for  
>>that matter Java/Netbeans, to write method after method, you can  
>>just type. What I saw in Squeak was a bad combination of mousing  
>>and typing. You have to click in the '--all--' window of methods,  
>>then mouse down to the editing pane, and replace text, then save,  
>>then do it again for the next method. I'm sure this is a YMMV  
>>thing, but these mini-interruptions sure wouldn't keep me in 'flow'  
>>as much as just typing.
>
>
> I totally agree with this though
>
>
>

>
> Out of curiosity, can you explain to me why using:
>
>     f := Lambda x + Lambda y.
>     f <~~ {3. 4}
>
> would be substantially different from
>
>     f := [:x :y| x + y].
>     f value: 3 value: 4.
>

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

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