On Sunday, December 17th, 1995 - Evan Langlois wrote:
 
EL>  Hmm .. perhaps you missed the point.
 
Yes, I think I did.
 
EL> All variables spring into existence when used.  They are automatically
EL>  global unless localized.  Local variables do not interfere with any
EL> global counterpart.  Generally, almost all variables are declared 
EL> local at the start of a function, much like C.
 
Well, not to pick nits, but all variables in C are understood to be
local within the function in which they are defined without being
specified so, and are automatic variables unless specifically declared
static.  Okay, I know that you know that, just wanted that in there for
the record and for the benefit of those who will easily get lost by
reading along here...  :-)
 
EL>  In fact, C auto variables are stack driven, and may contain anything
EL> in them (junk) - where PERL local variables, also stack based, contain
EL>  whatever was in the global - so you don't get junk.
 
Two points here (again, not trying to argumentative or anything, because 
what you're saying is true, but...):
 
 1) Anyone that knows how to program properly in C, or any other
    language for that matter, will initialize all variables upon 
    declaration, whether they are local or global.  This is part of
    common "defensive programming" practice in general, and is always
    supposed to be done in all C programs - if you learned to write
    "professional" level code.  Any program plagued by garbage in
    unitialized variables has nobody but themselves to blame.
 
 2) The value left over from a global variable being reused as a 
    local variable in PERL is in fact GARBAGE and JUNK unless the
    programmer's intent is to pass the value to the local variable.
    :-)
 
 RR> now?  Pick two global variables and LOCALize them?  Sounds a little
 RR>  
EL> You don't have to pick globals - you just use whatever names you like.
 
Oh.  Okay.  I had it wrong.  From the way you described it, I assumed
that local variables in PERL were required to be the same names as
global variables used elsewhere.  My mistake.
 
EL> It's just like BASIC or a bunch of other languages.  The local 
 
Yes, good point.  I still enjoy Atari Basic on my Atari 800.
 
EL>  The PERL code was about 4 lines - try that with C !!  PERL integrates
 
Yeah, good point.  It would be a lot bigger unless one already had a
very extensive library of stuff like this that one had programmed
previously.
 
EL> time. C would just take too long to write and debug something like 
 
Yes, that's true - especially if you were starting over from scratch!
 
EL>  PERL fills a gap between the shell script and the C application - its
 
I am almost tempted to say that is what interpreted Basic was for!  At
one time, anyway.  :-)
 
EL>  Its not to replace C - it simply fills that middle ground. C++ is the
EL>  above ground :-)  Its for writting HUGE applications and managing all
 
Yeah, I agree.  That's what I need to concentrate on learning next. 
Well, that and x86 assembly language.  Sigh.  Not as straight forward as 
6502.  :-(
 
--- RiBBS v2.10        

[+/162 of 200/107 Mins] = * FIDO: ST_PROG =: Next...