Volume Number: 18 (2002)
Issue Number: 7
Column Tag: REALbasic

REALbasic: How Do You Learn This Stuff, Anyway?

Suggestions on how one goes about learning to program in REALbasic

by G.D. Warner

As it says in the little box up there, my name is G.D. Warner, and I have been asked to serve as the REALbasic Contributing Editor for MacTech. I have a few articles planned, but some of these will take time to develop properly ... so if there's anything you'd like to see discussed here, or if you've got an idea, or have written an article you'd like to appear here, then by all means shoot me an e-mail.

In this, my first official outing as MacTech's REALbasic columnist, I will examine that age-old question every new programmer asks, regardless of the language:

"How in the world do you learn this stuff, Anyway?!?"

To discover the answer to this question, I posted a question on some of the newsgroups (comp.sys.mac.programmer.misc, and comp.lang.basic.realbasic): "... What is the best way to learn a programming language? That is, is it better to read through the keywords first, or what?"

As you might guess, I got a lot of different answers.

Phillip Stripling sums everything up pretty well:

"There isn't a best way, and there isn't an efficient way."

Uh-oh.

He then explained how he learned:

"I'd also say it depends on the language. I learned BASIC by typing in programs and fixing my typos. I didn't read books on programming BASIC until I had already learned enough of the language that I needed specific information on certain things that I wanted to do and didn't know how. That saved a lot of money on beginners' books, by the way. I'm not sure I could learn C or C++ that way, though."

Rocco Bowling passes on the advice his father gave him:

"For me, I first took an interest when I was 12 or so (wanting to program a game, if you can believe it). My dad handed me the SuperTalk manual and said something like, 'Son, if you really want to learn it there's only one person who can teach you. Yourself.' That's probably the most important thing my father ever taught me (you know, besides all that hard work nonsense)."

Heh. He continues:

"Buy a good book in the language you want to learn. No matter how you actually end up learning that language, there will ALWAYS be a time when you need to backtrack and look something up... a good reference book will be treasured down the road."

Patrick James has another perspective on the matter:

"In my case I have found that to learn scripting/programming of whatever type for me I have to actually be doing something with a real objective to keep doing it. I can' just learn in the 'abstract'. My learning will take place while I am actually creating something which will be useful when it is finished."

Good advice: program with a purpose.

J.B. Moreno recommends the step-by-step approach, to start:

"Learn how to set down your thoughts in concrete algorithms, how to break things up into different tasks so that you can get the job done, THEN to pick up a new languages it's simply a matter of becoming familiar with the syntax and the advantages and disadvantages of the language."

As you might know, an algorithm is simply a step-by-step process to solve a problem. For example, to figure out how much you earn per day, you would need to -

(1) Create a variable to represent hours (say, H)

(2) Create another variable to represent your rate of pay (say, P)

(3) Create still another variable to represent your daily rate (say, D)

(4) Multiply H by P

(5) Display the answer, D

Of course, somewhere in there you'll need to wrap all that math around an interface (or vice-versa).

Ian Ollmann posted an interesting suggestion:

"If you are new to programming, it might be worthwhile to take a class."

What's so special about taking classes, you ask? Ian explains:

"There are just too many new concepts (loops, conditionals, variables, etc.), which by themselves are not super difficult, but when combined with compiler problems, MacOS related problems, etc. will probably add up to become overwhelming. Compilers are notorious for being 'newbie-unfriendly' and giving cryptic error messages. It is really helpful to have someone that you can ask questions. Otherwise, the experience could be deeply frustrating."

Ian had another recommendation: "At least get yourself a book or two that teaches the language. These help organize the concepts in an easy-to-learn manner. Joining a computer programming club can be helpful as well."

Ian also recommends the old tried and true method for any musician to get to Carnegie Hall:

"The other thing to do is to practice. If you are serious about it, devote one or two hours a day (or more) to writing programs and keep it up for a few months."

