Possible Solution to threads like the one that was started.

[MystikShadows]

I tried to post this but the thread got locked before I could hit Submit it seems. But I think perhaps one thing can be learned from that whole thread is that the way FB is introduced to the outside world may be misleading (not misleading as in not true, just misleading as in not in the way that is seemingly assumed). For example, taking the two descriptions below.

[...] FreeBASIC (DOS (DPMI32), MS Windows and GNU/Linux) — An almost 100% QuickBASIC compatible Open source language compiler, (GPL) [...]

[...] FreeBASIC syntax attempts to stay as close to the BASIC syntax as possible, specifically that of QuickBASIC. [...]

I wonder if this isn't where a certain confusion might set in? If I was a newcomer to the freebasic project, these two descriptions seem to lead me to believe that if I just take a QB source file and fbc <sourcefile.bas> and press enter, that it should compile it fine. I'm thinking that maybe these two description should be changed to present today's FB reality.

Just like when I wrote my article on FreeBasic in QB Express, my evaluation, back then, FB's native mode was, as I mentioned, taking a different direction back then, and back then there was no specific talks of a -lang qb mode, back then it was just FB taking this new direction. Things changed since back then and evenI'll admit to that.

Now if you read these two descriptions above, perhaps the fact that FB supports multiple compilation modes one of which is created to support a QB like structure and dialect. Maybe people would come in the forum with all the knowledge they need to not assume what DML seemed to have assumed and know that they need to find which mode they need to use their qb code for example.

I wonder how much such confusion (and assumptions) can be avoided upfront just by adjusting these descriptions (those quoted above and others outside fb.net and perhaps in the wiki as well to be clear on which way FB supports the QuickBASIC syntax (ie via the -lang qb mode) so that people don't come here expecting -lang FB to work like and be like -lang qb.

Just a suggestion, but I think that might clear the air if people know about the multiple compilation modes upfront.

Thoughts?

[E.K.Virtanen]

I agree with that one. Eventho FB forums has lot's of old qb'rs, FB itself is not anymore near of original QB than many other basic dialect (unless you specially use lang qb).

FB is more and more it's own basic dialect, and thats how it should be talked about. Not as an QB clone.
No offence, fb is great. Just my 2 cents.

[v1ctor]

If an user that was using (or trying to use?) FB for 3 years couldn't find that a single command-line option could bring happiness back to his life, i don't think beginners will realize that even if we stamp a red warning label telling "Use -lang qb/fblite if you want your old sources to compile!".

A better option would be to split the compilers/packages. Say, the qb version wouldn't include any headers (those damned .bi files of hell) and so on.

Now we just need someone up to the task, keeping the compilers up to date, making the releases at same dates, applying patches etc etc.. it won't be me, and i believe nobody in the FB dev team is up to that too.

Btw, the "FB is getting closer to C!!!1" story has been told since version 0.1, get over it people. Of course it looks like C in many aspects, that was a deliberated choice. If you don't like that, try PowerBasic (the "new" features look like Cobol), Vb.net (a verbose version of C#), RealBasic/Blitzmax (Java-ish), PureBasic (var declarations are done like in NASM), etc.. Do you see a pattern? None of them followed the holly BASIC standards, and the reason is simple: there's no standard, each followed the path that the developers behind it wanted, just like we did. Are our choices the best ones? Let the users decide that, i'm sure there is a place for each one of those BASIC dialects.

[counting_pine]

@MystikShadows: The recent thread has led to the topic being brought up, but it wouldn't have been a good place to discuss it rationally.

If there are any places where you feel FB's description is wrong or out of date, then you can discuss it or suggest alternatives here.

I've updated the List page linked to - hopefully that gives a better idea of the situation. The main article could do with updating to talk about lang fblite though.
As users of FreeBASIC, what are you guys' understanding of lang fblite?

[cha0s]

Damn, I forgot the discussion we had about branching the compiler for the different dialects. Maybe instead of actually forking the codebase, we could just package the distributions differently... Yeah, fb.bi will have to be hit (FB_DEFAULT_LANG) for each build, but maybe it would be a nicer solution than what we have now.

I guess there just comes a point where you have to acknowledge ... "them", and make the process completely braindead... or do we? :P

I really would love to branch the code though because we could really remove a ton of crap hacks out of the compiler for QB... but that really is an enormous job... $%#@ I can't even type -lang qb.

[MystikShadows]

@MystikShadows: The recent thread has led to the topic being brought up, but it wouldn't have been a good place to discuss it rationally.

I understand that Counting_Pine. No problem there. :-)

As users of FreeBASIC, what are you guys' understanding of lang fblite?

My understanding of fblite is that it's the for those of us that got used to coding fb 0.16 style but lost some of the features when 0.17b came out (and versions after that) so that projects doen before 0.17 can compile in version 0.17 and above with the fblite or what used to be -lang deprecated.

[maddogg6]

I guess there just comes a point where you have to acknowledge ... "them", and make the process completely braindead... or do we? :P

