Newsgroups: comp.sys.apple2
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!unlinfo.unl.edu!hoss!greg
From: greg@hoss.unl.edu (Life...)
Subject: Re: Lets sum up! (was: Apple II BBS discussion)
Message-ID: <1991Jun8.194653.18316@unlinfo.unl.edu>
Sender: news@unlinfo.unl.edu
Nntp-Posting-Host: hoss.unl.edu
Organization: GBBS/ACOS Sysop Support
References: <1991Jun8.035310.7362@clark.edu>
Date: Sat, 8 Jun 1991 19:46:53 GMT
Lines: 237

apollo@pro-hindugods.cts.com (Amrit Chauhan) writes:
>greg@hoss.unl.edu (Greg ????) writes:
>>apollo@pro-hindugods.cts.com (Amrit Chauhan) writes:

>>So we have come to the law of opinions.  What one runs is what is best for
>>that person.  No-one is suggesting anyone should change.  We're just
>>appraising the differences between the systems, so that a person so
>>informed would be able to make the choice that is right for them when
>>buying a new system.

>I think that it's pretty inevitable that people will take things to heart
>here.  Yeah, we have our opinions, but it's human nature to REALLY stick by
>them and a little opinion like that doesn't hurt.  We all know that we're
>only defending aspects of each system.  A little interjecting opinion is ok.

>>However AppleSoft becomes very cumbersome and difficult to navigate as the
>>program's size increases.  Numbers become numbers, instead of pointers to
>>important routines.

>AppleSoft is not the BEST programming module on the market.  It's got its
>difficult points, but it doesn't have ANY bugs.

I must say here that even Apple has admitted that there are some bugs in
AppleSoft.  One of them I believe is the handling of the ON NOCAR GOTO
and RESUME commands.  They are documented.  I believe they are repeated
for compatibility reasons.

>ACOS does have bugs.  That's
>a bit of a setback for it.  Yes, ACOS makes adding MOD's easy and fixing
>programs much easier than in AppleSoft BASIC.  If ACOS gets out its bugs
>(like in future updates) it will be a very capable program editor.

Every large program has its bugs.  It is just whether or not you can
find them.  Some bugs are completely dormant, because due to changes in
the code they are no-longer in the instruction chain.  Arcade games
sometimes have bugs, simply because the programmer couldn't get to the
levels where the bugs manifest themselves.

Too bad Lance needs the remote sysop to track down a bug so that it is
reproducable before he'll try to fix it.  He won't bother trying to
duplicate the system on another.

>However,
>although MD-BASIC can be run only on an Apple //gs, let's not forget how
>powerful it is.  If, in fact, you have an Apple //gs, and you want to
>seriously rework ProLine, then buying MD-BASIC would not be a horrible idea. 
>You don't have to use for ProLine ONLY mods...there are those that buy it for
>their own programming needs.

Yes.  From what I've been able to get out of the manual, it is a rather
good programming language.  As it is now, I might as well have a //e,
since I don't have a good setup to look at the language as it runs.

>Have we done any comparisons between MD-BASIC
>and ACOS yet?  Put aside the fact that it can only be run on an Apple //gs,
>and let's look at both program editors.  We're all aware that it can only run
>on an Apple //gs.  That's unfortunate, but all the same, a reality.

Which is why I recommend to Morgan to work on a ProDOS 8 version of
MD-BASIC.  Why should the IIgs users have all the fun? :-)

>One other thing.  NO program in ProLine needs to be rewritten.

Unfortunately I find the need to get it to run under 2 800K volumes (one
/RAM5).  That involves a rewrite of some routines.

>If you wanted
>to write your own additions to ProLine, ok.  If you wanted to add a little
>MOD to this little program, then that's great too.  But no one ever, EVER has
>rewritten a program from scratch.  There's no need to.

Certainly not.  My system isn't a complete rewrite of GBBS "Pro".  It is a
large amount of modifications and enhancements.  However through the
course of time the amount of unedited GBBS "Pro" code has reduced.  It is
possible that eventually it could vanish.  This does take time.

>>Already have [MD-BASIC].  However it does add to the cost.  A time delay
>>doesn't decrease the cost.

>It doesn't
>have to add to the cost of ProLine.  MD-BASIC is not a ProLine only program
>editor.  You can buy it for other programming needs as well.

True, MD-BASIC stands well on its own.  However ProLine stands much better
with MD-BASIC.

>>>If you want to make a few MOD's,
>>>then just use AppleSoft.

>>MODs, or additions?  There is a difference.

>Both.

Looking back, "a few" mods would be possible.  Would splitting the root
directory fit that?  Perhaps the word "minor" would be appropriate in
there somewhere.

We'll leave file xfer out of the discussion.  Thinking about it more
carefully, the stock systems may be about equal in this regard.

>>>GBBS's message base really
>>>SUCKS. ...
>>>          ProLine has an EXCELLENT message base...GBBS doesn't even have a
>>>competitive one.  IT REALLY SUCKS for messages.

>>Give some reasons.

>Ok..I'm being a bit obnoxious here.  Sorry.  1) ProLine has GREAT networking
>capabilities (regardless of if you WANT them or not).  2) Both GBBS and
>ProLine can have message bases in separate partitions.  3) ProLine message
>bases can also be put into an 800K disk. 4) GBBS has bugs in the message
>base, to my understanding.

