[Coco] C VS Basic Coco

[Wayne Campbell]

Basic09 brings a lot to the table. First, what numbers are allowed, but not
necessarily required. The requirement of line numbers applies only to the
use of GOTO or GOSUB statements. In this regard why numbers are more like
labels then they are actual numbers. That said you cannot use text and are
restricted to using numbers, so in that sense they are actual numbers. When
it comes to writing the code, any text editor will do. Indentation is
allowed, as all blank lines separating sections of code. Basic09 will strip
all leading spaces when you load your source into it. Basic09 also has
structured elements, such as WHILE, REPEAT and LOOP loops (and FOR/ NEXT),
ON <expression> GOTO/GOSUB flow control, ON ERROR GOTO error control, and a
handy IF/THEN <line reference> branch control. You can select base
numbering using BASE 1 or 0 for arrays, which have 1, 2, or 3 dimensions.
Basic09 also has record structures (known as complex data types) which
allow you to work with data beyond the simple data types (BYTE, INTEGER,
REAL, BOOLEAN and STRING). Strings can be variable length, up to 32767
bytes. Instructions can be longer than 255 characters, but statements
longer than 255 will not be displayed correctly in the editor. Code can be
"packed" into I-Code modules (intermediate code) that are executable and
are handled by the runtime program RunB. This allows for faster execution
and easier distribution of programs without having to distribute the source
code. There is much more. I suggest reading the  Basic09 manual.

Wayne


On Feb 14, 2018 6:37 AM, "Lee" <leep at tigerbase.com> wrote:

> "*What's hard to find about that?*" - Find? Nothing's hard. Understand what
> "5000" means?  Impossible without reverse-engineering it (i.e. reading the
> code).  Keeping in your head what routines at what line numbers do for
> large program with 1000's of routines is not something I could do. :)  Well
> (descriptively) named routines and variables can go a long way to making a
> program more easily understood and maintained.  You may understand what
> "5000" means now, but another developer looking at it probably won't, and
> the you 5 years in the future might not either.
>
> That said, I agree that the curly brackets don't necessarily add to the
> readability.  Proper indentation, naming of routines and variables, and
> spacing between routines can go a long way.  Unfortunately, CB/ECB/DECB
> doesn't allow for indentation nor naming (2 letters in no way allows proper
> naming).  I'm not familiar with Basic09 to know what it brings to the
> table.
>
> On Wed, Feb 14, 2018 at 8:02 AM, Francis Swygert <farna at att.net> wrote:
>
> > From: Scott Wendt <malfunct at msn.com>
> >
> > I don't want to stir up any arguments, because whatever language that
> gets
> > the job done and is the one you want to use is the one you should use,
> but
> > I think the things that make BASIC easy to get started with are the same
> > ones that makes it poorly suited for complex projects.
> >
> > A lot of the extra "stuff" in structured languages are there to represent
> > program structure and does really lend to the readability and
> > maintainability of large complex projects. For me personally brackets and
> > indentation are super important for identifying logical blocks of code.
> > ==============================================
> > I find that amusing! I've never coded in anything but CoCo BASIC, but
> have
> > followed and modified some C code... with explicit directions on what to
> > modify and where.
> >
> > I find the use of brackets and indentations MUCH more confusing than well
> > coded BASIC with line numbers. Part of you know what you learn, I guess.
> > Unless you really packed BASIC code, subroutines generally start with a
> > whole number (like 500... with a "GOTO 500" to go to that routine).
> What's
> > hard to find about that? I've seen some long, packed lines of BASIC code,
> > and some packed programs that seem to just number from 1 to whatever and
> > use every line, but those are either poorly coded or packed to get the
> most
> > out of available memory. Those packed programs can be hard to follow, but
> > once you identify the sub routines and their line number range you're
> > pretty much done. You might want to go through that Apple BASIC program
> and
> > do that first. I've not coded anything in a LONG time.. to the point I
> > don't think I could now. But I did use some GW BASIC program as a guide
> to
> > writing a complex CoCo3 program (had to do an all but total re-write, not
> > really "converted"). I made an ASCII text listing of the GWB program and
> > divided it up with spaces into the separate routines to make it easy to
> > read, then tackled each routine one by one when possible (some were
> > dependent on others and couldn't be tested separately, of course). You
> > might try that... or use spaces and brackets to separate the listing if
> you
> > find that easier to work with. I just don't understand the placement of
> the
> > spaces and brackets... no misunderstanding line numbers!
> >  Frank Swygert
> >  Fix-It-Frank Handyman Service
> >  803-604-6548
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
> >
>
>
>
> --
> Lee Perkins
> TigerBase Technologies
> leep at tigerbase.com
> ------------------------------
>
>
> *[image: Hampton Roads .NET Users Group]2nd Tuesday of every month. Come
> meet, learn, network and eat pie!
> <http://www.meetup.com/Hampton-Roads-NET-Users-Group/>*
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>