If I may chime in.... It is my opinion that BASIC *is* and always was design for the 'brain dead' side of the spectrum when talking about 'programming'.

Frankly, I think this aspect (about BASIC, in general) is too easily forgotten by the non-brain dead developers.

The more brain dead ready anything is - the more successful it *can* be.

AOL made the internet easy for real idiots - and the internet exploded. (for better or for worse :p)

[Lachie Dazdarian]

To be honest, I don't get much the point of fblite. Is this related to compability with third-party lib wrappers or something?

BTW, can I use, for example, FMOD in -lang QB?

I would personally like to know more precisely the limits of fblite and -lang QB compared to -lang FB, related to using third party libraries.

[counting_pine]

When it comes to using external libraries, all of the dialects should have the same capabilities, as long as the headers are set up right. This is trickier for lang qb, given the integer size discrepancy, but lang fb and lang fblite can work fine on the same set of headers, provided all parameters are explicitly passed byval or byref - compile with "-w pedantic" to make sure of that.
The exception would be with object-oriented libraries, where obviously only lang fb will play nicely.

The point of lang fblite is to provide as much access to lang fb's features, and be as compatible as it can, without sacrificing the features of BASIC that many people like, such as implicit variables, Options and flat scoping.

It's also very close to older versions (pre 0.16b) of FB, when a lot of the changes discouraged many people. Upgrading from older versions should be a relatively painless experience.
Migrating from lang qb is also easier than it would be to either lang fb or lang deprecated, thanks to its flat scoping and Gosub. The devs have worked quite hard on both of those.

[Dr_D]

Well, I know this has been discussed before, but even if FB does seem like a C compiler, who cares?

I would much rather have oop, even if it isn't full blown C++ style oop.

I would much rather work with/debug this:

Code: Select all

dim as integer something, something2, something3

if something then
    if something2 then
        if something3 then
            
        end if
    end if
end if

than this:

Code: Select all

int main(int argc, char *argv[])
{
    int something, something2, something3;
    if (something)
    {
        if (something2)
        {
            if (something3)
            {
        
            }
        }
    }
}

My point being, even if FB seems close to C syntax, it's even closer to BASIC syntax. Maybe the first description does need updating, but a few minutes of reading about the compiler's features should lay it all out. The second one:

FreeBASIC syntax attempts to stay as close to the BASIC syntax as possible, specifically that of QuickBASIC.

Maybe just the almost 100% part should be taken out of the first?

[Skyler]

Dr_D: Judging from the contents of that firestorm, a lot of people cared. I bet many people were expecting to see QBasic ported to Linux and Windows, and were then disappointed.

[counting_pine]

I don't think it's sensible to discuss whether or not FB is too much like C.

FB has a dialect that aims to be as close to QBASIC as is practical for the scope of this project. It also has a dialect that aims to merge QBASIC's programming style with FB's feature set.

Thus, it doesn't make sense to talk to generally about FB in this respect. You can discuss issues with specific dialects, or even the concept or implementation of the dialects system, but I'd say the fact that there are dialects means that whether or not the default dialect is too close to C, is not a problem in itself.

[Basic Coder]

I guess there just comes a point where you have to acknowledge ... "them", and make the process completely braindead... or do we? :P

If I may chime in.... It is my opinion that BASIC *is* and always was design for the 'brain dead' side of the spectrum when talking about 'programming'.

Frankly, I think this aspect (about BASIC, in general) is too easily forgotten by the non-brain dead developers.

The more brain dead ready anything is - the more successful it *can* be.

AOL made the internet easy for real idiots - and the internet exploded. (for better or for worse :p)

BASIC was designed to be easy to use and learn. That is its strength.
It made programming possible for the casual user who didn't have
the time to learn all the ins and outs of more professional languages.
FreeBasic allows me to write fast code making use of the latest
hardware without having to learn the Window's API's.

I have dabbled in Java, C, C#, C++, VC++, VB and so on and they
are fine for what they do. For every task there is a best tool to use.
For some tasks FreeBasic is the best choice. For other tasks maybe
Java or C++ is the best choice.

Basic Coder

[arenth]

You know, we could look at things realistically, and the reality is, if you are too impatient, and close mined to do some independent research, and actually attempt to debunk your own wildley flammable claims, before dropping them on a forum, then perhaps computer programming is not for you.

Programming is, and always will be a means of solution to problems. People who choose not solve the problem of their lack of knowledge in terms of a new language, should be willing to solve the problem of how to do the same old thing, in a new package.

Perhaps -lang qb should be the default, as those who are going to the effort of learning -lang fb will also probably figure out how to do it. Perhaps that, or rip QB out entirely, less work for the dev's, more happiness for a few of us at least.

[yetifoot]

I was quite surprised to see that thread, because I thought that was old news really. At the time around 0.16-0.17 it seemed a lot of people got angry with the changes, of which there were quite a few, and some of them major for some people, and a number of people left. But, I didn't think that the language had changed enough again recently to force someone to leave so publicly.

I'm not necessarily against that kind of thread, if people feel something is wrong, it should be discussed. It was just a shame it was a flame fest.