The only bit I can disagree with is the last point.  The "bug" I am
familiar with is if a message base is configured with the wrong capacity
for the number of messages.  For n messages, one needs to tell it to
create a file capable of storing (4*n)K.  The CONFIG program doesn't
properly default to that, and so when the K limit is reached, messages get
trashed depending on their proximity to the storage bitmap.

>I, PERSONALLY, don't like ANSI, or
>animation unless I'm playing an on-line game.  Then, I'm prepared for the
>slow screen updates, and I don't mind because if the game is good, I'm having
>fun.  As far as message bases go, I agree that graphics don't belong there. 
>Games, as you stated, are a GREAT place for color graphics.  ProLine does NOT
>have this option.

Here we are in agreement, more or less.  However, a graphics "movie
theatre" is a nice place for those who are creative enough to make nice
movies to put them, so as to prevent emulation crosstalk when reading
messages (since the graphics have been relocated).  (Real fun when you
receive a PSE ^N for normal text when in a VT-100 emulation, where it
will put you into a graphics mode, where lowercase letters are redefined.)
I use extensions on the subject lines to indicate graphic messages, and if
the extention does not match the emulation, a warning message is printed
with the ability to skip the message.

However I have not fully implemented this due to the allergic reaction an
older version of ACOS had to some 8th-bit ASCII, causing random holes to
be created in .S and .G files.  I had to salvage what I could and
reconfigure.  I'm still hesitant to attempt it again, even with the new
ACOS.  It felt like when I discovered my drive was nuking key blocks on my
disks, like block 2.  Required total interior replacement.  Anyway, I'm
digressing...

>>>Can GBBS do something useful
>>>with special effects?...like maybe a full screen text editor?

>>Definitely.  Such a thing already exists.  However I don't use it.  I have
>>other modifications that are more important to me right now.

>The full-screen text editor available on ProLine is a GREAT option.  It makes
>things easier to edit, and I'm using it right now to add this message.  It
>has it's SMALL downturns but it works well.  I like it.

The reason I don't use the ACOS full-screen editor is that it isn't just a
text editor, but also a graphics editor.  Since it is designed for ProTERM
Special Emulation, it will allow inclusion of graphics where others
couldn't, due to their generic nature.  This make them more useful for
more users, but limits what unique things each user could do, if it was
designed specifically for them.

This is both an advantage and a disadvantage for both.  It depends on the
sysop's feelings on the subject whether or not it is desireable.  For
myself, it gives me less control on filtering out emulations for those who
don't have them.

>>What happened to your manual?

>For the Ampersand commands...I don't have the manual.

Ah, I understand.  (THAT'S what that 4th registration card was for!
Thanks for jogging my memory.)

>>>2) have about 4 to 5 times as many network bridges
>>>than GBBS.

>>Networking is not the sole reason to run a BBS.  If every BBS was
>>networked, you'd effectively have only one BBS.

>Fine.  We understand that networking is not the only reason to run a BBS. 
>But, like you said, we're only offering comparisions between the two systems.
>ProLine has a better networking system than GBBS and just because you don't
>want to network doesn't invalidate that point.  If you want to network, then
>ProLine is better than GBBS in this aspect.

Agreed.

>Now, what can ACOS do that MD-BASIC can't and
>vise-versa?

It can be used online.  You can load up a segment, edit it, save it, then
run it.  It is automatically compiled and run at that time.  You can code
AppleSoft online with ProLine, but you can't with MD-BASIC.  Shell scripts
are a nice compromise, but still not full coding ability.

Vice-versa, MD-BASIC is a good tool for creating programs.  You can create
programs which can execute by themselves, without the need of an
underlying system like ACOS.  Plus, you can use your favorite BASIC -> ML
compiler on the resulting code to make it run even faster.  No such tools
exist to make ACOS files into ML files... at least, none that I know of.

Then again, ACOS was designed to be used as a language for communications
-- it is part of the name.  MD-BASIC was just applied to that field, not
designed for it.  That is the root of the conflict.  They were designed
for different purposes.

Even if I never run ProLine, I would still use MD-BASIC (as soon as I get
at least a second 3.5" drive :-).

>God...it's tough to include your signature :)  How are the attributes this
>time?  I think I got it.

Signatures are usually edited down to just what is needed.  For mine,
you'd only include the last line, since that is the only important
information in it.  However one only includes the previous poster's
signature, not any of those previous.  The reduction is shown in the
editing I made of yours:

>Amrit
>ProLine:apollo@pro-hindugods     | Internet:apollo@pro-hindugods.cts.com     |
>UUCP: crash!pro-hindugods!apollo | ARPA: crash!pro-hindugods!apollo@nosc.mil |

But, one can do without the previous poster's signature altogether.  I
include only the alternate email paths available.

The best way to think of inclusion is the taking of the message being
replied to, adding a > at the beginning of every [non-blank] line, adding
an attributation at the beginning in standard form, and then editing.
Everything else is up to the human in the editor, and whether the system
is configured to add a signature at the end.

--
///   ____   \\\ "The major problem--one of the major problems, for there are
| |/ /    \ \| |       several--one of the many major problems with governing
 \\_|\____/|_//            people is of whom you get to do it, or more to the
greg \_\\\/ hoss.unl.edu    point, who gets people to let them do it to them."
