Re: Ideas for next Eu
----- Original Message -----
From: simulat <simulat at INTERGATE.BC.CA>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 08, 1999 1:17 AM
Subject: Re: Ideas for next Eu
> Hi
> I'm sorry to disappoint you Irv, but my posting was serious.
>
> I've already given an example of a "fluid" language (in the sense I'm
> talking about). Level 1 BASIC that ran (still does) on a TRS80 Model 1. It
> had lots of limitations, but it you didn't have to worry about whether a
> variable was local or global. They were all global. That language was
almost
> completely unstructured, compared to say, C. I wrote a lot of spaghetti
> code. Eventually I imposed my own structure by developing a structured
> programming style. I wrote some pretty interesting software on that
system,
> and some of it (a halftone exposure calculator) is still in daily use
> (though translated to GWBasic).
I also have several programs in daily use which were originally written
in BASIC for the TRS-80. Of course, they were re-written as soon as more
capable languages became available. Let's pick one as an example, call it
program "A"...
> Eventually I developed my own system for creating local variables and
> implemented it whenever I needed it. I had no trouble with having
variables
> global as a default. And this was on a system where the range of variable
> names was very small.
So you are doing, manually, what would otherwise be accomplished
automatically
using a more capable language. I also pity anyone who tries to read or
modify a
program which has, say, 741 global variables, as would program A.
> The problem with primitive languages wasn't how you used variables, it was
> just the lack of memory, and the limits of crude graphics that made me
want
> to move on.
True about the lack of memory, and crude graphics. However, the real problem
with program A was not memory or graphics, but how to read and write 741
variables to and from disk. You couldn't even read and write arrays, still
can't
as far as I know, much less declare a neat structure to manage that data.
> Euphoria is an excellent example of a fluid language, even if I do think
it
> could loosen up a bit. It's only got a few data types, you can make more
if
> you want, and as Lucius demonstrated, it's easy to make variables global
if
> you want. And sequences must be one of the most flexible data types going.
True, but it also lacks scalability. Program A, for example, needs to be
able to
store and retrieve those 741 variables for each day of the year over a
several
year period, and run weekly, monthly, and yearly averages, highs, lows, etc.
Oh, did I mention _quickly_? I haven't even tried this in Euphoria, because
it
lacks proper structured variables, and would require me to write my own
random access disk routines. Other languages have those built in.
> I'm self educated a computerist. I've tried hard, on several occasions to
> master C. I could get programs going, but I was never comfortable with it.
> The problem was the infinite data types, combined with the pointer based
> parameter passing. The simplest task seemed complicated and obscure by the
> time it was done.
I certainly agree on those points. The infinite data types require a lot of
annoying type casting. The pointer junk is a byproduct of C being a very
low-level language. Too bad they are still used.
However, by definition, all C variables are global, unless otherwise
specified. You should like that feature.
> Now that stuff is what I call programming overhead. It may be worth the
> trouble in some circumstances, but it is an expense. The question is "When
>is the benefit worth the expense?" The point I make is that in lots of
> circumstances the programming overhead has no benefit and is quite
> expensive. What's the justification for the expense in those
circumstances?
Euphoria doesn't use pointers. It does still require some type casting,
especially when you're dealing with Windows. I wish there were a way
to avoid that.
> So why is "global" equated with "ugly"?
Not ugly, just amateurish. It is much easier to write and debug code that
is short, clear, and self-contained, as opposed to code cluttered with
hundreds of non-relevant details and a minefield of potential side-effects.
If I want to write "for i = 1 to 10 do", I really shouldn't have to read the
entire program again to see if there is a global variable 'i' out there
somewhere which
shouldn't be clobbered. Or perhaps my routine calls a function during the
loop, now
I have to check that function to see if it, or any function it calls,
affects 'i'.
Too much backtracking, too much wasted time and effort.
> And how does forcing people to do things that aren't necessary, but are
> error prone, make programming easier?
I could ask you the same question. Global variables (excepting data that
must be available to all routines in a program) are both unnecessary
and error prone.
And of course, instead of declaring and initializing variables ahead of
time,
it's more fun to just write the program and spend the rest of your time
trying
to figure out why the dollar amount it prints on your paycheck this week is
"$%)@".
Regards,
Irv
|
Not Categorized, Please Help
|
|