Steve Wilbur agrees.

"There is no substitute for writing programs. Grab an introductory textbook, go to the back of the chapters, and write the programs asked for in the questions. Yes, they are small, menial programs that don't mean a thing - but that's what larger programs are made of. Grab a book on the language you want to use, and figure it out along the way, using the lame programs in the back of the chapters in the other book as your tool."

An anonymous programmer who goes by the name 'Anon Y. Mous' posted these thoughts in support of the 'Take a Class' method:

"There's two ways to learn programming. First, through formal education, wherein Dr. So'n'so will tell you to do this to start, leaving the meat of the coding for homework. But when your program dies, then you'll need the second way, brute force."

Um... brute force'?

Anon explains: "The second way is not actually brute force, its more an exercise in cognition ad nauseum :o) In the second way, you have to exploit some understanding that you have developed as a mechanism for troubleshooting, and that's where beginners fail (mostly due to a lack of empirical info from the brief exposure when the first bugs appear)."

Okay, formal education, along with a healthy dose of trial and error. Got it.

John Otto, of Nisus Software, shared his thoughts on learning styles:

"Different people learn better different ways. Some do better jumping in with modifying sample code. Some get drawn into MUDs, start to create their own, and go from there. Others need to sit in lectures, ask questions, see specific diagrams in answer."

Jeff Massung offers more advice of a psychological nature:

"You need to determine what kind of person you are. How do you learn math? Trial and error? Reading? Talking to someone and asking questions? Or just by looking at examples? Don't try and lie to yourself either - but once you understand how YOU learn, not only will learning programming be easier, so will everything else."

To sum up, the contributors discussed the two different methods of self-teaching and formal classes. Most suggestions applied well to both methods:

(a) Type in programs from books or other sources

(b) Start with the logic firmly in mind (or "algorithm," to use the Big Word of the week)

(c) Work with a programming club (or your local Mac User's Group's Programming SIG)

(d) Determine and pay attention to your style of learning

Taking suggestion (a), when I first started playing with computers (the Vic-20, followed by the Commodore 64), I used to try typing programs in from magazines. I got to experience close up and personal, Anon Y. Mous' "brute force" method of programming!

Gave up.

Suggestion (b), starting with a good idea of the logic flow, is also a good suggestion. It will certainly help to avoid bugs in your code later, but this stage comes after you've come up with your initial idea, and you're working out the steps to accomplish what you dreamed up.

Suggestion (c), working with a programming club, is also an excellent idea... though I would recommend teaching yourself as much as you can before approaching the club or SIG to avoid that feeling of helplessness as you listen to the more experienced programmers' conversations.

Suggestion (d), determine your style of learning, is an excellent plan. Chances are you already know how you learn... but it can't hurt to make sure.

Ricki Linksman (Linksman, 1996) has a short test you can take to determine your learning style. Once you've taken the test, you may discover your learning style will be one of the following:

(1) Visual

(2) Auditory

(3) Tactile

(4) Kinesthetic

As you might guess, Visual and Auditory learners learn by seeing or hearing, respectively. Tactile learners learn by touching or feeling with their hands, and Kinesthetic learners learn by moving their large (arm, leg) muscles, through simulations, role playing, etc. The problem here is it's hard to do role-playing in computer programming.

Then there's the method of learning foreign languages advocated in the books "Superlearning," and "Superlearning 2000," (Ostrander & Schroeder, 1979, 1994, respectively).

This method uses relaxation techniques, certain types of classical music, and information read in a rhythmic fashion over the music. Alas, no one appears to have used this method to teach themselves a programming language!

I contacted Thomas Madden, of the Accelerated Learning Institute, Inc. and asked about the possibility of doing so.

"No one, to my knowledge, has attempted to use the accelerated learning methodology for learning computer programming," he said.

"The principles could easily be applied. Any text or course that exists can be converted to the brain-based technology. Application is similar to using a computer - it is easy if you know how. There would, however, need to be a significant paradigm shift."

