---------------------------------------------------------
The Liberty Basic Newsletter - Issue #26 - Jan 98
  "The only stupid question is the one you don't ask"!
---------------------------------------------------------
"There's more than one way to skin a cat." - Part 2


Part 1 covered the big, general aspects of skinning cats.

In this part we take our gloves off and get into the specific aspects of
having more than one way to accomplish things.

Ahhh.  No.  I changed my mind.  There is a lot of information that
shouldn't be skipped over if you truly wish to understand.  I'll make this
into a three part article instead of a double header.  We'll get to the
details after the groundwork has been laid.

You may feel that all of this is unnecessary, and for some of you that may
be true, but if you ARE having problems, it could be that you don't have
the proper background.  Hang in there, we can correct that quickly before
moving on toward our goal.  I promise to have a few examples of code near
the end of this installment.

To begin with, you must understand that most computer languages have more
than one way to do things.  Within each way however, the lexical syntax of
the code you write is very rigid and cannot be altered.

In low level languages (assembly) there are FEW instructions to choose from
and you are confined and restricted to one way of doing something.  In high
level languages (basic) there are MORE of these predefined instructions.

The reasons for this might seem unclear to beginners, but having a bigger
list of keywords allows programmers to pick and choose the structure that
will do the job best.  After you have learned and practiced using these
structures many times, selecting the right one will become second nature.

By the time you're through reading this article, you should have a better
understanding of the reasons for this - and be able to use this knowledge
to your advantage.  Soon you will be thinking and speaking in basic - even
dreaming in basic.

The FIRST REASON; High level languages are able to use the functions and
services that are defined and written in lower level languages.  As each
new feature is added into a language it becomes easier to use and more
useful to more people.

The SECOND REASON is because there are many people involved in developing a
computer language.  From the top down, we have;

On the inside:
   The Concept Originator(s)
   The Financier(s)
   The Purchasing agent(s)
   The Researcher(s)
   The Specifications person(s)
   The Designer(s)
   The Programmer(s)
   The Code writer(s)
   The Technician(s)
   The Alpha tester(s)
   The Documentor(s)
   The Sales person(s)

On the outside:
   The Sales person(s)
   The Beta tester(s)
   The Application programmer(s)
   The End user(s) of products developed with this language
   The Competitor(s) products

All of the above have been appended with an (s) to indicate these positions
may be filled by more than one person.  In some cases, one person may fill
more than one position, and there may be several smaller niches (payroll)
in the hierarchy that haven't 
been listed.

The Concept Originator(s)
    The guy (or gal) who discovered a way to make something better,
    faster, easier to use, cheaper or more versatile.
    Something was missing from the language they were using at the
    time, or it would not allow them to do something the way they
    wanted so they started thinking about what could be done to
    improve the situation.

The Financier(s)
    The people with deep pockets that are convinced the project is
    worthwhile and figure out how they can all make a living at this.

The Purchasing agent(s)
    The ones that buy the things everyone needs to keep working.
    You know, computers, desks, ashtrays, coffee, pizza and rootbeer.

The Researcher(s)
    Gather information about anything pertinent, study, collate
    and then distribute the data to other departments.

The Specifications person(s)
    The people that lay out the specifications the language should
    adhere to.  Should they use Microsoft or IEEE math standards.
    Figure out how many usefull features can be included.

The Designer(s)
    Designers take the specifications to the blackboard and start
    pushing chalk.  What will it look like, how will it act, what
    will it do if this happens, what will happen if this button is
    pushed before that one.

The Programmer(s)
    Take the design and start planning things.  Decide what language
    THIS language should be written in.  Lay out the scope and par-
    ammeters that will be used.  Organize the plans into manageable
    size chunks and flow-chart everything so it will work.

The Code writer(s)
    The groovy dudes in the back room that put it all together.
    They toss out much of the work that has proceeded them, and
    start getting things done.  Along the way, they write a slew
    of utility programs, a batch of subroutines and hundreds of
    snippets.  All to be used latter in the testing and veri-
    fication phase.  Then they set up the initialization file,
    the rudimentary beginning code and then start working on the
    screen interface layouts and dialog boxes.

