Using GFA Basic In 2016

[Mikefulton]

At the risk of starting a religious war... or at least another battle in the ongoing one...

I've been reading the messages in this forum section, and it's got me thinking.

First, let's be clear about something. I enjoyed using GFA BASIC back in the day. I bought it as soon as it hit the store, and I was as annoyed as anybody when there were compatibility problems on newer and different hardware like the Falcon030.

But here's the thing... I don't really understand why anybody would want to write new code in GFA BASIC these days. It seems to me that whatever advantage there was to using GFA BASIC for some projects back in the day, most of the reasons don't really apply any more. And given the well-known compatibility problems that GFA has with non-vanilla hardware, I just don't understand why it seems to retain so much popularity.

One thing people used to tell me back then was that they used GFA BASIC because it was affordable. Granted, that was a significant factor back then for many users, when something like Lattice C might be a couple hundred bucks while GFA BASIC was more like $60-$80. But these days you can get the GCC tools, or Lattice C, or Pure C, or pretty much anything you want for free, so cost certainly isn't a factor any more.

Back in the day, I used to hear people make the argument that they were able to get things done faster in GFA BASIC. There's a certain amount of truth in that, but I think it's a misleading truth.

If you haven't ever done anything with C, then yeah, you're probably going to get results faster with GFA BASIC instead. I mean, it's pretty obvious. You run the GFABASIC program, type a few lines of code into the editor, hit "RUN" and BANG! you've got some results that might even do what you wanted. By comparison, doing anything with C or Pascal or Assembly, for example, is going to require you to do more work before you get anywhere.

However, that advantage starts to disappear once your programs get to be longer than a few lines. The larger your project gets, the more the advantage starts to swing the other way towards something like C or Pascal. Things like code reuse and building an application framework are much more practical in those other environments. And yet, I keep reading threads about people creating some surprisingly large and complex programs in GFA BASIC.

I guess if there's a question wanting to escape from these thoughts, it's this: Why use GFA BASIC instead of something else?

[GokMasE]

If the alternative to GFA is not to code, I guess GFA can be considered a better option?

Being strictly a hobbyist coder, doing it all for fun, the syntax of C has always kept me away. Too much about it is too far from intuitive and messy looking - at least for someone used to a more tidy and clean syntax, albeit not as powerful. And the fun part is vital to still wanting to do things with code in my case. I can vaguely understand snippets of C, but always felt that the threshold to getting anywhere with using it myself would be way too big and require efforts and time better spent on fun stuff. Like coding. So I guess one might say it is the fun factor that settles this. C just doesn't look fun enough for someone that knows his way around GFA.

That does of course in no way make me any less grateful that there are skilled C coders around in our platform in 2016, still doing nice stuff. At the end of the day my opinion is that rather than discouraging anyone doing creative stuff in GFA it might more sense to enjoy the fact that complex and potentially cool stuff is still being written. Even in 2016.

In a way, one might even consider it suitable to involve an ancient language when dealing with ancient hardware

[lp]

At the risk of starting a religious war... or at least another battle in the ongoing one...

Don't worry, it won't get out of hand and end up a locked thread.

I've been reading the messages in this forum section, and it's got me thinking.

Since I still maintain GFA unofficially I'll try and answer best I can.

First, let's be clear about something. I enjoyed using GFA BASIC back in the day. I bought it as soon as it hit the store, and I was as annoyed as anybody when there were compatibility problems on newer and different hardware like the Falcon030.

What you say is true, however you might be unaware of my updated GFA BASIC package. It's fully compatible with the old GFA, but it offers a new tasking editor, which means a better work flow. You can build and tweak a RSC file while coding, etc. It offers new features and the compiler support is built in. It also supports the coldfire, which the original GFA fails at. The interpreter is actually a separate process and if you crash and its not to severe the editor is still there with your source intact. It's a huge improvement over the way the old GFA works, it provides a full IDE. However, this updated GFA requires MiNT and thus a fairly fast Atari or clone.

But here's the thing... I don't really understand why anybody would want to write new code in GFA BASIC these days. It seems to me that whatever advantage there was to using GFA BASIC for some projects back in the day, most of the reasons don't really apply any more. And given the well-known compatibility problems that GFA has with non-vanilla hardware, I just don't understand why it seems to retain so much popularity.

