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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
77 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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

Alan L. Lovejoy
Reply | Threaded
Open this post in threaded view
|

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

Duncan Mak-2
On 5/16/06, Alan Lovejoy <[hidden email]> wrote:
Link: <a href="http://i-need-closures.blogspot.com/2006/05/am-i-supposed-to-like-smalltalk.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://i-need-closures.blogspot.com/2006/05/am-i-supposed-to-like-smalltalk.html

I just read another blog entry and it took brings up the familiar topic of 'how do i get started on using squeak?'.

http://www.goesping.org/index.php?p=152

While the LISP guy just couldn't even get started to really use the environment, 'my' guy did eventually learn to like and use Squeak, yet he still finds it difficult to get work done (and somtimes I feel the same too).

Duncan.


Reply | Threaded
Open this post in threaded view
|

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

Chris Patrick Schreiner
In reply to this post by Alan L. Lovejoy
> 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

Reply | Threaded
Open this post in threaded view
|

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

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


Reply | Threaded
Open this post in threaded view
|

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

Zulq Alam

> I have found that the presentation/treatment of methods as separate units of
> work has more benefit than cost.
As someone who really misses the flexibility of a flat file *and* IDE
navigation could you explain the benefits to me?

Things I can't easily do now are:

    - Look at more than one method at the same.
    - Edit more than one method at the same time.
    - Show how code is related by spatial relation to other code.
    - Move around a class in a fuzzy way, e.g. Page Up/Down, Ctrl+End in
Windows.
    - Look at class declaration stuff easily (is there or could there be
a key for this?). I'd just use Ctrl+Home in Windows to get to the top of
a Java file.
    - Jump around the class method by method Ctrl+Shift+Down/Up in