The Technician(s)
    Deal with the hardware aspects of the language.  Printer drivers
    and/or anything relating to physical properties.  Trouble-shoot
    these problems, figure out why something doesn't work right and
    explain hardware connection details to the code writers. 

The Alpha tester(s)
    In-house people that put the software through its paces.  They
    are continuously testing updates and new versions.  They make
    sure a problem is repeatable and not just a fluke, take notes
    and report back to the other groups.

The Documentor(s)
    Run the program step by step and write down everything as they
    go.  They explain what happens when each button or menu selection
    is made, try to give an overall description of the use of the
    language, make up the glossary, keyword table and appendix.

The Sales person(s)
    Make deals with computer stores and software-warehouses to sell
    the product.  Show off the language at conventions.  Give demos
    away and generally strive to make their product be the best on
    the market.

The Competitor(s) products
    It's true, the competions' products play an important part in
almost anything.  Competition is good.  It pushes us forward ...     you
know the rest.

Each of them provide usefull input during the languages life-cycle.  And
once it has started, this feedback process continues - unabated - clear up
to the point when the needs of most of those involved outgrow the original
conditions, and then someone else will come along with a newer idea and
start the whole thing over again.

All of them make suggestions.  Everyone wants to have their own ideas
included if possible.  Pecking order does carry some weight, but it's a
secondary issue.  It's up to the central core of people to decide what is,
and what isn't used.  Usually the good ideas find their way inside - and
the rest are filed.

This development depends on things like how big the bankroll is, how much
time they have, how gifted the staff is, what the weather is doing ... you
name it, the list goes on and on.

Think back over what you've just read, it's a bigger picture than you
thought it was.  And think about this too - Carl's trying to do most of it
himself.  I have great respect for this guy.

The THIRD REASON is because programmers are all different, each has their
own idea about how things should work.  They always want to have as many
choices as possible.  As many "WAYS" as they can to solve their problems.

The FORTH REASON is ... just because ... because it's natural ... because
it's normal for us humans to do things in different ways.  It would be a
pretty boring world to live in if there was only one way of doing things.
Everyone has a different perspective on how things should work.

Here kitty, kitty, nice kitty.  Meow?

The cat is out of the bag now and it's time to get to work.

Recently I've seen questions posted about the differences between the
"Decision-making" structures we have in Liberty Basic.  Good, I'm glad to
see you asking questions like these.  These are one of the fundamental
things you will be using over and over in your programs.  Hundreds, no,
thousands of times, so you really need to have a clear understanding of
them if you want your programs to be successful and work properly.

Be thankful we have three, I'm hoping version 2 will have at least one more.
Some languages have even more than four.

They are;
1. the  IF condition THEN statement
2. the  IF condition THEN statement1 ELSE statement2
3. the  WHILE condition : statement:  WEND

These are the primary decision making statements.
Each of these have secondary syntax structures which we'll get into in the
next part of this article.  Essentially, these are similar.  They are all
designed to allow you to ask questions and make decisions based on the result.

In the following examples, I use the word 'condition' to indicate a test, a
question, and based upon that test, the 'statement' will either be executed
or ignored.  Statement can be almost anything. Printing something,
calculating, or branching to another section of the program.

Example 1:  IF x = 5 THEN PRINT x

The question is 'Does the variable named 'x' equal the value of 5 ?
If x has been set to another value, nothing will be printed - but if x has
been set to equal 5 THEN the computer will print;  5 on your screen.

Example 2:  IF temp$ = "Stev" THEN PRINT "Stev"

The question is 'Does the variable named 'temp$' equal "Stev" ?
If temp$ has been set to another word, nothing will be printed - but if
temp$ is in fact equal to "Stev" THEN the computer will print;  Stev

If temp$ is empty, or has been set to "STEV" nothing happens because these
letters are in upper case.  "STEV" is not the same as "Stev"