I provide an updated library with many bug fixes. The old library has been fully dis-assembled, fixed and rebuilt from the ground up. I do not patch any of the files, this is true also of the compiler and linker, both rebuilt entirely from source. The same bug fixes are also applied to the interpreter, so you see the same results when compiled.

One thing people used to tell me back then was that they used GFA BASIC because it was affordable. Granted, that was a significant factor back then for many users, when something like Lattice C might be a couple hundred bucks while GFA BASIC was more like $60-$80. But these days you can get the GCC tools, or Lattice C, or Pure C, or pretty much anything you want for free, so cost certainly isn't a factor any more.

I do use PureC myself, but only when the context of the project forces me to, otherwise I use GFA. I guess its just my preference and I don't have to deal with a make file for simple projects.

Back in the day, I used to hear people make the argument that they were able to get things done faster in GFA BASIC. There's a certain amount of truth in that, but I think it's a misleading truth.

This can still apply, but it depends heavily on what you are doing. The GFA compiler does do a nice job, and one reason it does fly is the parameters passed to built in functions are register based.

If you haven't ever done anything with C, then yeah, you're probably going to get results faster with GFA BASIC instead. I mean, it's pretty obvious. You run the GFABASIC program, type a few lines of code into the editor, hit "RUN" and BANG! you've got some results that might even do what you wanted. By comparison, doing anything with C or Pascal or Assembly, for example, is going to require you to do more work before you get anywhere.

I don't think we get a lot of new GFA coders, maybe occasionally. But I still hold that belief that every system should have a version of BASIC, so newbies can get their feet wet, that's why I maintain it. Perhaps they will move on to C later. Since GFA now works on the firebee, I suppose it might seem attractive to some.

However, that advantage starts to disappear once your programs get to be longer than a few lines. The larger your project gets, the more the advantage starts to swing the other way towards something like C or Pascal. Things like code reuse and building an application framework are much more practical in those other environments. And yet, I keep reading threads about people creating some surprisingly large and complex programs in GFA BASIC.

My updated editor can INCLUDE files. If others use this feature I don't know, but it can do it. The updated GFA editor has a pre-processor pass at compile time that allows you to do some new stuff the old editor can't.

I guess if there's a question wanting to escape from these thoughts, it's this: Why use GFA BASIC instead of something else?

It might simply be personal preference. I find 'C' to be not very intuitive and the compiler errors cryptic at times and I try to avoid make files, but I started out with GFA back in the day.

Best viewed at full resolution:
https://www.youtube.com/watch?v=LHw7t7UGKmI (68k/coldfire building)
https://www.youtube.com/watch?v=CXjQ8zyp9Wo (assembler options)

[Mikefulton]

If the alternative to GFA is not to code, I guess GFA can be considered a better option?

Being strictly a hobbyist coder, doing it all for fun, the syntax of C has always kept me away. Too much about it is too far from intuitive and messy looking - at least for someone used to a more tidy and clean syntax, albeit not as powerful. And the fun part is vital to still wanting to do things with code in my case. I can vaguely understand snippets of C, but always felt that the threshold to getting anywhere with using it myself would be way too big and require efforts and time better spent on fun stuff. Like coding. So I guess one might say it is the fun factor that settles this. C just doesn't look fun enough for someone that knows his way around GFA.

That does of course in no way make me any less grateful that there are skilled C coders around in our platform in 2016, still doing nice stuff. At the end of the day my opinion is that rather than discouraging anyone doing creative stuff in GFA it might more sense to enjoy the fact that complex and potentially cool stuff is still being written. Even in 2016.

In a way, one might even consider it suitable to involve an ancient language when dealing with ancient hardware

It wasn't my intention to discourage anybody from anything. I was just wondering how they came to their decision(s).

What you're saying about "the syntax of C has always kept me away" is definitely a thing, but it's something that goes away for most people as they work with other programming languages more and more.

Most people, when they start programming, end up with their brain trained to think of programming in terms of the syntax of whatever language they were using at first. In your case that may be GFA BASIC. When you try to do something in another language, the problem you're attempting to solve gets somewhat lost in the translation of the syntax.