Eclipse - Squeak might be able to do this?
    - Print out a class (though I haven't even tried this in Squeak)

The first two are really important to me, I didn't realize how much I
did this until I switched. Some kind of popup code viewer could work
here, on top but without focus still in the browser code area. My
monitor is way too small (19") to fit all the browsers I need.

With regard to showing how code is related, has anyone looked into
multiple categories for methods? Less about saying what a method does
but more about what methods it's related to (so maybe not a category at
all).




Reply | Threaded
Open this post in threaded view
|

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

Stéphane Rollandin
In reply to this post by Alan L. Lovejoy
Alan Lovejoy wrote:
> Link:
> http://i-need-closures.blogspot.com/2006/05/am-i-supposed-to-like-smalltalk.
> html
>

"
Second is the 'OOP all the way' flavor of the Smalltalk language.
Sometimes a function is just a function, and doesn't need to be in a
class. I prefer the options that Lisp provides, I use imperative, OO,
and functional, depending on the problem.
"

this is now possible with LambdaMessageSend (on Squeakmap). a function
can be just a function


Stef

Reply | Threaded
Open this post in threaded view
|

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

Duncan Mak-2
In reply to this post by Zulq Alam
On 5/17/06, Zulq Alam <[hidden email]> wrote:
Things I can't easily do now are:

    - Look at more than one method at the same.
    - Edit more than one method at the same time.

Just open another browser.

    - Show how code is related by spatial relation to other code.

The linear ordering of code is only important because there's no way to group methods together in these languages.

C# has #region, which lets you group things together, and then the code editor can fold on them, but the Squeak code browser has method categories too, which is the exact same idea.
 
    - Move around a class in a fuzzy way, e.g. Page Up/Down, Ctrl+End in
Windows.

Well, just start clicking around the method category pane and method pane.

    - Look at class declaration stuff easily (is there or could there be
a key for this?). I'd just use Ctrl+Home in Windows to get to the top of
a Java file.

Here's a trick I do:

type 'self', alt-p to print the class name, and then press alt-b to browse it

I think the keybindings to 'browse it', 'senders of' and 'implementers of' are the keystrokes that I hit the most often in a Squeak session.

    - Jump around the class method by method Ctrl+Shift+Down/Up in
Eclipse - Squeak might be able to do this?

With the focus on the list, you can just use the up/down button.

    - Print out a class (though I haven't even tried this in Squeak)

Right click on the class and fileout,  There might even be a way to generate a nice PostScript version, but  I don't know how.

The first two are really important to me, I didn't realize how much I
did this until I switched. Some kind of popup code viewer could work
here, on top but without focus still in the browser code area. My
monitor is way too small (19") to fit all the browsers I need.

I agree that there's a tendency to have too many browser windows, but I work on squeak from my laptop ( 12.1"), and as long as I close the browsers I leave running around, I think it's fine.

You might also wanna try some other browsers, like Whisker Browser:

http://www.mindspring.com/~dway/smalltalk/whisker.html

Duncan.


Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
In reply to this post by Stéphane Rollandin
Stéphane Rollandin wrote:
> "
> Second is the 'OOP all the way' flavor of the Smalltalk language.
> Sometimes a function is just a function, and doesn't need to be in a
> class. I prefer the options that Lisp provides, I use imperative, OO,
> and functional, depending on the problem.
> "
>
> this is now possible with LambdaMessageSend (on Squeakmap). a function
> can be just a function

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.

(other than that the former looks more unusual ;-) If it's about the
syntax it'd be pretty simple to change the block syntax to something
like here:

        f(x, y) := [x + y].
        f(3, 4).

[Hm ... actually this *does* look pretty reasonable; I should consider
this for Croquet] I'm in particular curious about your claim this is
"now" possible which seems to imply that there is something
LambdaMessageSend does that blocks/closures for some reason can't
represent properly.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

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

Chris Patrick Schreiner
In reply to this post by Duncan Mak-2

Den 17. mai. 2006 kl. 10.07 skrev Duncan Mak:

...
You might also wanna try some other browsers, like Whisker Browser:

http://www.mindspring.com/~dway/smalltalk/whisker.html

Duncan.


The whisker browser brings something fresh into the traditional browser approach arena. But I find myself even more depending on my mouse when using it. I guess I am happy with it because it emulates very nicely a feature that I occationally find extremely useful; the ability to see several things at once without cluttering my screen with fluff, and without requiring me to spend energy on arranging it, in this regard Squeaks-UI-feel really sucks!

I guess Whisker address this one issue, keeping the screen tidy, perfectly, otherwise it's a pain in the .... to use. But I do use it from time to time, because its so brilliant at letting me select what information I want to look at. Introduce some rudimentary keyboard commands, that would be really really great. (also thinking about introducing the idea of screensets into Whisker).

chris p


Reply | Threaded
Open this post in threaded view
|

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

Gilrandir
In reply to this post by Michael Latta
although i personally like the smalltalk browser style much better, i
think we shouldn't just tell 'the others' "our approach is better, so
you have to use it" ...with all the "anything is possible with
smalltalk" talk on the other hand. we sure have a lot of ways to
represent all the methods for a class in a single editable stream (chunk
format?), so why not? some people will just feel more comfortable that
way ^_^

Michael Latta wrote:

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


Reply | Threaded
Open this post in threaded view
|

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

Zulq Alam
In reply to this post by Duncan Mak-2
Duncan Mak wrote:
> The linear ordering of code is only important because there's no way
> to group methods together in these languages.
Spatial ordering is actually quite effective if you only have a few
groups but is weaker than categorization if you have a reasonable number
of groups. In a flat file, a commenting convention could be used more
effectively than explicit categorization as it stands as you can have
optionally nested multiple categories etc.  Navigation would then be by
finding strings in the file.

What /might/ be a good idea is a pseudo-3D browser. Your view is from
the first person in a 3D world. Around you float classes, perhaps as
glowing orbs, with related classes floating close to each other. The
more general classes like Collection classes or the more core classes
like Kernel classes would be floating towards the center of this world.
Clicking on a class makes it the center of your view. Clicking again
takes you in to that class and you see a similar world as before but
with methods instead of classes. The methods could be squares which
always face you rather than a 3D object and this square would simply be
your code editor.

Not sure about how you would jump to another class easily, it might be
better to not have two different levels but to just have methods sitting
in opaque spheres that represent the classes. Looking at a method takes
you into the class sphere but you can still see out at other nearby
classes methods etc.

The position of objects can be rearranged as you see fit and it would
probably be good to allow multiple perspectives on the world to be saved
and used. There should also be a nice swooshing noise when flying around
this world.

Perhaps something similar already exists?

Could Croquet be used to implement something like this?




Reply | Threaded
Open this post in threaded view
|

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

Stéphane Rollandin
In reply to this post by Andreas.Raab
Andreas Raab wrote:

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

in this precise example (with numeric arguments) the behavior is not
different: actually the former uses the latest internally as its
so-called "compiled form".

but now
        f <~~ {3 . f}

is not at all the same as the block version
        f value: 3 value: f
(which opens the debugger)

you can check that
        (f <~~ {3 . f}) = (3 + (Lambda x + Lambda y))
returns true.


it also is different if you have

      x := Lambda x.
      y := Lambda y.
      f := x + y.
      g := x * y.

because you can then directly do

     (g+f) <~~ {3.4}

while with blocks you would have to do

     f := [:x :y| x + y]
     g := [:x :y| x * y].
     gplusf := [:x :y| (f value:x value: y) + (g value:x value: y)]

the printString is much clearer also:

     (g+f) printString
is
     '((<x> * <y>) + (<x> + <y>))'

while
        gplusf printString
is
  '[] in UndefinedObject>>DoIt {[:x :y | (f value: x value: y)   + (g
value: x value: y)]}'

