coderJeff wrote: ↑Jul 02, 2023 18:04
I really don't think that preserving legacy code was ever a goal of the project. I think the addition of dialects was a reaction to complaints about directions fb was taking. But then a faction of the fb/qb community split off to go do qb64 anyway (which they did a good job with compatibility and marketing a product, even though the source is horrendous and the language is a mess).
As far as I know, the goals were defined as the project was going on. And FreeBASIC went far beyond its original goals. As in many open source projects, several people joined, with different goals, and each one tried to pull FreeBASIC toward their own goals: some wanted to preserve retrocompatibility, others wanted to move forward, and dialects were introduced to make everyone happy (I remember the discussion that brought to introduce dialects: it was about a change made by V1ctor, to disallow GOSUB inside subroutines, and allow RETURN to be used to return a value from subroutine itself, instead)
I agree with you about QB64: it is a miracle it works at all, and it wastes a lot of resources (for example, if I recall correctly, it supported direct mode, but each time you entered a command directly it created a C++ code, invoked the GCC compiler, and ran it. It supports COMMON SHARED between multiple programs, but implements it by saving the variables to a temporary file): it uses a lot of inefficient solution, with the excuse "modern computers are fast enough": but what is the point of a faster computer if you clog it to slow it down like 40 years ago?
Also, the attempt to maintain complete compatibility with QB4.5 has actually killed any attempt to do anything creative with original QB45, even when 16 bit computing wasn't totally dead yet: in fact, the few people who still used QB45 aimed to keep their code compatible with QB64, too, and that meant giving up on any external library. And this tendency is happening again: there is a separate project, QBJS (for web pages), that aims to be compatible with QB64, and this means that now developers who use QB64 have to care about not breaking compatibility with it, too; FreeBASIC doesn't have that issue, because the equivalent feature is achieved through the Emscripten target, so the compiler used to produce web pages is the same, and any change will apply to it, too.
I am actually surprised by the success of QB64, I guess it has marketed better than FreeBASIC
I spent a day to estimate the amount of work needed. I think is a lot. I would guess like more than 80 hours but likely less than 200.
The internal / external naming of things is a of course a concern and probably needs some work, but the real effort is going through the 100's of places in the compiler where variables and arrays are used and writing special handling just for qb dialect; then proving that it all works.
I appreciate that, I had no idea it was so complicated. I agree it is not a high priority, but I thought it were easier to implement.
Thank you for your answer