However, my own experience, which seems to match that of other programmers I've talked to, is that as you work more with other languages, your brain starts to think about problems at a higher level, with more generic programming constructs instead of the specific syntax of a particular programming environment.

That is, you start to think "This needs a WHILE loop" instead of specifically "This needs a GFA BASIC WHILE loop".

[siriushardware]

Outrageous confession: I bought GFA Basic back when the ST was current, mainly as a reaction to how bad and slow the supplied BASIC on the Atari language disc was. But, somehow, I never got around to learning it properly. I may even still have the discs and manual somewhere.

I think the main problem was that the PC was by then in the ascendancy and so I took the plunge and bought PC QuickBasic, the compilable 'Full version' of QBasic for DOS, and ended up using and understanding that a lot more.

To this day, when I have a little task which requires user input and screen output it's still BASIC that I reach for - C, for all its power, is what I have in the past often called a 'write-only' language because it looks so horribly un-English and unintuitive.

Don't get me wrong, I do use 'C' for programming microprocessor projects, especially if it involves maths which can be something of a headache in assembly language on 8-bit microprocessors.

I agree with LP that every computer needs a good version of BASIC, or at least a similarly high-level, easily readable language.

Probably the closest thing there is to a cross-platform BASIC-Like language is Python which, thanks to the Raspberry Pi which introduced me to it, I am almost starting to get used to. But BASIC remains my favourite quick problem solving tool on any platform.

[Mikefulton]

Back in the day, I used to hear people make the argument that they were able to get things done faster in GFA BASIC. There's a certain amount of truth in that, but I think it's a misleading truth.

This can still apply, but it depends heavily on what you are doing. The GFA compiler does do a nice job, and one reason it does fly is the parameters passed to built in functions are register based.

I didn't mean the executing code was fast. I was referring to the ability to sit down and be able to create a simple program in a few minutes.

If you haven't ever done anything with C, then yeah, you're probably going to get results faster with GFA BASIC instead. I mean, it's pretty obvious. You run the GFABASIC program, type a few lines of code into the editor, hit "RUN" and BANG! you've got some results that might even do what you wanted. By comparison, doing anything with C or Pascal or Assembly, for example, is going to require you to do more work before you get anywhere.

I don't think we get a lot of new GFA coders, maybe occasionally. But I still hold that belief that every system should have a version of BASIC, so newbies can get their feet wet, that's why I maintain it. Perhaps they will move on to C later. Since GFA now works on the firebee, I suppose it might seem attractive to some.

I agree that every system should have some sort of interpreted programming language. I dunno if it has to be BASIC, though. I think you could make the argument that JavaScript is a better choice these days.

I guess if there's a question wanting to escape from these thoughts, it's this: Why use GFA BASIC instead of something else?

It might simply be personal preference. I find 'C' to be not very intuitive and the compiler errors cryptic at times and I try to avoid make files, but I started out with GFA back in the day.

