Malcolm McLean wrote, On 21/01/07 17:11:
Since your language does not even include subroutines any book on how to
learn using it would be something I would recommend people avoid.
I don't know.
For instance in the bioinformatics course we taught people to program using
Java. The problem was that, for many, object-orientation was a step too far.
Or then again the OP might be able to learn all that you can do in your
Basic in under a week, in which case it would be a complete waste of
time because the following week the OP would have to switch to a new
language to progress.
For instance I once told a girl to reverse an array, and she just looked at
me blankly. The idea of doing something in a unit hadn't sunk in.
So? That does not mean that the OP is like that.
Another important point is that the source code for my Basic is available,
and relatively short and readable. So it helps to demystify the tool.
I would be surprised if people having difficulty writing programs long
enough to need to be broken down in to subroutines are up to
understanding a BASIC interpreter.
In conventional Basic subroutines are pretty unusable
That's odd because in the first significant program I wrote, which was
in BASIC on a Commodore PET, I made a lot of use of subroutines. Of
course, later (or may be earlier) BASIC implementations added procedures
which improved the language no end.
> because there are no
local variables, no way of passing parameters, and the line system means you
cannot cut and paste code between programs.
The above makes them less useful but by no means makes them unusable.
So most Basic programs
were written without them.
May be most programs you write, but as soon as I was beyond about 10 or
20 line programs all of mine made use of subroutines until I moved on to
languages with better facilities.
> The programs were short enough for it not to
matter over much. In the fact the number of times you need to execute the
same code from two places in the same program is limited, with the exception
of highly reusable routines like sine which are provided.
Abstracting code in to
subroutines/functions/procedures/modules/objects/whatever is not only
about reuse it is also about managing complexity. It is often easier to
understand an N line program when is broken down in to M functions even
if each function is only called once.
I've got a whole list of useful program written in Basic for BASICdraw
Well, since your implementation does even include subroutines the only
thing I would use it for is illustrating what a programming language
should NOT be.