(I did this in a workspace)


> I'm in particular curious about your claim this is
> "now" possible which seems to imply that there is something
> LambdaMessageSend does that blocks/closures for some reason can't
> represent properly.

in short, LambdaMessageSend implements closures out of nested
MessageSends. compared to blocks it is another, completely different way
to do functional programming in Smalltalk

example:

f := Lambda x + Lambda y.
g := f <~~ {15 . Lambda z sqrt}.

g printString is  '(15 + (<z> sqrt))'
and indeed
g <~ 100 return 25.0
g asBlock (compilation) returns the block [:t1 | 15 + t1 sqrt] allright


how do you do this with blocks ?


regards,

Stef











Reply | Threaded
Open this post in threaded view
|

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

Alexandre Bergel-2
In reply to this post by Andreas.Raab
> f(x, y) := [x + y].
> f(3, 4).
>
> [Hm ... actually this *does* look pretty reasonable; I should  
> consider this for Croquet] I'm in particular curious about your  
> claim this is "now" possible which seems to imply that there is  
> something LambdaMessageSend does that blocks/closures for some  
> reason can't represent properly.

Elegant, but it breaks the homogeneity of Squeak. There is no message  
sending in f(3, 4) Perhaps something like f@(3, 4) would make it more  
compliant...

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.cs.tcd.ie/Alexandre.Bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

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

Wolfgang Helbig-2
In reply to this post by Alan L. Lovejoy
Hi Victor,

you wondered,

> we sure have a lot of ways to
>represent all the methods for a class in a single editable stream (chunk
>format?), so why not? some people will just feel more comfortable that
>way ^_^

I must confess that I still tend to file out a class or even a whole category
just to browse or edit the source with vi and then file it in again if I've
changed it.

As an excuse I offer that I worked with Unix for about 10 years and with Squeak
for about 5 months. But then, the Unix editing facilities can be used for small
and big files, whereas the Squeak editor does not work well for large files. And
finally, I don't know how to save that neatly formatted text I carefully entered
into a workspace view. Which makes editing and formatting larger documents in
workspaces a less rewarding experience for me.

Greetings
Wolfgang

--
Weniger, aber besser.


Reply | Threaded
Open this post in threaded view
|

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

Ralph Johnson
In reply to this post by Zulq Alam
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

Reply | Threaded
Open this post in threaded view
|

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

Alexandre Bergel-2
> 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.

It is very well said.
Many thanks for this email...

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.cs.tcd.ie/Alexandre.Bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re[2]: A Lisper asks, "Am I supposed to like Smalltalk?"