No doubt personal preference plays a big role. Just out of curiosity, do you have some examples of things about "C" you find non-intuitive? (I fully agree about compiler errors although it's not as big a deal with modern setups.)

[lp]

Well at least for me GFA wins hands down on how long it takes to make a simple program start to finish, seeing how I don't even have to compile it. As for JavaScript, I don't even have that option on my Atari, so I guess some form of BASIC still applies on this platform. I am only familiar with PureC, so anything I say is regarding that package. I use it because it was quite popular and it's easy to find another user if one needs help. I really hate the cascading errors, 1 error leads to a gazillion and yes I know you can limit this, but it seems pretty daft to me, why it's designed like this. PureC seems pretty bad at placing the cursor at the actual position of the error. Again, this might be years of GFA use, where I'm used to the editor doing a syntax check before I run it and not after. Also the GFA editor is quite good at placing the cursor within a line when it don't like something. None of the Atari C packages can fold subroutines like GFA can, far as I know and I really love that feature.

[christos]

For me BASIC is kind of my first love. I met her with my 130XE. However I actually programmed in C/C++, Pascal and Matlab before I started using GFA. Mind you my biggest projects were DLA simulation in C++ and a program to control and acquire data from a high resistor meter in Matlab. But GFA was easy to pick up, it allows me to do everything I want with it, and I get to do it fairly quick. I am even using X11 Basic on this linux box and on Android just because it's GFA Basic for new systems.

I really like C and C++. It's just that it demands too much time out of me, I constantly need to look stuff up in the reference. So I prefer the simplicity of GFA BASIC. Moving on from GFA, it would mean that the language is limiting me somehow and that is definitely not the case.

Doing web design and web development for a living, I have to deal with php, javascript and the occasional python on a daily basis. If I am going to do comfort coding, I'd prefer something I am more familiar with.

[mjvans]

Why GFA? Because we can and it is much fun. GFA is easy to understand, readable, I would recommend it to everyone who wants to try programming.
I restarted programming in GFA this year after more than 17 years.
For me it is logical to use GFA because I used it a lot back in the day. It brings back good memories.
I used Pure and Highspeed Pascal for GEM programming and GFA for the more creative game and demo like stuff. With GFA you get very easy result and that gives a boost to creativity.
I tried C more than once but never came to results with it and when it takes too long I lose interest.
Got a couple of old projects from the nineties which I can work on.
I want to try LP's new version of GFA but I don't use MiNT yet. Multitasking was very unreliable on the Atari when I last used it (MultiTOS) so unusable that I tried to keep far away from it, but that is decades ago it could have evolved by now. I will try later this year but not too fast.
And I don't need compatibility at this stage for my old programs. First I want to try to create something and come to a result.

[Mikefulton]

Well at least for me GFA wins hands down on how long it takes to make a simple program start to finish, seeing how I don't even have to compile it. As for JavaScript, I don't even have that option on my Atari, so I guess some form of BASIC still applies on this platform.

I am only familiar with PureC, so anything I say is regarding that package. I use it because it was quite popular and it's easy to find another user if one needs help. I really hate the cascading errors, 1 error leads to a gazillion and yes I know you can limit this, but it seems pretty daft to me, why it's designed like this.

PureC seems pretty bad at placing the cursor at the actual position of the error. Again, this might be years of GFA use, where I'm used to the editor doing a syntax check before I run it and not after. Also the GFA editor is quite good at placing the cursor within a line when it don't like something. None of the Atari C packages can fold subroutines like GFA can, far as I know and I really love that feature.

I didn't mean JavaScript on Atari... just meant that as far as the general concept of having a programming language right out of the box went, it might be a more reasonable choice than BASIC for modern PCs.

Otherwise, I think a lot of the stuff you're talking about is really a compiled -vs- interpreted issue more than a which-language issue.

[GokMasE]

What you're saying about "the syntax of C has always kept me away" is definitely a thing, but it's something that goes away for most people as they work with other programming languages more and more.

However, my own experience, which seems to match that of other programmers I've talked to, is that as you work more with other languages, your brain starts to think about problems at a higher level, with more generic programming constructs instead of the specific syntax of a particular programming environment.

That is, you start to think "This needs a WHILE loop" instead of specifically "This needs a GFA BASIC WHILE loop".

Sure, but at the end of the day you still need to properly understand the syntax of any language you wish to target no matter how good you are at treating coding scenarios in a more generic manner.

You also have to get yourself familiar with appropriate coding tools for the language of choice, which in some cases may look and work quite differently from whatever devkit you are familiar with currently.

Depending on who you are, why you are coding, what your aim is, these things can easily become too big hurdles for you to want to try and get past. Or even feel the need to.

For the purpose of being able to port code from other platforms, there have been times when it would have been useful for me to know C, that is true. That insight has however never brought me really close to trying and push beyond the barrier of the kludgy C syntax, its just too much work and too little fun involved. For me, that is

Since GFA nowadays is more compatible and more stable than it has ever been, I don't consider that a limiting factor myself. And with Lp:s GBE one can keep creating GFA code in a modern multitasking setup without nasty hacks. If anything, the inability to call procedures/functions by address is the one limitation factor that at times may be considered an obstacle for work flow.

But I suppose your question regarding why using GFA over anything more modern, you might as well ask why mess with an Atari at all when there are modern computers that are better suited for pretty much anything you want to have executed today? Maybe its just for fun? Maybe because of the challenge? Or maybe just for the heck of it!

[Mikefulton]

While I'm aware that there's a revised version that's supposed to work reasonably well, I'll admit that my thoughts about GFA BASIC are perhaps a tad biased as a result of having to deal with compatibility issues when we released the TT030. Or Falcon030. Or MultiTOS... Just got to be a recurring theme back in the day.

[lp]

I didn't mean JavaScript on Atari... just meant that as far as the general concept of having a programming language right out of the box went, it might be a more reasonable choice than BASIC for modern PCs.

Otherwise, I think a lot of the stuff you're talking about is really a compiled -vs- interpreted issue more than a which-language issue.

Well, I have a fairly new mac and zero interest in doing anything coding-wise on a modern system. What's relevant outside this forum doesn't matter to me, we are on a forum about obsolete machines after all.

That is the draw to GFA, easy to write in, fast results, as the interpreter has always been an integral part of GFA. The compiled code isn't to shabby on the speed either. Plus it's still supported, as I make every effort to handle bug reports. I don't see anything wrong with using something that is still supported and it works even on the firebee.

If you want to question something, head into the other sub-sections and ask why they bother with HiSoft, Omikron, or STOS. None of those really have any support on a regular basis or major updates since the companies abandoned them.

[lp]

While I'm aware that there's a revised version that's supposed to work reasonably well, I'll admit that my thoughts about GFA BASIC are perhaps a tad biased as a result of having to deal with compatibility issues when we released the TT030. Or Falcon030. Or MultiTOS... Just got to be a recurring theme back in the day.

I totally get that. In fact it happened to me. The original GFA is not tasking friendly at all without some nasty patch program and that was probably a show stopped for many back in the day. Even with the patch program it wasn't really working to well with tasking, you could say just enough to get by. So, here you are with this new tasking ability, but the coding package barely works, what a messy situation that was. All I can say is the ones who do use the updated GFA, are usually very happy with it. It retains a similar look and feel and so anyone familiar with GFA can just start editing code and feel right at home. Some don't even use the interpreter, since the compiler is so fast. I coded it on a Hades, so its very VDI compliant and so one can code in any bit-plane depth, all the way up to 32-bit.

STOS broke at every TOS release from what I know of it and people still use it.

[Arne]

My 2ct:
I have enjoyed GFA-Basic those days, too. Even converted a financial accounting program from a CBM3032 (code was plain Commodore Basic with source) to my father's brand new MegaST2 with GFA Basic 2. It did what he expected plus some new extras. Then I wanted to write a strategy game (no inline assembly needed). It ran from the interpreter but bombed when compiled. I never got it running when compiled. That day GFA died for me and I just used it for some matrix calculations in university.

But here's the thing... I don't really understand why anybody would want to write new code in GFA BASIC these days. It seems to me that whatever advantage there was to using GFA BASIC for some projects back in the day, most of the reasons don't really apply any more. And given the well-known compatibility problems that GFA has with non-vanilla hardware, I just don't understand why it seems to retain so much popularity.

I can only speak for myself but what I see most amateur programmers are lost/overextended when it comes to other 2GL languages (C, Pascal, Modula 2). I tried to learn C in the late 80's with books written especially for the Atari and C. I was lost. Too many cryptic lexemes like { } ! ~ & | and so on. And of course: there was no www and other resources available besides magazines and books.
I thought "Why is it (C) so difficult? You have to write everything yourself." Want to load a file into RAM? Use BLOAD. In C/Pascal/Modula2 it is much more difficult. So I sticked with GFA (for the time being). In university I had to learn Turbo Pascal 6 and learned to enjoy it. Later the year we had to learn C. And in C I understood how pointers worked and what they are. It didn't when learning Pascal. :-/
What I want to say: be patient with these people. They aren't professionals. I earn my living the last 15 years writing code in assembly, C and Delphi. I would never go back to BASIC!
Of course I have to write (almost) everything myself but I do have full control.
On the German forum was an attempt to teach others C. It vanished after two (or so) lections. There is no enthusiasm for me (at least) to do (almost) the same at home in my spare time (i.e. teaching) what I do for 40 hours a week. And the "students" give up easily. They just vanished, too. That's how things are. I leave it that way - and do other things in my spare time: like engineering hardware
It's easier to give up learning C for an amateur at home then for students or in your job where you are forced to learn it!

Today I "think in C" and trying to port my way of thinking to Basic gets difficult when it comes to pointers and other things.

Too much about it is too far from intuitive and messy looking

I hear you
I have seen absolute crappy code by "pros" written in C and really beautiful code written in C. I would suggest starting with Pascal as it is a more "chatty" language. You have "begin" and "end" instead of "{" and "}" and so on.
What I hate is the syntax of pointers in Pascal. But that's just my opinion. Pascal pointers are almost the same as in C but it looks strange with these ^ signs. I can't get used to it.

I don't know about Lattice C but Pure C's project files are pretty easy. Writing makefiles for GCC is a burden. Not talking about linker skripts!

[shoggoth]

(weird, I just posted, but the post disappeared)

My preference nowadays is C - but to be honest - any tool which makes a person productive is a good tool. Just look at the amazing applications written by Rajah, GokMasE, LP, and others. These applications are perfectly system friendly, fast (!), and very very useful. LP has achieved the impossible without access to the GFA Basic Compiler/Interpreter source code.

I'd say LPs incarnation of GFA definitely has its place on this platform 2016. It's just as significant as AHCC, VBCC and GCC.

[simonsunnyboy]

The result is what matters. Given the sheer number of ST releases these days, the language just does not matter. If the developer is happy with one and it leads to a result, it is all ok.

Noone is forced to use GFABASIC but it presents a solution that still produces considerable output and programs. The ST wouldn't be the same without GFABASIC!

[Mug UK]

If it wasn't for GFA, I probably wouldn't have moved onto other forms of BASIC as I moved onto the PC.

I code Microsoft Word, Excel and PowerPoint add-in and 'quick fixes' in work. All done using VBA and wouldn't be possible without all my GFA experiences.

I still dabble in 68K albeit the simple stuff, but it's not something I can use in my workplace.

And echoing Simon's reply above, it doesn't matter what you use, so long as (a) it works and (b) you enjoy it

[Dal]

Anarcho Ride by Thomas Ilg was written in GFA Basic and it's FAST!

As stated above any language that allows a programmer to be creative is the best language for that programmer.

[AtariZoll]

...
Most people, when they start programming, end up with their brain trained to think of programming in terms of the syntax of whatever language they were using at first. In your case that may be GFA BASIC. When you try to do something in another language, the problem you're attempting to solve gets somewhat lost in the translation of the syntax. ...

My first programming was drawing square on screen of Sinclair ZX 81 - five minutes after I turned it on for first time. It appeared not so simple, and I spend some half hour with 5 line Basic program - because did not get right at start how to make nested loops Point is that I was not focused to syntax at all, but on algorithm . And I'm sure that it is basically same for all programming languages .
Later I discovered that doing same in ASM may be 1000x faster with even shorter code. In case of compiled Basic, difference is of course much smaller.

...
And echoing Simon's reply above, it doesn't matter what you use, so long as (a) it works and (b) you enjoy it

I would add to it that how works is important too. Especially in case of slower computers. Today, with PCs 10000x faster than ST, you can do most of stuff in C, or even in Visual Basic or like - it will work reasonably fast. Probably even Steem authors would not do today some parts in ASM.
Another thing is size of code - today irrelevant too, but in case of ST - TOS would not fit in 192K, if was written 100% in C.
Related with - I always hated CPX and it's modules - just because they took tens of KB of RAM for some really trivial settings, just because high level language overhead.

[SweYC]

My 2 bits as well:

Call me stupid, but i cant even grasp a reason for this post. GFA is a tool. Many tasks can be done using different tools or techniques. So why on earth should one propagate or dismiss a tool, other than performance wise? I work mainly in GFA. Its fast, its easy, and im used to it. I have seen great and bad programs done in ANY language, so thats not the point of not using GFA. Its limitations are known, so are HW limitations of our Ataris. From demoscene i know briliant coders, they are not briliant because they do not use GFA, they are not briliant because they maybe do use C, and they are not briliant because they use ASM. They are biriliant, because they are smart! And im glad about any app i find usefull, nice, amazing, whatever, just because someone did it! And for sure, i will not rant about what tool they use... I will not talk about how good GBE is, how fast it compile stuff etc, etc... GFA is a tool, if one use it, i wont dismiss him/her and talk nonsense.... I will rather thank them, and if possible get them a beer!

[Scottinnh]

I see both sides, and really IMO it's about more than GFA, it's any form of legacy programming.

My opinions (disclaimer: I don't code on Atari at all)

PROS
* the notion that C requires "experience" (lots of consultation against reference docs until concepts become muscle memory)
** perception that C requires greater effort for less result (see above)
* Docs for GUI C coding will assume the reader is versed in C fundamentals, putting novice C coder at great disadvantage
** ...talking C as a new language, on the ST, means considerable time spent practicing "boring" CLI applications
* Pure sentimental/nostalgia feedback (which is healthy -- as long as one doesn't get carried away..)

CONS
* C is relevant to the modern, real world.
** (Even if you don't "want" to become a professional programmer, simply having the skill opens many non-coding doors).
* C is useful for much more than than creating applications for users.
** Ability to interact with hardware, or communicate with cool stuff like Arduinos (which use a simplified C language).
** Being able to understand "cool stuff" done for other OS like the C64, Amiga, Linux... being able to interact with Arduino and sensors using Firmata protocol, and so on).


Personally, I'm not a C coder (except for things I forget from school, and more recent fun on the Arduino).
I'm competent enough with Python/Perl/Bash/PHP to be employed for those skills however these languages don't exist on the A8 or a 520ST
(I'm aware of Jeff Armstrong's awesome port of Python 3 to FreeMiNT -- looks nice -- but that OS requires 4MB I don't have on my 520ST... and no one's ported MicroPython to the Atari ST, as far as I know).

I could see some relevancy in the Contiki OS, as they're making a play for the Internet of Things space. But I expect that too relies heavily on C. I've found a few threads on Contiki and Atari 8-bit, but not much on the ST, and not much about the capabilities of the Contiki environment under Atari.

[exxos]

Those pros and cons look backwards to me.

[Mikefulton]

... but in case of ST - TOS would not fit in 192K, if was written 100% in C. Related with - I always hated CPX and it's modules - just because they took tens of KB of RAM for some really trivial settings, just because high level language overhead.

The issue with CPX size wasn't really so much the overhead of a high-level language. It was the fact that they were all individually compiled and linked as stand-alone things. Meaning if you had a half-dozen CPX modules loading, you likely had half a dozen copies of the same C runtime code.

Beyond that, the real problem is something I've touched on in my blog... the way GEM AES was designed, your application had to do a fair amount of work just to do the "basic" minimum level of event handling for the GUI. So, in addition to that half dozen copies of the same C runtime code, you probably also had a half dozen copies of essentially the same code for processing messages, redraw events, etc.

Neither of those issues really has anything to do with "C" being inefficient or not. It wouldn't have been that hard to do a shared runtime library that only needed to be loaded once. And because of the differences in how the system has default behaviours for event handling, an executable for a simple program similar to a CPX might only be a kilobyte or two for MS Windows, versus probably at least 10-12kb with GEM.

[Mikefulton]

My 2 bits as well:

Call me stupid, but i cant even grasp a reason for this post. GFA is a tool. Many tasks can be done using different tools or techniques. So why on earth should one propagate or dismiss a tool, other than performance wise? I work mainly in GFA. Its fast, its easy, and im used to it. I have seen great and bad programs done in ANY language, so thats not the point of not using GFA. Its limitations are known, so are HW limitations of our Ataris. From demoscene i know briliant coders, they are not briliant because they do not use GFA, they are not briliant because they maybe do use C, and they are not briliant because they use ASM. They are biriliant, because they are smart! And im glad about any app i find usefull, nice, amazing, whatever, just because someone did it! And for sure, i will not rant about what tool they use... I will not talk about how good GBE is, how fast it compile stuff etc, etc... GFA is a tool, if one use it, i wont dismiss him/her and talk nonsense.... I will rather thank them, and if possible get them a beer!

If you like GFA, that's fine. Nobody is saying that you should stop using it. My original post was simply based around the idea that the reasons why one might select GFA BASIC in 1989 may no longer apply in 2016. There might be completely different reasons now and I was curious as to what they may be.