ken@pdn.UUCP (Ken Auer) (04/18/88)
In article <1360@lznv.ATT.COM> psc@lznv.ATT.COM (Paul S. R. Chisholm) writes: >I've narrowed my options down to three: > >1) Say to hell with it. Hope I don't ever need to write applications >that run in an event-driven, windowing environment. > >2) Keep banging my head against it every six months or so. Hope I >continue to learn a little more each time. (Hey, I just discovered >Behavior sourceCodeAt:; I now know almost enough to make listings of my >programs!-) > >3) Say to hell with a nice, fundamental understanding of what's going >on. Just mimic and copy existing applications a few times. Hold off >on graphics applications until I can write text and list applications. >Hope I learn by osmosis. > >Suggestions? One speaker at OOPSLA '86 (forgive me for forgetting his name) made an interesting point about the learnability of Smalltalk. He said something to the effect of: Instead of comparing the learnability of Smalltalk to another language, we need to compare it to learning a language and its environment. With that in mind, learning Smalltalk isn't much different from learning UNIX and C. I'll have to agree. Learning Smalltalk takes some patience. But, in looking back, I learned it the same way I learned UNIX and C. I read the books, and the trivial examples (implementing them to a point where I understood them) then did a lot of 3) and a lot of 2). The only difference I notice in Smalltalk is that I do more RTFSing but that's probably because there's so much more readable source (i.e. it's much easier to figure out what 4-10 lines of source are doing than 4-10 pages) that is so much more readily accessible (due to the environment). Also, the debugger in Smalltalk-80 has proven invaluable (the last time I saw Smalltalk/V, the debugger was about 10 times less powerful, but it's been a while since I've seen it) in figuring out how code works. I've often dug into the guts of code by hitting ctrl-C and following the code through the debugger. (The following is rambling about my experience and advice with respect to learning Smalltalk. I'm only semi-familiar with Smalltalk/V so I'm not sure how much of this applies to it. My frame of reference is Smalltalk-80). I feel the best way to learn how to write applications in Smalltalk is to write some which are extremely similar to some of the applications already in the environment. I've found the Browser code to be very valuable in teaching how models, views, and controllers interact. After doing this for a while, you'll get a good understanding of how things work and you'll be able to write new ones from scratch. You'll even be able to find flaws in the way some of the current Smalltalk applications are written (and believe me, you'll never stop finding them :-). Watching many people here trying to learn Smalltalk has taught me a lot about how to approach it. Although I can't say that I've got all of the answers, I have learned many. I've seen the following in just about everyone who's started to learn Smalltalk. The first reaction is amazement at the power of a line or two of code. Newcomers usually spend the first few days drawing stuff on the screen, and making minor mods to applications mapped out in the book (e.g. adding a new menu item to the ScreenController). They love the ease at which they can modify or change their environment, and draw nifty stuff on the screen. Next, they usually spend some time browsing through code. Although at first, this excites them, they start to become frustrated at the lack of comments and the fact that they don't know what kind of objects the variables are refering to. Then comes the moment of truth, they decide to (or are asked to) create a new application. Their approach to this is what makes or breaks their opinion of Smalltalk. Most impatient (and/or insecure) people tend to throw their hands up at this point and choose option 1) saying something to the effect of "Unless you are a guru, you can't do anything useful with this stuff". Patience and perseverence are a must at this point. When trying to write applications for the first (few) times, remember the following: - Don't try to write it all from scratch. Smalltalk is made to reuse code. If you're writing more than you are reusing, you're making a mistake. - Don't get too creative. Use an existing application as a model, and try to understand the concepts it is using before introducing some new ones. - Don't try to change the way text works; especially when you're also working with graphics. Concentrate on a small area at a time. - Do take your time. Make sure you understand (at least partially) how each method works. Take the time to figure out the purpose of each class you (or the existing application) are using. - Do use the debugger, (and the "senders", "implementors", and "messages" options in the Browser) to help follow the code. The "inst var refs" and "class var refs" menu options in the Browser can also be very useful. If you don't know what's going on, hit Ctrl-C. N.B. Interrupting Smalltalk at certain points during Controller activity can sometimes be hazardous to the health of your image... therefore save often when debugging controllers. In summary, you need patience and perseverence when learning to write Smalltalk applications. Your first COBOL project wasn't an airline reservation system (hopefully your first COBOL project is still waiting :-); your first C project wasn't a shell; don't make your first Smalltalk project a flight simulator! I know the power is enticing but don't try to master it all at once. -------------------------------------------------------------------------- Ken Auer Paradyne Corporation {gatech,rutgers,attmail}!codas!pdn!ken Mail stop LF-207 Phone: (813) 530-8307 P.O. Box 2826 Largo, FL 34649-9981 "The views expressed above do not necessarily reflect the views of my employer, which by no means makes them incorrect."