Re: Making vars local by default

["Russell Y. Webb" <rw20@...>]

> No. In both versions failures are depending on
> the situation. In both versions the failure can
> be long hidden or found immediately.

That's true as stated.  But most of the time the one that by definition
creates potentially latent coupling mechanisms between disparate modules
will create bugs that require analyzing more source to fix and are therefore
more of a pain.  

In my programs I would hazard to guess that I use 10-20 times as many locals
as globals.  I think that's true for at *least* 90% of us (OK, Lua as
configuration language people excepted, as I've said before those people
need it the other way --- what a predicament), so local by default makes
since --- it's what we usually mean.  Right now I have to declare locals
explicitly contrary to every other language I use (which does matter since I
have to use other languages, one reason I use PHP more than Python is that
switching to it from C requires less mental effort) and missing a "local"
(which is easier to omit than accidentally typing "global") creates code
that can break later in some baffling way at some unexpected point.

> In small programms global vars by default are welcome
> because you don't have to worry about variable scopes.
> Use them and its ok.

You do have to worry; once collision occurs let's see a novice or
non-programmer fix it.  The fact that experienced programmers like John are
creating tools to analyze the global space is spooky.  Why should they have
to do that?

> In big projects global variables are also welcome
> because you don't need to declare it global again and
> again in each function who need them. Instead you
> declare the locals because you use them only here
> and once.

Again, no one has ever said that PHP is a good model for scoping.  There are
lots of choices: have to use 'global' for all globals, have to use 'global'
only to get write access to a global (my favorite), use a function to write
to globals (also good), have to use both 'local' and 'global' all the time
and if the local is not defined reads and writes go to the global (as in C),
... the list goes on and on.  Picking the poorest choice and shooting it
down does not really address the issue.

> You can program errors in each situation. It can't
> not the job of the language to prevent errors.

Have any idea why no one (well almost no one) does serious work in Forth?  I
personally like Forth, but would never use it for something complex because
it's too easy to create errors in.

> Almost all other languages aren't as good as Lua is.
> Other languages are not reference. I hate this type
> arguments: most do it so it most be done so (or: so
> it must be good). Its possible that all do the right
> but *others do it so* its not the argument.

Why aren't Divorak keyboards more popular, why not put the turn signal lever
on cars in strange places, or why is Java big deal when Smalltalk 80 was
more of a write-once environment?  It's not what people are used to.
Switching is too hard.  Yes, we should break from the past when there are
large improvements to be made, as Lua does in many ways with success.

> Unfortunatly in the last weeks I programm only in php
> and I think globals by default are a pain.

PHP's globals do suck.  Let's quit thinking they might be an acceptable
model.  They are a huge pain and it would be terrible to make Lua like PHP.
we could get rid of destructors too if we thought PHP was a good language.
There are other options.

All that said, I think most of the needs of those of us in the "I use locals
more than globals why isn't it the default" camp can be served by writing
tag methods for the global table to prevent writes and using a function to
write to globals.  The problem is that then we have to say, "I'm not going
to use standard lua source."  If global("name", value) or the global keyword
(preferred mainly because it looks like part of the language) were part of
Lua then at LEAST our anti-global-write code could be used by standard Lua
and if it turned out that most everyone liked it that way it *could* become
the standard one day (or remain a compatible variant that can't use standard
Lua code but can be used by people in the main camp).

I'm just looking for a way to serve more people's needs without adding too
much complexity.  Does that make sense?

Of course the Lua authors would be the right group to endorse the global
keyword or function for a compatible anti-global-write variant.  The other
choice being that we should create an anti-global-write standard written in
Lua that uses global("name", value) so that if that function is added to Lua
one day our code would work with standard Lua (abet without the
anti-global-write checks).

Russ