Herbert König
In reply to this post by Zulq Alam
Hello Zulq,


ZA>     - Look at more than one method at the same.
ZA>     - Edit more than one method at the same time.
ZA>     - Show how code is related by spatial relation to other code.

all three in the TracingMessagesBrowser. I usually have two of them
open. Indentation of the control flow, one algorithm in one window,
even if it spans 20 methods in 10 classes.

I prefer it to a folding text editor, because everything that is
related to the thing I'm developing is in that single Browser. No way
to do this with files.

BTW, I still make my money with LISP and since Squeak I wish I had
that IDE there. I more or less flatly refuse to work in Delphi anymore
:-)

ZA>     - Move around a class in a fuzzy way, e.g. Page Up/Down, Ctrl+End in
ZA> Windows.

Don't need it anymore.

ZA>     - Look at class declaration stuff easily (is there or could there be
ZA> a key for this?). I'd just use Ctrl+Home in Windows to get to the top of
ZA> a Java file.

???? I guess that's why I keep a RefactoringBBrowser open in addition
to my two TMB's. Usually I also have one Explorer open.

ZA>     - Jump around the class method by method Ctrl+Shift+Down/Up in
ZA> Eclipse - Squeak might be able to do this?

ZA>     - Print out a class (though I haven't even tried this in Squeak)

Should be as easy as fileout, never tried it. Fileout and a macro in
my favourite text editor.

ZA> The first two are really important to me, I didn't realize how much I
ZA> did this until I switched. Some kind of popup code viewer could work
ZA> here, on top but without focus still in the browser code area. My
ZA> monitor is way too small (19") to fit all the browsers I need.

Really try the TracingMessagesBrowser, it needs magma base additions
and magma exceptions (don't have an image handy for correct names),
all on SM.

Cheers!


Herbert                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

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

Hernan Wilkinson
In reply to this post by Ralph Johnson
I completly agree with what Ralph says... and because Smalltalk is so
different to the other languages, enviroments, etc. it is so difficult
to compare it with them...therefore when somebody talks about Smalltalk
but have no expirience with it, I always propose he/she to really give a
Smalltalk a try, do something important, get the taste of Smalltalk, and
then to compare it with other languages... In almost 99% of the cases,
if they have really used Smalltalk, there will be no need to compare
Smalltalk anymore... they will feel what it is so difficult to explain,
no more words will be needed.

Hernan.

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


--
______________________________
Lic. Hernán A. Wilkinson
Gerente de Desarrollo y Tecnología
Mercap S.R.L.
Tacuari 202 - 7mo Piso - Tel: 54-11-4878-1118
Buenos Aires - Argentina
http://www.mercapsoftware.com
---------------------------------------------------------------------
Este mensaje es confidencial. Puede contener informacion amparada
por el secreto profesional. Si usted ha recibido este e-mail por error,
por favor comuniquenoslo inmediatamente via e-mail y tenga la
amabilidad de eliminarlo de su sistema; no debera copiar el mensaje
ni divulgar su contenido a ninguna persona. Muchas gracias.
 
This message is confidential. It may also contain information that is
privileged or otherwise legally exempt from disclosure. If you have
received it by mistake please let us know by e-mail immediately and
delete it from your system; you should also not copy the message nor
disclose its contents to anyone. Thanks.
 ---------------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

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

Zulq Alam
In reply to this post by Ralph Johnson

> The Smalltalk environment is optimized for browsing and reading, not
> for writing.
There is ultimately no point in browsing or reading alone and you cannot
write about or use what you cannot understand and you cannot read or
understand what you cannot find.

Is it perhaps more the case that the Smalltalk environment is better for
browsing and reading than it is for writing rather than being optimized
as such.

> 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.
Out of curiosity, what are your concerns when you feel this? Would you
still feel them if, hypothetically, browsing and reading were effortless?
> We spend more time reading than writing.  
More time than who and why?

Reply | Threaded
Open this post in threaded view
|

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

stéphane ducasse-2
In reply to this post by Ralph Johnson
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
>
>


1234