Re: Ideas for next Eu
Hi
The programs I write are pretty self-contained; that is, there's no
interaction with the user. In that context, it's kind of a nuisance to not
be able to modify global variables from inside functions. Here's an example.
I have a sequence called "tiles" that holds a bunch of bitmaps. The bitmaps
are manipulated by placing tiles[x] onto the screen and then drawing on the
screen then saving the screen to tiles[x] again. Sometimes, the functions
that accesses tiles are deeply buried within strings of other functions. I
end up having to pass tiles through a bunch of functions that don't use it,
just to make it available for one that does (but that might not even be
called), and then I have to pass the modified value back up the chain. I
think this is less than elegant, maybe even ugly. It's certainly a hassle.
It would be a lot easier if there was just a way to modify the global
variable.
OK - I admit it - I learned to program on something called "Level 1 BASIC".
All the variables were global. Variable names could be up to 2 characters
long. I found that if I needed a variable to be local that it was easy to
do, but that it was rarely necessary. It didn't take long for me to
appreciate the benefits of structured programming and I found it easy to
implement in that completely unstructured environment.
I understand that when programs are written by large teams, and when
software is used by many people at once, extreme efforts must be taken to
protect data integrity. But that's not what I'm doing. I write programs that
make pictures. It's no big deal if it crashes - it's not like it's
controlling an airplane or anything. I find that the subtle logic bug is
rare, but that the crashes caused by the safety features of structured
programming (like not letting functions modify global variables) are a
constant hassle.
I like Euphoria. It works just perfectly for the kind of programming that I
do. One of it's benefits is that it has very little programming overhead.
Personally, I think that "beauty" would be found by making the language
looser and more flexible. There are lots of languages around that are rigid.
Bye
Martin
>From: Brian K. Broker <bkb at CNW.COM>
> On Fri, 5 Nov 1999, Darth Maul wrote:
>
> > You know how in Q(uirk)Basic, all values are passed to FUNCTIONs/SUBs by
> > reference? Maybe you should add a 'byref' keyword so that variables are
pas-
> > sed by reference. This would make porting progs from QB to Eu a little
> > easier.
>
> Ick! IMHO it is a poor practice to have variables passed to a sub or
> function be globally changed by that sub or function. Besides, you
> can already easily accomplish that same effect by declaring your
> variables outside of your subs/functions (then you don't even need to
> pass them). There is more than one way to get around your porting problem
> than to introduce that ugliness into Euphoria. But again, that's just my
> opinion.
>
> Can you provide a better reason for this inclusion (besides making it
> easier to port poorly written QB progs)?
>
> -- Brian
>
|
Not Categorized, Please Help
|
|
