How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?
Hi,
I'm trying to get familiar with Squeak. I used Smalltalk/V way back, have and read and understand the Smalltalk 80 book, so it's not completely new to me....
But Squeak is so much bigger. I'm really struggling to get an overall sense of the beast - I can't see the wood for the trees and for me, at least, the environment seems to contribute to that because of the method-by-method interface to the code seems to make it harder to get the big picture. Methods are presented in alphabetical order, without much clue as to how they relate. Similarly for classes.
Are there any pointers/suggestions? I feel like I'm missing some tool I don't know about. It's great that you can see everything, but understanding for me would be aided with some sort of "gradual revelation"; a way to replace all the details of a class or bunch of classes with conceptual documentation - showing in a screen or two the overall story of that class's purpose and place in the system. And a way to dip under that to the implementation as needed.
Any comments or suggestions for me?
Thanks, Steve Davies
Stephen Davies puso en su mail :
Hi,
I'm trying to get familiar with Squeak. I used Smalltalk/V way back, have and read and understand the Smalltalk 80 book, so it's not completely new to me....
But Squeak is so much bigger. I'm really struggling to get an overall sense of the beast - I can't see the wood for the trees and for me, at least, the environment seems to contribute to that because of the method-by-method interface to the code seems to make it harder to get the big picture. Methods are presented in alphabetical order, without much clue as to how they relate. Similarly for classes.
Are there any pointers/suggestions? I feel like I'm missing some tool I don't know about. It's great that you can see everything, but understanding for me would be aided with some sort of "gradual revelation"; a way to replace all the details of a class or bunch of classes with conceptual documentation - showing in a screen or two the overall story of that class's purpose and place in the system. And a way to dip under that to the implementation as needed.
Any comments or suggestions for me?
Thanks, Steve Davies
I have one. Decide a first project for learn "The Squeak Way". Try what that project was as fun and crazy one as you could, a game maybe. Load IRC and connect to Squeak channel and start to fire questions. And if size of Squeak raise havoc, I get SqueakLight in several flavours, including one with IRC ready to run.
Edgar
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! �Abr� tu cuenta ya! - http://correo.yahoo.com.ar
IRC??? >:-o The best way to make people shut up is to throw TLAs at them. (Don't you know any TLAs? Get off the line.)
I googled and found: "There is an IRC (Internet Relay Chat) channel devoted to Squeak. Its name is #squeak (naturally!), and it's on irc.freenode.net (note their FAQ about IRC ... :-)
Seriously, I believe Stephen hits a sore point. I've been programming Smalltalk since 1978, and most code is still unreadable. I try to pick up programs I wrote ten years ago, and what do I find? A bunch of spaghetti nicely chopped into noodles. I load some package that sounds interesting, and get what Stephen describes so well. :'(
The most revolutionary part of Smalltalk is, IMO, the Stored Program Object Computer. Seen in this light, its current programming language is a language for microcode because it defines new operations on the objects, just as regular microcode defines new operations on the binary words.
We need one or more languages that lets uts describe higher level constructs where a program = Data + Communication + Algorithm. I have written an exploratory example in Java that is based on strongly encapsulated components. It seems to help readability, but at the cost of a very bureaucratic object strucure.
What does the FORTRAN of OO look like?
Cheers --Trygve
At 15:25 29.04.2006, you wrote:
Stephen Davies puso en su mail :
Hi,
I'm trying to get familiar with Squeak. I used Smalltalk/V way back, have and read and understand the Smalltalk 80 book, so it's not completely new to me....
But Squeak is so much bigger. I'm really struggling to get an overall sense of the beast - I can't see the wood for the trees and for me, at least, the environment seems to contribute to that because of the method-by-method interface to the code seems to make it harder to get the big picture. Methods are presented in alphabetical order, without much clue as to how they relate. Similarly for classes.
Are there any pointers/suggestions? I feel like I'm missing some tool I don't know about. It's great that you can see everything, but understanding for me would be aided with some sort of "gradual revelation"; a way to replace all the details of a class or bunch of classes with conceptual documentation - showing in a screen or two the overall story of that class's purpose and place in the system. And a way to dip under that to the implementation as needed.
Any comments or suggestions for me?
Thanks, Steve Davies
I have one. Decide a first project for learn "The Squeak Way". Try what that project was as fun and crazy one as you could, a game maybe. Load IRC and connect to Squeak channel and start to fire questions. And if size of Squeak raise havoc, I get SqueakLight in several flavours, including one with IRC ready to run.
Edgar
Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
On 29.04.2006 17:12, Trygve Reenskaug wrote:
...
The most revolutionary part of Smalltalk is, IMO, the Stored Program Object Computer. Seen in this light, its current programming language is a language for microcode because it defines new operations on the objects, just as regular microcode defines new operations on the binary words.
Interesting POV!
We need one or more languages that lets uts describe higher level constructs where a program = Data + Communication + Algorithm. I have written an exploratory example in Java that is based on strongly encapsulated components. It seems to help readability, but at the cost of a very bureaucratic object strucure.
What does the FORTRAN of OO look like?
Good question.
To go into this direction evolutionarily Squeak could have 1. namespaces; 2. multiple inheritance of code (e.g. Traits) - related to the former point! -; 3. rigid conventions or tools or language extensions (not meant as xor) for answering the questions - 'outside' more or less fine granular being another class or package or ? -: 3.a) what is the 'official' interface, which *can/should* be used from outside, 3.b) which part of above interface *has* been used from the outside; 4. BlockClosures.
Currently I have no opinion about package oriented code extensions (class boxes), since this could lead to difficult to grasp code variations being valid all together... (related to 1., 2., 3.).
Regards, Stephan
Cheers --Trygve ...
you can have a look at the videos: http://www.iam.unibe.ch/~ducasse/Resources.html
If you have ideas of things that you would like to know that you do not know yet :), please tell me I want to produce new videos.
Stef
On 29 avr. 06, at 13:55, Stephen Davies wrote:
Hi,
I'm trying to get familiar with Squeak. I used Smalltalk/V way back, have and read and understand the Smalltalk 80 book, so it's not completely new to me....
But Squeak is so much bigger. I'm really struggling to get an overall sense of the beast - I can't see the wood for the trees and for me, at least, the environment seems to contribute to that because of the method-by-method interface to the code seems to make it harder to get the big picture. Methods are presented in alphabetical order, without much clue as to how they relate. Similarly for classes.
Are there any pointers/suggestions? I feel like I'm missing some tool I don't know about. It's great that you can see everything, but understanding for me would be aided with some sort of "gradual revelation"; a way to replace all the details of a class or bunch of classes with conceptual documentation - showing in a screen or two the overall story of that class's purpose and place in the system. And a way to dip under that to the implementation as needed.
Any comments or suggestions for me?
Thanks, Steve Davies
Hi,
If you open the Objects tool from the World menu, you get some categories which cut across packages, classes and methods . These categories are not optimal or exhaustive, but they can help one zoom in on some wood. From Object tools,select a category of interest(Graphics is a good choice), drag out an object and bring up a halo and browse the class. Yes, you're back in the browser but at least with a little context. If you do this with a few objects in the category you'll notice similarites and differences. Now the Object Explorer can help - there's nothing like working with wood! One easy thing you can do to increase bandwidth while browsing is to open the World menu and select Appearances/Preferences then browsing. Select opeionalButtons. Now when you open a new browser, you'll get a row of buttons which get you more wood. Mouse over the inheritance button and pay attention to it's color. Hopefully all this helps some.
There is a deeper issue here which Americo has touched upon on the Croquet list and I'd be very interested in your take on his tutorials at: http://www.dmu.com/crb/
Other help is on the way.
Regards,
Laurence
On 4/29/06, Stephen Davies stephen.l.davies@gmail.com wrote:
Hi,
I'm trying to get familiar with Squeak. I used Smalltalk/V way back, have and read and understand the Smalltalk 80 book, so it's not completely new to me....
But Squeak is so much bigger. I'm really struggling to get an overall sense of the beast - I can't see the wood for the trees and for me, at least, the environment seems to contribute to that because of the method-by-method interface to the code seems to make it harder to get the big picture. Methods are presented in alphabetical order, without much clue as to how they relate. Similarly for classes.
Are there any pointers/suggestions? I feel like I'm missing some tool I don't know about. It's great that you can see everything, but understanding for me would be aided with some sort of "gradual revelation"; a way to replace all the details of a class or bunch of classes with conceptual documentation - showing in a screen or two the overall story of that class's purpose and place in the system. And a way to dip under that to the implementation as needed.
Any comments or suggestions for me?
Thanks, Steve Davies
Thanks for all the various responses. Don't worry, I know what IRC is...
Stef - I didn't know about your videos, which are great - I watched all of them I think, and definitely learned some things in the process. Also came across and downloaded the Squeak CD which has some books that I will read - "Smalltalk with Style" caught my eye for one.
Laurence - thanks for your practical suggestions, I will look at Americo's tutorials too.
And Edgar - yes, a specific goal will definitely add needed focus. I have an idea for a project, so lets see.
I was thinking a bit more as to why I feel at sea. In the traditional scene of static programs - lets say I'm looking at program.tcl, or program.mod, program.pas, program.rb etc etc - In a language that I'm not familiar with. I know what the program is supposed to do, Comments in the code or my common sense and general experience of programming will give me a framework in which I can see what's going on. The "domain space" is smaller, and the "solution space" is maybe a few thousand lines of source code.
Regards, Steve
Hi Steve,
on Sun, 30 Apr 2006 17:53:06 +0200, you wrote:
... I was thinking a bit more as to why I feel at sea. In the traditional scene of static programs - lets say I'm looking at program.tcl, or program.mod, program.pas, program.rb etc etc - In a language that I'm not familiar with. I know what the program is supposed to do, Comments in the code or my common sense and general experience of programming will give me a framework in which I can see what's going on. The "domain space" is smaller, and the "solution space" is maybe a few thousand lines of source code.
Just out of curiosity: if you fileOut the code of a Squeak class and view/edit that file in your favorite text editor ("string" editor), would you feel less "at sea"?
/Klaus
Most Smalltalk classes build on a lot of other Smalltalk classes. So, they are hard to understand until you know the classes that they use.
In fact, you can't print out Object and completely understand it, because it has methods like "inspect" that call a lot of other classes. It is possible to build the image up from a small base, but it is not done one class at a time. Each layer is partly new classes and partly adding methods to existing classes. This is a good thing, not a bad thing, but it makes it harder to learn Smalltalk.
When an expert teaches Smalltalk, it is like getting a guided tour of a city. We show just the part of Smalltalk that a beginner is able to understand, and avoid the parts that are confusing until they have the background. You don't get that by looking at the image. For example, I tell people to ignore the GUI, the compiler, and all the tools at first. Just focus on Collection classes and numbers. We spend several weeks with just the core classes before we move on to other things. The GUI is way more cool, but I think students learn better if you ignore it at first.
Unfortunately, one of the disadvantages of Smalltalk over Java is that it is harder to learn on your own. It is not hard to learn with a guide, but newcomers don't know what to look at and what to ignore. It would help to have a beginners browser that hid most of the classes that beginners want to ignore anyway.
-Ralph Johnson
Indeed; this is one of the things I wanted to add to the StarBrowser,but never found the time to do. But it coiuld be worth it...
I would add: 1- classification: 'Basic Collections' : Set, Array, String, OrderedCollection, SortedCollection (and maybe Stream) 2- classification: 'Basic Enumeration methods' : #do:, #collect:, #select:, #detect:ifNone: 3- classification: 'Boolean' : True, False 4- classification: 'Loops and conditions' : #ifTrue:, ifFalse:, ifTrue:ifFalse, ifFalse:ifTrue, #while:do:, ... (some more) 5- classification: 'Interesting objects' : Smalltalk, ??
More suggestions ?
All of these methods/classes should have a comment with some very simple examples (I guess quite a lot of these already do).
On 30 Apr 2006, at 22:11, Ralph Johnson wrote:
Most Smalltalk classes build on a lot of other Smalltalk classes. So, they are hard to understand until you know the classes that they use.
In fact, you can't print out Object and completely understand it, because it has methods like "inspect" that call a lot of other classes. It is possible to build the image up from a small base, but it is not done one class at a time. Each layer is partly new classes and partly adding methods to existing classes. This is a good thing, not a bad thing, but it makes it harder to learn Smalltalk.
When an expert teaches Smalltalk, it is like getting a guided tour of a city. We show just the part of Smalltalk that a beginner is able to understand, and avoid the parts that are confusing until they have the background. You don't get that by looking at the image. For example, I tell people to ignore the GUI, the compiler, and all the tools at first. Just focus on Collection classes and numbers. We spend several weeks with just the core classes before we move on to other things. The GUI is way more cool, but I think students learn better if you ignore it at first.
Unfortunately, one of the disadvantages of Smalltalk over Java is that it is harder to learn on your own. It is not hard to learn with a guide, but newcomers don't know what to look at and what to ignore. It would help to have a beginners browser that hid most of the classes that beginners want to ignore anyway.
-Ralph Johnson
Hello,
As other people mentioned, getting started with Smalltalk is the toughest part (unlike most scripting languages like php, where it is the opposite -- try to get some real work done after an initial period of wonder and everything-goes).
What might help is: 1) (as was already mentions) : try to fix a goal. What do you want to learn about first ? Morphic (then build a kind of GUI application), network library (write a newsfeed client), ...
2) you might want to use tools like eCompletion or RoelTyper to figure out some dependencies between classes.
3) you might want to use the StarBrowser so that you can keep some of the classes that interest you in classifications. For me this helps sometimes to build my own structure for understanding code.
Note that all of these approaches are bottom-up. I second the need for top-down information. What I planned to do some years back was to launch the StarBrowser with some beginner classifications that for example contain some of the most used collections, some Morphic classes, etc.
On 29 Apr 2006, at 13:55, Stephen Davies wrote:
Hi,
I'm trying to get familiar with Squeak. I used Smalltalk/V way back, have and read and understand the Smalltalk 80 book, so it's not completely new to me....
But Squeak is so much bigger. I'm really struggling to get an overall sense of the beast - I can't see the wood for the trees and for me, at least, the environment seems to contribute to that because of the method-by-method interface to the code seems to make it harder to get the big picture. Methods are presented in alphabetical order, without much clue as to how they relate. Similarly for classes.
Are there any pointers/suggestions? I feel like I'm missing some tool I don't know about. It's great that you can see everything, but understanding for me would be aided with some sort of "gradual revelation"; a way to replace all the details of a class or bunch of classes with conceptual documentation - showing in a screen or two the overall story of that class's purpose and place in the system. And a way to dip under that to the implementation as needed.
Any comments or suggestions for me?
Thanks, Steve Davies
now that videos are easy to do, we should produce a massive amount of "code with me that application" movie.
Stef
On 1 mai 06, at 09:03, Roel Wuyts wrote:
Hello,
As other people mentioned, getting started with Smalltalk is the toughest part (unlike most scripting languages like php, where it is the opposite -- try to get some real work done after an initial period of wonder and everything-goes).
What might help is:
- (as was already mentions) : try to fix a goal. What do you want
to learn about first ? Morphic (then build a kind of GUI application), network library (write a newsfeed client), ...
- you might want to use tools like eCompletion or RoelTyper to
figure out some dependencies between classes.
- you might want to use the StarBrowser so that you can keep some
of the classes that interest you in classifications. For me this helps sometimes to build my own structure for understanding code.
Note that all of these approaches are bottom-up. I second the need for top-down information. What I planned to do some years back was to launch the StarBrowser with some beginner classifications that for example contain some of the most used collections, some Morphic classes, etc.
On 29 Apr 2006, at 13:55, Stephen Davies wrote:
Hi,
I'm trying to get familiar with Squeak. I used Smalltalk/V way back, have and read and understand the Smalltalk 80 book, so it's not completely new to me....
But Squeak is so much bigger. I'm really struggling to get an overall sense of the beast - I can't see the wood for the trees and for me, at least, the environment seems to contribute to that because of the method-by-method interface to the code seems to make it harder to get the big picture. Methods are presented in alphabetical order, without much clue as to how they relate. Similarly for classes.
Are there any pointers/suggestions? I feel like I'm missing some tool I don't know about. It's great that you can see everything, but understanding for me would be aided with some sort of "gradual revelation"; a way to replace all the details of a class or bunch of classes with conceptual documentation - showing in a screen or two the overall story of that class's purpose and place in the system. And a way to dip under that to the implementation as needed.
Any comments or suggestions for me?
Thanks, Steve Davies
Roel Wuyts puso en su mail :
Hello,
As other people mentioned, getting started with Smalltalk is the toughest part (unlike most scripting languages like php, where it is the opposite -- try to get some real work done after an initial period of wonder and everything-goes).
What might help is:
- (as was already mentions) : try to fix a goal. What do you want to
learn about first ? Morphic (then build a kind of GUI application), network library (write a newsfeed client), ...
- you might want to use tools like eCompletion or RoelTyper to
figure out some dependencies between classes.
- you might want to use the StarBrowser so that you can keep some of
the classes that interest you in classifications. For me this helps sometimes to build my own structure for understanding code.
Note that all of these approaches are bottom-up. I second the need for top-down information. What I planned to do some years back was to launch the StarBrowser with some beginner classifications that for example contain some of the most used collections, some Morphic classes, etc.
What Roels say reminds me to send again this:
http://www.4shared.com/file/833444/8e413b3e/MorphClassMaps.html
Courtesy of Morphic Team, here you could have a .zip with some of class hierarchy in new Morphic clasification, I attach the small .jpg for you have the idea of what is in .zip
This is the complete list, produced from Squeak with GraphViz module from John Pierce
Morphic-Menus class hierarchy.jpg Morphic-Menus class hierarchy.dot Morphic-Pluggable Widgets class hierarchy.jpg Morphic-Pluggable Widgets class hierarchy.dot Morphic-Support class hierarchy.jpg Morphic-Support class hierarchy.dot Morphic-Text Support class hierarchy.jpg Morphic-Text Support class hierarchy.dot Morphic-Widgets class hierarchy.jpg Morphic-Widgets class hierarchy.dot Morphic-Windows class hierarchy.jpg Morphic-Windows class hierarchy.dot Movies class hierarchy.jpg Movies class hierarchy.dot Speech class hierarchy.jpg Speech class hierarchy.dot Nebraska class hierarchy.jpg Nebraska class hierarchy.dot BalloonMMFlash class hierarchy.jpg BalloonMMFlash class hierarchy.dot
Possible uses is you could have a clear understanding of Morphic or amazing friends with wall size versions of jpg and hard copy of NASA job search about Squeak :=)
Enjoy
I would like to add the Tracing Messages Browser to this list. This browser is great for browsing the flow of code that cuts across classes in various packages. You end up with a single window showing the flow of execution instead of 57 windows.
----- Original Message ---- From: Roel Wuyts Roel.Wuyts@ulb.ac.be To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Sent: Monday, May 1, 2006 2:05:09 AM Subject: Re: How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?
Hello,
As other people mentioned, getting started with Smalltalk is the toughest part (unlike most scripting languages like php, where it is the opposite -- try to get some real work done after an initial period of wonder and everything-goes).
What might help is: 1) (as was already mentions) : try to fix a goal. What do you want to learn about first ? Morphic (then build a kind of GUI application), network library (write a newsfeed client), ...
2) you might want to use tools like eCompletion or RoelTyper to figure out some dependencies between classes.
3) you might want to use the StarBrowser so that you can keep some of the classes that interest you in classifications. For me this helps sometimes to build my own structure for understanding code.
Note that all of these approaches are bottom-up. I second the need for top-down information. What I planned to do some years back was to launch the StarBrowser with some beginner classifications that for example contain some of the most used collections, some Morphic classes, etc.
On 29 Apr 2006, at 13:55, Stephen Davies wrote:
Hi,
I'm trying to get familiar with Squeak. I used Smalltalk/V way back, have and read and understand the Smalltalk 80 book, so it's not completely new to me....
But Squeak is so much bigger. I'm really struggling to get an overall sense of the beast - I can't see the wood for the trees and for me, at least, the environment seems to contribute to that because of the method-by-method interface to the code seems to make it harder to get the big picture. Methods are presented in alphabetical order, without much clue as to how they relate. Similarly for classes.
Are there any pointers/suggestions? I feel like I'm missing some tool I don't know about. It's great that you can see everything, but understanding for me would be aided with some sort of "gradual revelation"; a way to replace all the details of a class or bunch of classes with conceptual documentation - showing in a screen or two the overall story of that class's purpose and place in the system. And a way to dip under that to the implementation as needed.
Any comments or suggestions for me?
Thanks, Steve Davies
On 5/1/06, Chris Muller chris@funkyobjects.org wrote:
I would like to add the Tracing Messages Browser to this list.
It can be hard for newbies to understand the value of a new tool. Making movies of them (following Stephane's suggestion) can help a lot.
-Ralph
On 01/05/06, Ralph Johnson johnson@cs.uiuc.edu wrote:
On 5/1/06, Chris Muller chris@funkyobjects.org wrote:
I would like to add the Tracing Messages Browser to this list.
It can be hard for newbies to understand the value of a new tool. Making movies of them (following Stephane's suggestion) can help a lot.
So the frustrating thing for me - I loaded the Tracing Messages Browser from Monitcello. I can see the class(es) in the browser, I have a pref for "traceMessages" in my preferences.
But I can't figure out how to get a Tracing Messages Browser open, or what I'm supposed to see happen...
Steve
When you browse Squeak code, one of the browsers you will invariably use VERY frequently is a Methods browser. This browser appears whenever you browse "senders" or "implementors" of a method, or references to a class or variable, among other things. It is a two-paned browser, methods list in the upper-pane, code in the lower-pane.
So just keep exploring code normally, the next time you use senders or implementors (something any Smalltalker does about 1000 times per day) you will see the Tracing Messages Browser.
These browsers look the same initially, but by having the "traceMessages" preference set, they take on enhanced behavior as you "trace" method calls. The SqueakMap entry describes it well:
"I look like a standard methods browser with methods in the upper pane, code in the lower. As you browse senders and implementors, the upper pane is built into a "stack" rather than opening new method browsers, reducing window profileration. Implementors are indented below the currently selected method, senders are outdented above. You end up with a flow of the execution of methods across multiple classes all in one place. The stack is quickly customized by easy-removal of unwanted methods. First, the upper pane is multi-select, and can handle rapid, sweeping gestures of the mouse without dropping selections (shift+clicking is also supported). Once methods are selected, you can quickly remove them (just from the browser) with otherwise unused Command+f."
I think this browser has saved me years of closing windows.
Please let me know if you have other questions.
Cheers, Chris
----- Original Message ---- From: Stephen Davies stephen.l.davies@gmail.com To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Sent: Monday, May 1, 2006 4:05:15 PM Subject: Re: How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?
On 01/05/06, Ralph Johnson johnson@cs.uiuc.edu wrote:
On 5/1/06, Chris Muller chris@funkyobjects.org wrote:
I would like to add the Tracing Messages Browser to this list.
It can be hard for newbies to understand the value of a new tool. Making movies of them (following Stephane's suggestion) can help a lot.
So the frustrating thing for me - I loaded the Tracing Messages Browser from Monitcello. I can see the class(es) in the browser, I have a pref for "traceMessages" in my preferences.
But I can't figure out how to get a Tracing Messages Browser open, or what I'm supposed to see happen...
Steve
That was very helpful. Thanks!
On 02/05/06, Chris Muller chris@funkyobjects.org wrote:
When you browse Squeak code, one of the browsers you will invariably use VERY frequently is a Methods browser. This browser appears whenever you browse "senders" or "implementors" of a method, or references to a class or variable, among other things. It is a two-paned browser, methods list in the upper-pane, code in the lower-pane.
So just keep exploring code normally, the next time you use senders or implementors (something any Smalltalker does about 1000 times per day) you will see the Tracing Messages Browser.
These browsers look the same initially, but by having the "traceMessages" preference set, they take on enhanced behavior as you "trace" method calls. The SqueakMap entry describes it well:
Ah - got it. Thanks for the explanation.
Steve
But this doesn't work if you use the Refactoring Browser :(
Chris Muller wrote:
When you browse Squeak code, one of the browsers you will invariably use VERY frequently is a Methods browser. This browser appears whenever you browse "senders" or "implementors" of a method, or references to a class or variable, among other things. It is a two-paned browser, methods list in the upper-pane, code in the lower-pane.
Hello Antony,
AB> But this doesn't work if you use the Refactoring Browser :(
it does work. What you have to do is mark the method in the rightmost top pane of the RB and press Alt m for implementors or Alt n for senders. This will open the tracing messages browser.
Can't imagine how to continue without.
(on Win that is don't know how to formulate this in mouse button colours)
Didn't yet manage to enter this into mantis.
AB> Chris Muller wrote:
When you browse Squeak code, one of the browsers you will invariably use VERY frequently is a Methods browser. This browser appears whenever you browse "senders" or "implementors" of a method, or references to a class or variable, among other things. It is a two-paned browser, methods list in the upper-pane, code in the lower-pane.
Cheers
Herbert mailto:herbertkoenig@gmx.net
Yes it works fine with Refactoring browser, it just doesn't get called because Refactoring Browser modifies methods which call the standard methods browser to call its own VERY unfriendly methods browser.
This might be avoidable if you load Tracing Messages Browser AFTER Refactoring browser, otherwise you'll have to revert a few methods that Refactoring Browser installs which calls its own terrible methods browser.
If you are a new Smalltalker, this would be a good exercise in finding and updating code to suit you. You can find the methods which need to be changed by using the Command+Shift+e on the text of the menu (i.e., "implementors of...").
To get you started, #implementorsOfIt and #sendersOfIt in ParagraphEditor will take care of the ones when browsing out of a code pane.. Another is CodeHolder>>#messageListKey:from: which will take care of using the hot key invocations from message lists..
This is life in Smalltalk. The system is open so things sometimes get changed, particularly when it comes to the IDE. Thankfully, the system is open so at least you can take control of your own software destiny.
- Chris
----- Original Message ---- From: Antony Blakey antony.blakey@linkuistics.com.au To: squeak-dev@lists.squeakfoundation.org Sent: Wednesday, May 3, 2006 7:40:37 AM Subject: Re: How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?
But this doesn't work if you use the Refactoring Browser :(
Chris Muller wrote:
When you browse Squeak code, one of the browsers you will invariably use VERY frequently is a Methods browser. This browser appears whenever you browse "senders" or "implementors" of a method, or references to a class or variable, among other things. It is a two-paned browser, methods list in the upper-pane, code in the lower-pane.
All of which reinforces the original point of the thread. So many things definitely don't "just work" - especially given that I had no idea if this was a) known to be broken; or b) my config error; or c) broken in my particular version; or d) fixable by investigating the code.
Not a criticism, just an observation that it's difficult to empathise with a newbie when you are not.
As an aside, I guess this is a significant advantage that e.g. VW has over Squeak.
Chris Muller wrote:
Yes it works fine with Refactoring browser, it just doesn't get called because Refactoring Browser modifies methods which call the standard methods browser to call its own VERY unfriendly methods browser.
This might be avoidable if you load Tracing Messages Browser AFTER Refactoring browser, otherwise you'll have to revert a few methods that Refactoring Browser installs which calls its own terrible methods browser.
If you are a new Smalltalker, this would be a good exercise in finding and updating code to suit you. You can find the methods which need to be changed by using the Command+Shift+e on the text of the menu (i.e., "implementors of...").
To get you started, #implementorsOfIt and #sendersOfIt in ParagraphEditor will take care of the ones when browsing out of a code pane.. Another is CodeHolder>>#messageListKey:from: which will take care of using the hot key invocations from message lists..
This is life in Smalltalk. The system is open so things sometimes get changed, particularly when it comes to the IDE. Thankfully, the system is open so at least you can take control of your own software destiny.
- Chris
I certainly understand and agree with that sentiment. Most things with Squeak seem to require a little sweat to get going. Heck, a lot of packages don't even present a workspace pop-up suggesting where to start; you actually have to look for code-elements and examine just to figure out where to start!
But many things do "work", some even well. Its just that packages under development move so fast they quickly become slightly contentious with each other. I think this problem exists in any technology, but amplified in Squeak commmunity. I think its the side-effects of rapid commumity development, the wide-openness of the system, and a community still struggling with coordination and money.
But I know we can do better, even just a change to a more-inviting mindset would help tremendously. I think SqueakMap has the right mindset because it tries to document how to get something working; which version, what should be the expected stability, etc.
I do think we need better "one-click loading". SqueakMap can do it, its just laborious (but flexible) to post, I tried to resurrect SARBuilder but rapid development and lack of coordination and other code changing under me rapidly.. sigh.
Things *are* considerably better than they were, and I think they'll get better and more stable.
Cheers, Chris
----- Original Message ---- From: Antony Blakey antony.blakey@linkuistics.com.au To: squeak-dev@lists.squeakfoundation.org Sent: Thursday, May 4, 2006 8:38:55 AM Subject: Re: How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?
All of which reinforces the original point of the thread. So many things definitely don't "just work" - especially given that I had no idea if this was a) known to be broken; or b) my config error; or c) broken in my particular version; or d) fixable by investigating the code.
Not a criticism, just an observation that it's difficult to empathise with a newbie when you are not.
As an aside, I guess this is a significant advantage that e.g. VW has over Squeak.
Chris Muller wrote:
Yes it works fine with Refactoring browser, it just doesn't get called because Refactoring Browser modifies methods which call the standard methods browser to call its own VERY unfriendly methods browser.
This might be avoidable if you load Tracing Messages Browser AFTER Refactoring browser, otherwise you'll have to revert a few methods that Refactoring Browser installs which calls its own terrible methods browser.
If you are a new Smalltalker, this would be a good exercise in finding and updating code to suit you. You can find the methods which need to be changed by using the Command+Shift+e on the text of the menu (i.e., "implementors of...").
To get you started, #implementorsOfIt and #sendersOfIt in ParagraphEditor will take care of the ones when browsing out of a code pane.. Another is CodeHolder>>#messageListKey:from: which will take care of using the hot key invocations from message lists..
This is life in Smalltalk. The system is open so things sometimes get changed, particularly when it comes to the IDE. Thankfully, the system is open so at least you can take control of your own software destiny.
- Chris
Maybe this will help someone struggling with this issue. Maybe it won't.
I've been an on-again, off-again Smalltalker for years. I've authored or co-authored several books on the subject. I've helped design and write two pretty substantial systems in Smalltalk. I'm not an engineer by training or discipline but I'm a programming language junkie with a pretty decent grasp of object-oriented concepts.
My early experiences with Smalltalk had two fearful faces to them.
One was the notion that I was not creating a simple program which, if it broke, didn't do any damage elsewhere in the universe. Rather, I was <insert appropriate scary overture music> *modifying THE image*. It was kind of like correcting God. I used to pause, my fingers poised over the keyboard, as I overrode some method or subclassed a builtin class and think, "I'm about to modify the known Smalltalk universe. If I screw this up...." And my fingers would fall back onto the desk. I'm not kidding about this. It sometimes took me a very long time to be willing to start coding even when I was sure what I was doing.
The other source of fear derived, for me, from the experience that said that it was hard to do basic, simple stuff in Smalltalk that would have been a cake-walk in Basic or Pascal, the other languages with which I was pretty familiar when I began my Smalltalk meanderings (which are far too random to qualify as a journey). Just an example. I remember one day thinking I'd write the Basic program that was sort of just after "Hello World". It printed out the numbers from 1 to 10 alongside their square and cube. Trivial, right? Five minutes after I opened and installed Basic, I had it working. Pascal took longer but that was because the install took longer and I had to learn about compilation. I could not get it to run in Smalltalk/V to save my gluteus maximus. I can't now remember all the gyrations I went through before I finally threw up my hands and asked for help.
But even after that, I remember a lot of times in which I'd spend hours poring over the source for various classes and methods that seemed like they might do what I wanted to do if only I could wrestle them to the ground, finally locate what I needed and then write two or three lines of code in a new method that just worked the first time exactly as I intended. But the code-shopping phase of programming always seemed like it took too long and I believed it took too long because I was incompetent somehow. Why? Because always before Smalltalk, productivity was measured in lines of code per hour or day. In Smalltalk, the real hard-core coders seemed to be the guys who wrote the *fewest* new lines of code per day because they figured out how to hook into what already worked.
I finally created this analogy. At least I think I created it. Maybe someone else had it before me but I didn't read it. Writing a program in every language except Smalltalk is like starting with a pile of building materials and building a house. There were some large- function building blocks and some very small ones, but you took them from a seemingly infinite pile of those pieces and you fabricated a house pretty much from scratch, following a blueprint whose level of detail and sophistication varied dramatically. Programming in Smalltalk is more like adding a new office or apartment to a skyscraper whose very building fabric has connectors for 90% of what you want to do and suitable building supplies to fill in the missing pieces. If I build a house, I don't have to worry too much about fitting in to some other scheme (other than rules and regulations, that is). But if I'm going to create a new office space atop a 3875- story skyscraper that already has a lot of stuff in place, I'd better be trying to fit organically into the existing scheme of things and create symbiotically.
Like all analogies, this one breaks at various points, but it does draw one to a single and helpful inevitable conclusion. If you want to master Smalltalk, spend your first days, weeks and/or months (YMMV) studying and understanding the key components of the class library. Then go design and write your new apartment of office. It will be much less painful, even though it will seem to take a lot longer at first.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. -.-.-.-.-.-.-.-.-.-.-.-.-.-.- Dan Shafer "Looking at technology from every angle"
Nice post Dan,
My early experiences with Smalltalk had two fearful faces to them.
One was the notion that I was not creating a simple program which, if it broke, didn't do any damage elsewhere in the universe. Rather, I was <insert appropriate scary overture music> *modifying THE image*.
In this case, the image appears to have led to this nervous psyche. Other systems don't have a live environment for trying and learning. Instead, you start with a blank text editor into which type a program and subsequently feed to the compiler or interpreter. These systems are so closed off there's little or no chance of any danger, is that right?
Now, I suppose this could be done with Smalltalk too, but its so ironic that a primary benefit of the environment is *learning* it through live experimentation and live program development. I don't know if this will help but, "Go ahead, its ok." :) As you now know, any changes you make only modify YOUR image and only in memory (until you save). So you won't do much damage elsewhere in the universe, so go ahead, explore! Once you let go of the fear, I think you will enjoy working in an image immensely.
It was kind of like correcting God. I used to pause, my fingers poised over the keyboard, as I overrode some method or subclassed a builtin class and think, "I'm about to modify the known Smalltalk universe. If I screw this up...."
Please pardon the blasphemy but, in your image, YOU are god. That's the attitude adjustment needed for people to take control of their own software destiny. The mainstream sw industry counters this by constantly pummelling the marketing tecnobabble, it actually works in intimidating people and they become afraid just like you did.
Adding a subclass will never cause any problem. The new subclass is your "blank slate" you can feel safe to go crazy.
The other source of fear derived, for me, from the experience that said that it was hard to do basic, simple stuff in Smalltalk that would have been a cake-walk in Basic or Pascal, the other languages with which I was pretty familiar when I began my Smalltalk meanderings (which are far too random to qualify as a journey). Just an example. I remember one day thinking I'd write the Basic program that was sort of just after "Hello World". It printed out the numbers from 1 to 10 alongside their square and cube. Trivial, right?
Well, I think "familiar" is the key word here, because this is indeed a cakewalk in Smalltalk too:
"print it" String streamContents: [ : stream | (1 to: 10) collect: [ : n | stream cr. 1 to: 3 do: [ : exp | stream tab; print: (n raisedTo: exp) ] ] ]
Coding time: 2 minutes. I doubt I could do it in Pascal in < 10 minutes though. It's just familiarity, thats all.
Five minutes after I opened and installed Basic, I had it working. Pascal took longer but that was because the install took longer and I had to learn about compilation. I could not get it to run in Smalltalk/V to save my gluteus maximus. I can't now remember all the gyrations I went through before I finally threw up my hands and asked for help.
When looking at the simple code above, what do you think is the reason it eluded you so?
But even after that, I remember a lot of times in which I'd spend hours poring over the source for various classes and methods that seemed like they might do what I wanted to do if only I could wrestle them to the ground, finally locate what I needed and then write two or three lines of code in a new method that just worked the first time exactly as I intended. But the code-shopping phase of programming always seemed like it took too long and I believed it took too long because I was incompetent somehow. Why? Because always before Smalltalk, productivity was measured in lines of code per hour or day. In Smalltalk, the real hard-core coders seemed to be the guys who wrote the *fewest* new lines of code per day because they figured out how to hook into what already worked.
Code-shopping is no different than looking up in the Pascal manual isn't it? Except you can be certain the code is up to date, the manual may not be.. Also, the code can actually be tried and watch it happen in the debugger:
SomeMysteriousClass new halt someMysteriousMethod
I finally created this analogy. At least I think I created it. Maybe someone else had it before me but I didn't read it. Writing a program in every language except Smalltalk is like ...
Well, this simply sounds like intimidation by the image again. Once you create your own subclass and feel completely free to go crazy, you can just build your house, right?
Like all analogies, this one breaks at various points, but it does draw one to a single and helpful inevitable conclusion. If you want to master Smalltalk, spend your first days, weeks and/or months (YMMV) studying and understanding the key components of the class library. Then go design and write your new apartment of office. It will be much less painful, even though it will seem to take a lot longer at first.
I add that "studying" does not have to be reading every class of every method. Instead, studying should mean do programming exercises that force you to "query the database" of code (classes and methods) to find, experiment and assemble them in the live environment. This learning "by doing" should have much more lasting impact than reading the Pascal manual cover to cover.
Regards, Chris
Chris....
Thanks for the great feedback. Glad you found the post interesting.
I did in fact overcome all of this. I am re-emerging into the world of Squeak/Smalltalk with tentative steps these days as I evaluate it vs. PythonCard as my next development tool of choice. You can follow my thinking and my progress in bits and pieces on my blog if you're so inclined (http://www.danshafer.com/onemind). I was recording here my very early experiences and fears; they are long since dismissed and I find that I now have a proliferation of images containing all sorts of stuff and experiments. Playing God in the Image is certainly fun. (An aside: I'm a spiritual teacher and writer by profession, so I couldn't help but turn your note into a little saying. "The Bible tells us we are made in the image and likeness of God. In Smalltalk, your image is created by a likeness of God." FWIW.)
On May 8, 2006, at 2:30 PM, Chris Muller wrote:
Nice post Dan,
<snip>
Well, I think "familiar" is the key word here, because this is indeed a cakewalk in Smalltalk too:
"print it" String streamContents: [ : stream | (1 to: 10) collect: [ : n | stream cr. 1 to: 3 do: [ : exp | stream tab; print: (n raisedTo: exp) ] ] ]
Coding time: 2 minutes. I doubt I could do it in Pascal in < 10 minutes though. It's just familiarity, thats all.
Five minutes after I opened and installed Basic, I had it working. Pascal took longer but that was because the install took longer and I had to learn about compilation. I could not get it to run in Smalltalk/V to save my gluteus maximus. I can't now remember all the gyrations I went through before I finally threw up my hands and asked for help.
When looking at the simple code above, what do you think is the reason it eluded you so?
Well, your result is nothing like I ended up with; you found a much more elegant solution (iterating over the exp for example). But note that to create that code I'd have to know about the class String, streams, collect: (a powerful but really new concept) and the raisedTo: method. Not hard stuff, of course, but, as you properly say, it's a question of familiarity and only that.
In Basic, it's something like:
repeat with i = 1 to 10 print i; i*i, i*i*i end repeat
Essentially the same in Pascal. But note that the "print" statement just prints stuff in a predictable place. When I solved the problem in Smalltalk, I ended up believing that I needed to use the Transcript for output, which involved figuring out how to get one to open and print stuff.
Also, I should note that this was my first attempted program out of the box without reading any docs. That's how I'd done it in Basic and Pascal, so I expected a similar result form Smalltalk. It was my familiarity with other environments and my inaccurate expectation at work. But I suspect a LOT of folks who encounter Smalltalk do so with a similar mind set and walk away bewildered.
Dan
On 5/10/06, Dan Shafer dan@shafermedia.com wrote:
Well, your result is nothing like I ended up with; you found a much more elegant solution (iterating over the exp for example). But note that to create that code I'd have to know about the class String, streams, collect: (a powerful but really new concept) and the raisedTo: method. Not hard stuff, of course, but, as you properly say, it's a question of familiarity and only that.
In Basic, it's something like:
repeat with i = 1 to 10 print i; i*i, i*i*i end repeat
You can pretty much write the same in Squeak too:
1 to: 10 do: [:i | Transcript show: i; tab; show: i * i; tab; show: i * i * i; cr].
Actually, there's a squared method, but unfortunately, there's no cubed method ;-(
Also, it might be nice if Transcript
Essentially the same in Pascal. But note that the "print" statement
just prints stuff in a predictable place. When I solved the problem in Smalltalk, I ended up believing that I needed to use the Transcript for output, which involved figuring out how to get one to open and print stuff.
I see what you're trying to get at, but unfortunately, this is not a particular good example, because It's the same in other languages too.
I don't know Pascal/Basic, but if you were to do it in Java, or C#, you'll end up using the StringBuilder class, which is just the equivalent to the Stream here. In C#, StringBuilder is part of System.Text, which requires a 'using' statement, so it's not a module that can be used out of the box either (and I'm sure the same is true in the Java case).
Duncan.
1 to: 10 do: [:i | Transcript show: i; tab; show: i * i; tab; show: i * i * i; cr].
Thanks for this, it seems far more comparable from a beginner's point of view. The other one made me cry. :)
Yeah, in that case, a beginner just needs to grok the idea of a Transcript. The iterator syntax looks strange to a newbie but isn't hard to read. But I submit that it *is* hard to "invent".
Dan
On May 10, 2006, at 5:43 PM, Simon Michael wrote:
1 to: 10 do: [:i | Transcript show: i; tab; show: i * i; tab; show: i * i * i; cr].
Thanks for this, it seems far more comparable from a beginner's point of view. The other one made me cry. :)
I don't disagree, Duncan. In fact, on some level, the problem I ran into is less Smalltalk/Squeak-specific than it is the head-twist required to grok a language using objects for everything.
I've since become quite comfortable with all of this, of course (or at least I think I have until I try something really sneaky) but at first, this was a real wall for me.
Dan
On May 10, 2006, at 3:48 PM, Duncan Mak wrote:
I see what you're trying to get at, but unfortunately, this is not a particular good example, because It's the same in other languages too.
I don't know Pascal/Basic, but if you were to do it in Java, or C#, you'll end up using the StringBuilder class, which is just the equivalent to the Stream here. In C#, StringBuilder is part of System.Text, which requires a 'using' statement, so it's not a module that can be used out of the box either (and I'm sure the same is true in the Java case).
Duncan.
What i note from your excellent point of view is:
- in the image, we are like god (and we like it i guess)
- a good tutorial should teach us that breaking an image is not the end of the world, we can recover from that. (I am also still afraid maybe because in early Smalltalk/V, it was not that easy).
- we all need a good step by step tutorial (Dan, i guess you had not access to the Smalltalk/V tutorial, because your basic example would have been much easier with this excellent book)
- all the time we spend inspecting the wires down to the power plant when we just have to install a bulb is the Smalltalk way of building the house. An investment well retributed by future economy of coding... This way, we not only reuse our own code, we reuse code from the whole system.
Smalltalk syntax is rather readable, and code is so easy to be changed. So, i still think the best detailed documentation of code is the code itself. But i think we lazily rely on that property, and do not write enough documentation. We rely too much on browsing (i speak for myself). This is not practicle in modern oceans of code.
As complexity is growing, proper organization (Monticello packages, traits, something higher ?) and documentation (implementation guidelines and short tutorials) is a key to Smalltalk success. And this is valuable not only for newcomers. Ideally, this documentation would be accessible from the image. I do not know at which level it should be attached (package ?), and under which format, but web like navigation sounds good to me, with crossrefs and links. The documentation found in squeak projects is something i like. Should SqueakMap have such projects attached ? Would it be possible to navigate through such worlds located anywhere on the web ? We have to invent the tools... (is this Croquet ?)
Nicolas
On May 8, 2006, at 3:28 PM, nicolas cellier wrote:
- we all need a good step by step tutorial (Dan, i guess you had
not access to the Smalltalk/V tutorial, because your basic example would have been much easier with this excellent book)
I did in fact have access to it. Later, I wrote three books on Smalltalk. But at the time I was just opening the box to see what Smalltalk was about, I was too impatient to read a book. I had this experience in Basic and Pascal and figured I'd give Smalltalk my easiest "getting to know you" program as a blind test. That turned out to be a wrong-headed approach but at the time I didn't know that.
Dan
On 03.05.2006, at 14:36, Antony Blakey wrote:
But this doesn't work if you use the Refactoring Browser :(
Which version are you using? This is fixed in the 3.9 version of course, but I think I fixed it even in the 3.8 version....
Name: Refactory-md.3844 Author: md Time: 18 January 2006, 5:35:35 pm UUID: b245755d-19cf-482e-8e06-210d4edbcc42 Ancestors: Refactory-lr.3843
delete the overrides for implementors and senders
Chris Muller wrote:
When you browse Squeak code, one of the browsers you will invariably use VERY frequently is a Methods browser. This browser appears whenever you browse "senders" or "implementors" of a method, or references to a class or variable, among other things. It is a two-paned browser, methods list in the upper-pane, code in the lower-pane.
Hello Marcus,
MD> Which version are you using? This is fixed in the 3.9 version of MD> course, but I think I fixed it even in the 3.8 version....
MD> Name: Refactory-md.3844 MD> Author: md
I'm using Refactory-md3845.mcz and this definitely needs the keys while the buttons in the code pane and the context menu of the method pane (top rightmost) don't.
Don't know for 3844.
And I have previously installed Cees' Tric-RefractoringBrowser-CdG.9.mcz which gives me only selected categories.
To make it useful: Took a 3.8.665 image loaded Refactory-md.3844 loaded Tracing Messages Browser-cmm.19.mcz Buttons and right mouse menu produce the old method browser Alt-m and n produce the tracing messages browser.
Herbert mailto:herbertkoenig@gmx.net
On 04.05.2006, at 14:28, Herbert König wrote:
Hello Marcus,
MD> Which version are you using? This is fixed in the 3.9 version of MD> course, but I think I fixed it even in the 3.8 version....
MD> Name: Refactory-md.3844 MD> Author: md
I'm using Refactory-md3845.mcz and this definitely needs the keys while the buttons in the code pane and the context menu of the method pane (top rightmost) don't.
Don't know for 3844.
3845 is based on 3844, so it's the same in this regard.
You are right, the buttons call the strange browser for implementors/ senders (I fixed in only for alt-m / n, I don't use the buttons, so I did not see the problem....). This should be fixed.
Can you add a bug-report to mantis (Squeak-packages)? I'm not sure when I can fix it, but I'm happy to add a fix if someone does it.
Marcus
Hello Marcus,
MD> Can you add a bug-report to mantis (Squeak-packages)? I'm not sure when MD> I can fix it, but I'm happy to add a fix if someone does it.
http://bugs.impara.de/view.php?id=3561
Please check before adding the fix.
Herbert mailto:herbertkoenig@gmx.net
On 1 mai 06, at 17:36, Chris Muller wrote:
I would like to add the Tracing Messages Browser to this list. This browser is great for browsing the flow of code that cuts across classes in various packages. You end up with a single window showing the flow of execution instead of 57 windows.
Where is that browser?
Stef
----- Original Message ---- From: Roel Wuyts Roel.Wuyts@ulb.ac.be To: The general-purpose Squeak developers list <squeak- dev@lists.squeakfoundation.org> Sent: Monday, May 1, 2006 2:05:09 AM Subject: Re: How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?
Hello,
As other people mentioned, getting started with Smalltalk is the toughest part (unlike most scripting languages like php, where it is the opposite -- try to get some real work done after an initial period of wonder and everything-goes).
What might help is:
- (as was already mentions) : try to fix a goal. What do you want to
learn about first ? Morphic (then build a kind of GUI application), network library (write a newsfeed client), ...
- you might want to use tools like eCompletion or RoelTyper to
figure out some dependencies between classes.
- you might want to use the StarBrowser so that you can keep some of
the classes that interest you in classifications. For me this helps sometimes to build my own structure for understanding code.
Note that all of these approaches are bottom-up. I second the need for top-down information. What I planned to do some years back was to launch the StarBrowser with some beginner classifications that for example contain some of the most used collections, some Morphic classes, etc.
On 29 Apr 2006, at 13:55, Stephen Davies wrote:
Hi,
I'm trying to get familiar with Squeak. I used Smalltalk/V way back, have and read and understand the Smalltalk 80 book, so it's not completely new to me....
But Squeak is so much bigger. I'm really struggling to get an overall sense of the beast - I can't see the wood for the trees and for me, at least, the environment seems to contribute to that because of the method-by-method interface to the code seems to make it harder to get the big picture. Methods are presented in alphabetical order, without much clue as to how they relate. Similarly for classes.
Are there any pointers/suggestions? I feel like I'm missing some tool I don't know about. It's great that you can see everything, but understanding for me would be aided with some sort of "gradual revelation"; a way to replace all the details of a class or bunch of classes with conceptual documentation - showing in a screen or two the overall story of that class's purpose and place in the system. And a way to dip under that to the implementation as needed.
Any comments or suggestions for me?
Thanks, Steve Davies
Available on SqueakSource.. MCHttpRepository location: 'http://www.squeaksource.com/TracingMessagesBrows' user: '' password: ''
----- Original Message ---- From: stéphane ducasse ducasse@iam.unibe.ch To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Sent: Tuesday, May 2, 2006 6:03:09 AM Subject: Re: How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?
On 1 mai 06, at 17:36, Chris Muller wrote:
I would like to add the Tracing Messages Browser to this list. This browser is great for browsing the flow of code that cuts across classes in various packages. You end up with a single window showing the flow of execution instead of 57 windows.
Where is that browser?
Stef
----- Original Message ---- From: Roel Wuyts Roel.Wuyts@ulb.ac.be To: The general-purpose Squeak developers list <squeak- dev@lists.squeakfoundation.org> Sent: Monday, May 1, 2006 2:05:09 AM Subject: Re: How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?
Hello,
As other people mentioned, getting started with Smalltalk is the toughest part (unlike most scripting languages like php, where it is the opposite -- try to get some real work done after an initial period of wonder and everything-goes).
What might help is:
- (as was already mentions) : try to fix a goal. What do you want to
learn about first ? Morphic (then build a kind of GUI application), network library (write a newsfeed client), ...
- you might want to use tools like eCompletion or RoelTyper to
figure out some dependencies between classes.
- you might want to use the StarBrowser so that you can keep some of
the classes that interest you in classifications. For me this helps sometimes to build my own structure for understanding code.
Note that all of these approaches are bottom-up. I second the need for top-down information. What I planned to do some years back was to launch the StarBrowser with some beginner classifications that for example contain some of the most used collections, some Morphic classes, etc.
On 29 Apr 2006, at 13:55, Stephen Davies wrote:
Hi,
I'm trying to get familiar with Squeak. I used Smalltalk/V way back, have and read and understand the Smalltalk 80 book, so it's not completely new to me....
But Squeak is so much bigger. I'm really struggling to get an overall sense of the beast - I can't see the wood for the trees and for me, at least, the environment seems to contribute to that because of the method-by-method interface to the code seems to make it harder to get the big picture. Methods are presented in alphabetical order, without much clue as to how they relate. Similarly for classes.
Are there any pointers/suggestions? I feel like I'm missing some tool I don't know about. It's great that you can see everything, but understanding for me would be aided with some sort of "gradual revelation"; a way to replace all the details of a class or bunch of classes with conceptual documentation - showing in a screen or two the overall story of that class's purpose and place in the system. And a way to dip under that to the implementation as needed.
Any comments or suggestions for me?
Thanks, Steve Davies
squeak-dev@lists.squeakfoundation.org
-
Antony Blakey -
Chris Muller -
Dan Shafer -
Duncan Mak -
Herbert König -
Klaus D. Witzel -
Laurence Rozier -
Lic. Edgar J. De Cleene -
Marcus Denker -
nicolas cellier -
Ralph Johnson -
Roel Wuyts -
Simon Michael -
Stephan Rudlof -
Stephen Davies -
stéphane ducasse -
Trygve Reenskaug