#GFA-Basic
4 messages in this thread
Other than the 512K limit, and SOUND bug, what else don't you like, or more
to the point, are there other bugs that you've discovered?
Well, there were several things. One was that I could not get gadgets and
such to work reliably. However, that may be due to the memory management
problems. EXTEND, the basic extender, has just announced a revision which
they claim will work with both GFA and HiSoft, so perhaps that problem will
be resolved. I also didn't much care for the editor. Although I do like
the auto syntax, keyword caps, etc. features, the editor is difficult to
work with and should be more Amiga-ized! I guess aside from that it's
pretty good. I would have implemented different symbols for variable
typing which would have been similar to other basics. They also
desperately need a working conversion program. The one supplied only works
for small programs, but cannot convert large ones. Oh, yes, the editor
fails to recognize a couple of keywords when loading in a .LST file. The
keywords are recognized in the .GFA file and the program will run, but
there is a small bug there, which I communicated to them a while back. I
was also disappointed that the compiler hasn't arrived. All these
considered, GFA was a nice implementation. When they get the major
problems straightened out, GFA will be a good basic language, provided they
get the compiler for it. Unfortunately, I had to convert my stat program to
HiSoft, and since that program is now fairly well developed I doubt I would
want to re-convert to GFA. Course, HiSoft has its problems, too. I
doesn't support the CON: device in the OPEN statement! A major screwup!!
Neither HiSoft nor GFA could be truly considered finished products. They
both need a lot of work. But when they both get their respective acts
together, they will be welcomed replacements for AmigaBasic which is so bad
that it isn't worthy of comment! Ultimately, these compilers need the
sophistication of the CBasic compiler from the old CP/M machines. Now
there was a great Basic compiler.
I have heard mega replies about how bad AmigaBasic is. IMHO its not bad,
just DIFFERENT. I have been programing in basic on many platforms,
including mainframes for the last 14 years. I have worked in at least 8
dialects of basic. I must admitt, all of my programs are research or
business related, or in other words, no games. I currently have 5 A2000s,
using AmigaBasic, compiled , competing against a VAX, PS/2s, and various
other 386 equipped machines. I work at least 12 hours a day, using
AmigaBasic on programs that are HUGH. My only gripe is the lack on a
search and replace. Oh by the way, my AMIs are kicking the S*** out of the
other systems. All in a basic dialect that is so bad that it isn't worth a
comment.
Jesse, I think the perceived shortcomings with AmigaBasic are valid. These
are the ones I know of:
1 – The use of the upper Address bits in address registers causes the
software to fail on processors other than the 68000 if memory above 16 meg
is decoded (normal for a 68020, for instance). This was stupid, ie Bad.
2 – The program crashes often, steps on low memory, and just generally
doesn't restore the Amiga to the state it was in before AmigaBasic was
invoked. Not a particular basic program, mind you, just AmigaBasic itself.
3 – The editor is incredibly slow, as are all requester operations, in a
machine with probably the fastest window managment of any reasonbly priced
micro. This is due to lack of care on the part of the programmers. Other
window/refresh modes are available, they just were to lazy to do it _right_
4 – There is no compiler unless you go to third parties.
All of this in mind, AmigaBasic is VERY fast – for an interpreted basic –
and it's reasonably flexible. It's also free, which is not to be sneered
at, except possibly to note that it's easily worth more than it costs. 🙂
Finally, it's not been updated since approximately the pre-cambrian era,
not something you like to hear about the tool your doing important work
in.