Well, that is somewhat promising, if not exactly concrete. I have contacted a few more agencies involved in this method of teaching. To be sure, there appears to be some difference between "Accelerated Learning" and "Superlearning." One of the Superlearning sites does mention one of their customers used these techniques to learn to program. Should they ever get back to me, I will provide an update for you. In the meantime, if you're curious, see the bibliography for links and reading recommendations.

The 'take a class' method is somewhat more difficult. How many REALbasic classes exist at your local community college? Not many, huh?

Buying a book, is a little easier, finally: there are now two books available on REALbasic: Matt Neuburg's "REALbasic: The Definitive Guide," and Erick Tejkowski's "REALbasic For Dummies" are all that are available - so far.

So what to do?

Well, here's an idea: why not stop by your local library and pick up a copy of a book for Visual Basic?

Whoa! Put away that Acme Tar and Feather(R) kit! It's not like I suggested you cross over to the Dark Side (that's another column (I'm kidding!)); I'm only suggesting that you TAKE ADVANTAGE of the amazingly large number of books out there for Visual Basic (VB from here on; REALbasic will be RB).

Now, before you go out and start looking for VB books to borrow projects from, there are a few things you need to watch out for.

VB, being a Microsoft product, uses Microsoft technologies ... like Active-X. Make sure you look through the project description in the book you're looking at to see that it doesn't rely heavily on Active-X or ADO ('Active-X Data Object'). OLE is another 'watch out for,' but not as serious. You should be able to get away with using AppleScript for the OLE functionality.

This method has several advantages:

(i) You get to "program with a purpose," as suggested by Patrick James

(ii) You get to use your reference books, as suggested by Roco Bowling

(iii) You get to practice, practice, pratice - as suggested by Ian Ollmann

Unfortunately, you may also get to experience Anon Y. Mous' "brute force" method to troubleshoot your code when it doesn't work.

I chose for my experiment in this method of learning the book "Visual Basic Weekend Crash Course," by Rick Mansfield. Also at my side were the two previously mentioned REALbasic books, and an active internet connection. Optionally, you might run Virtual PC on our system, and use the demo version of Visual Basic to enter your code so you can see how it works on the Dark - um, VB side of things.

Using this method provides one more thing to watch for when selecting a VB book: make sure the CD has a functioning copy of Visual Basic on it. One book I picked up recommended the Professional version - which, of course, wasn't on the CD. Of course, if this is all you have, it is still useable - as long as you aren't planning on running VB on your PC or via Virtual PC and you don't have a copy of the Professional edition of VB.

Before you start, if you have never used REALbasic before, I strongly suggest that you go through the tutorial on REAL's Tutorial page:

http://www.realbasic.com/download/tutorialdownload.html

Once you've been through that, go here:

http://www.applelinks.com/rbu/001

This page is the first of a series of tutorials by Marc Zeedar. As I type this, he is up to #17. Just change that '01' appropriately once you've gone through the first tutorial, and go through them all. You will learn quite a bit this way, guranteed.

Since I have VirtualPC on my system, I decided to create the project step by step - first in Visual Basic, then in REALbasic.

The first big project in the Visual Basic Weekend Crash Course is a simple - if ugly - word processor.

As you might guess, this project consists of a bunch of buttons and an EditField. Easily replicated in REALbasic:

I quickly added Balloon Help in RB, and tool tips in VB, without reading the instructions in the book. I also added the End event to the Close button in the VB app, and the Quit command to the Quit button in the RB app. At this point, I started looking at the book again, and added code to clear VB's Textbox when the New pushbutton was pressed, and then added similar code in RB's New button's Click event to clear the EditField.

Next, the book added code to the Open pushbotton. VB was easy. RB took a bit more time.

The Open button should simply create a standard Open dialog, and allow you to select a text file.

In VB, it was simply a matter of dragging a Common Dialog control to the interface (you can see it there, just below the Export button), and typing the following code in the Open button's Click event:

Private Sub cmdOpen_Click()
CommonDialog1.ShowOpen
Text1.Text = CommonDialog1.FileName
End Sub

In RB, I had to rely on my two reference books. Eric's book laid it out for me:

"To open a text file, follow these four easy steps:

REALbasic may have already created one for you, but check anyway by selecting File -> File Types."

This gave me pause for a bit, because File Types wasn't under File anymore; it had been moved to the Edit menu.

Dim TextIn as TextInputStream

f.OpenAsTextFile

TextIn = f.ReadLine"

After all of that, I ended up with this code for my Open pushbutton:

  Dim TextIn as TextInputStream
  Dim F as FolderItem
  Dim myText As String
  
  f=GetOpenFolderItem("TEXT")
//Note the caps in 'TEXT'. Using lowercase letters results in code which, when run,
//does not show any text files in the dialog box.
  
  If f<>nil Then
    TextIn = f.OpenAsTextFile
    While Not(TextIn.EOF)
      myText = TextIn.ReadLine
      EditField1.Text = EditField1.Text + myText+chr(13)
    Wend
  End If

It worked as advertised (after I fixed that 'text' blunder I mentioned in the comments), but that was a lot of work - at least when compared to VB's method.

Next the project called for coding the Save pushbutton. This was pretty easy in both RB and VB.

Next we did the code for the Print pushbutton. Here we see the differences in the Windows approach and the Macintosh approach to things.

The code for the Print button in VB is pretty straightforward:

Private Sub cmdPrint_Click()
If Text1.Text <> "" Then
Printer.Print Text1.Text
Printer.EndDoc
End If
End Sub

The code for RB is more involved. Once again I turned to Eric's "REALbasic For Dummies" book ... and found a whole chapter just devoted to printing (chapter 13).

Before I could write the code for the Print pushbutton (which, later in this project, will be removed anyway), the Print and the Page Setup... menu items will need to be enabled, the appropriate menu handlers created and the code written ... and code to create and save the Printer Setup options in a Preferences file, and load the Preferences when the application opens ... then the code for the Print button can finally be written (though 'copied-and-pasted' is somewhat more accurate).

After I entered the VB Print button code, I tested it. I didn't get a dialog box ... but my desktop printer (set to "Print to File") spat out an untitled PostScript(TM) file, so it worked.

I'm still working on finishing this program (out of time due to a short-fuse deadline) but I highly recommend doing this exercise. If programming with no real purpose doesn't work for you, this method will do the trick. It forces you to look up the Mac version of the code that your VB book has in it. Sometimes this can be a bit of a chore ... but it's well worth the effort.

Finally, Phillip Stripling had one more important piece of advice:

"Have fun, Glen."

I suggest you do the same.

• Linksman, Ricki. How to Learn Anything Quickly: An Accelerated Program for Rapid Learning. Citadel Press Book, 1996.

• Ostrander, Sheila and Schroeder, Lynn. Superlearning. Laurel, 1979

• Ostrander, Sheila, Schroeder, Lynn with Ostrander, Nancy. Superlearning 2000. Dell, 1994

• Accelerated Learning, Inc.: http://www.accelerated-learning.com/

• Superlearning, Inc.: http://www.superlearning.com/

• Superlearning 1979-2001 Authors Web Site of the Supermemory/Superlearning System: http://www.health-o-rama.org/superlearning

• Mansfield, Richard. Visual Basic 6 Weekend Crash Course. M&T Books, 2000

G.D. Warner is a Technical Writer, and has been using the Mac since 1992. He's been downloading and testing software during that entire time, first from local BBSes, then from the internet, and toying with programming (HyperCard, AppleScript, FutureBasic, ObjectBasic, C, C++, Visual Basic, and, of course, REALbasic). E-mail him at gdwarner@ricochet.net.