You can ask all sorts of questions.  Besides asking if something is equal,
you can ask if two things are NOT equal by using  <>

Example 3:  IF x <> 5 THEN x = 5

You can also ask if something is LESS-THAN or if it is MORE-THAN something
by using  <  or  > symbols.

Example 4:  IF x < 5 THEN x = x + 1

What this did was ask if x is less than 5. If it is, then 1 is added to the
value that x contains.

The computer does not care what the question is, or what the following
statement is.  It ONLY answers the question you are asking.  It is up to
YOU to know what question to ask, and what statement to execute IF the
condition of the test is true or false.


4. the  IF condition THEN statement1  ELSE statement2
   Allows you to have two statements ready for the computer to execute
   depending on the true or false result of the test.

Example 5:
IF x = 5 THEN PRINT "X is equal to 5" ELSE PRINT "X does NOT equal 5"
Another word for ELSE would be 'otherwise'

We can also do several tests at the same time, and in several ways.
We could ask  IF x <= 5 THEN PRINT "Yes, x is less than or equal to 5"
Or            IF x >= 5 THEN PRINT "Yes, x is more than or equal to 5"

One way is to ask:
Example 6:
IF x = 1 OR x = 2 THEN PRINT "X is either 1 or 2 but nothing else"

Or:
Example 7:
IF x > 5 and x < 10 THEN PRINT "X is more than 5 and less than 10"
Or:
IF x < 5 and temp$ = "Stev" THEN PRINT "Both conditions are true"

A simple use of tests like this is to put a timing loop in your program.
Example 8:

x = 0
[timedelay]
IF x < 1000 THEN x = x + 1: goto [timedelay]

And, here's the flip side - WHILE condition : statement : WEND

Example 9:  WHILE x < 5 : x = x + 1 : WEND
This tells your computer to keep checking the condition of this variable
named x, and as long as its value IS less than 5 it should add 1 to its
value and then turn right around and check it again.  It is a conditional
loop structure.  If the condition x
 
< 5 is true, add 1 and recheck, otherwise go on to the next line of code
and proceed from there.

Example 10:  WHILE x < 10 : x = x + 1 : PRINT "Still counting" : WEND
Can you tell what this line will do?  Try it out.  If you leave out the
x=x+1 part, it will run on forever telling you that it is still counting,
but in fact it is only checking.  This is called a continuous hanging-loop,
an unfinished loop that will never end.

It doesn't matter if you put the x = x + 1 statement before or after the
print statement, it just needs to be somewhere after the condition test and
before the ending WEND.

WEND, in other words means  When condition is true END this loop.

Example 11:
x = 0
WHILE x < 1000 : x=x+1 : WEND

This does the same thing as the [timedelay] loop above but without using
bracketed target names and is quicker to write and executes faster.

I hope this has made it clearer to you.  You will need to practice using
these 'conditional' tests many times before it really begins to sink in, so
take the time you need.  Mess around with them as much as you want, study
the results closely and you will discover quickly that ...

"There's more than one way to skin a cat."

Part 3 will continue where this one leaves off, and take us into the
multi-statement-line styles of both IF...THEN ELSE and WHILE...WEND.
If time and space permit, we can delve into the mystical aspects of ...
are you ready ... conditional-branching and GOTO vs GOSUB.
Working examples and snippets will be included for you to play with.

Until next time, Stev


Another great article by Stev.  
I believe this newsletter needs more articles like this.  The more
experience we get, the more we forget the basics.  Well, we don't
forget them - its just that we do them instinctively and never 
consider explaining them to others, even though we sufferred 
through trying to learn these things ourselves.

I was delighted with the feedback that you gave to Stev for his
last article - and I hope to see a similar response from this one.

Thank you Stev

Coming soon to an Inbox near you:

	Skinning cats - part 3
	GDI for Dummies
	LB for absolute Beginners - Part 1

--------------------------------------------------------------
 Newsletter compiled and edited by: Brosco and Alyce.
 Comments, requests or corrections: Hit 'REPLY' now!
---------------------------------------------------------------
 
