Possible Solution to threads like the one that was started.

For other topics related to the FreeBASIC project or its community.
Site Admin
Posts: 6169
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Postby counting_pine » May 23, 2008 0:38

Skyler wrote:It makes sense that if they want to compile QB programs, they could just download QB. I assume they can still do that?

Not legally. It's not freeware, it just happened to come with older versions of Windows, at no extra cost.
But the main point is, if someone has code that uses QBASIC, why not give them the opportunity to upgrade that to FB?
With lang qb, there's a fair chance it will run out of the box. With little or no extra effort it can be made to work in lang fblite, and then maybe it's possible to go all the way and get it working nicely in lang fb.
Without those two dialects, there's a fairly huge jump, and an awkward, in-between phase, where your code won't work in either. There's a fairly limited set of code that will work in both - you can't even use Functions.

@Mentat: If you submit a few patches for any problems you see in the compiler, and if you prove to be a generally responsible member of the community, then you may well be considered as an addition to the team. But we won't go out of our way to ask people who don't seem to be up for it.
FWIW, I think at the time I was invited, I'd submitted a few rtlib/gfxlib patches. I can't remember if I'd shown any aptitude with the compiler code, but I'd also been generally helpful and (mostly) diplomatic on the forums as well.

I think it would be good to "wikify" some of those front pages. That will make it easy to collaborate on them, then they can go back up after a while.

I think this page needs some work too:

We sort of have an equivalent here:
It's quite long though - I guess that could either be abridged or linked to.

In fact, I guess all three "About" sections could do with updating, plus the summary.
I don't think me and yetifoot are mentioned in the credits. Not that that bothers me or anything...
Site Admin
Posts: 5317
Joined: May 27, 2005 6:42
Location: Illinois

Postby cha0s » May 23, 2008 5:15

Yeah, you guys need to get into the credits page, you've both made great contributions. Itemizing all the features/fixes we've added/made I think would take up way too much space, so we should decide how to get that done, I think saying 'various compiler improvements/fixes might sound a little generic over and over, but I dunno. I'm tired right now.

Putting some of those front pages into the wiki is a good idea I think, that way we can let users tweak them if they feel they're wrong, openly, without having to ask us for permission first.

I think our system of dialects is good, but ultimately if the people we try to target (people stuck on QB for whatever reason) resent the choice we make, then maybe it's better to revise our model and consider something like branching the compiler dialect(s?). As counting_pine says, there's a graduated learning curve associated with the different dialects. That's been (lovingly!) worked on, but for the most part, (bitterly!) rejected by the target audience...
Posts: 2752
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL

Postby marcov » May 23, 2008 8:49

Mentat wrote:
You're hiring?

No, just annoying.

Seriously, I've been in exactly the same discussions in the prehistory of FPC, but then with QB's direct competitor Turbo Pascal. I know how it feels, and we also had such a compability statement on the webpage, so I just wanted to warn the committers about it (keeping that in sync) before people start whining about it.

And maybe they would be justified in whining. It is not always easy for users to understand what is happening in core (or committers, or devels or how you want to name it)
Posts: 73
Joined: Sep 29, 2006 13:39
Location: Roma, Italy

Postby fabrizio » May 23, 2008 14:39

I contributed very little to FB (just 2 unfinished projects + some posts here and there). I'm writing my opinion here as a user.

I think QB is put in the front everywhere so that FB can go on being developed until 1.0. To be consistent with this QB should be made the default and we should have a -lang FB option. Probably this would cut on some criticisms.

IMO FB is being treated by the developers more like a huge hack (which it is), than like a proper programming language. And the user base should just consider it in the same way and accept the magic the developers throw at them.

The first problem of "yet another programming language" would be: who is it useful for? How does it differentiate from other offerings? I still don't think FB has an answer to those questions. It is basically trying to put together QB's positioning on hobbists with a desire to be on par with the sharpest development tool available (g++).

I don't think this goal is realistically attainable. To grow steadily from here I see three options: a fork, a choice, or a clear and formal statement of the FB language (which would define once and for all what 1.0 is going to be).
Posts: 605
Joined: Feb 18, 2006 13:30
Location: Alexandria / Egypt

Postby voodooattack » May 25, 2008 7:35

Alright, I've been lurking for long enough, and I've been following this thread amongst other for a while, and it's about time I spill my thoughts regarding the subject into this post..

Let's go over this quickly again, a good method would be decomposing such complex subject into it's prime elements:

  • QB Compatibility:
    • -lang QB is upsetting people with a QB background for the following reasons:
      • The need to pass a command-line argument to FB in order to activate QB compatibility mode (Not a problem with any functional IDE in my opinion, but we'll discuss this later)
      • Compatibility is not 100% accurate.. not as advertised, yet..
      • -lang QB is getting restricted and stripped out of features with every new patch.
      • QB programs won't compile out-of-the-box.
    • -lang QB is also upsetting the -lang FB users:
      • Compiler bloat.
      • Newcomers getting confused.
      • Waste of dev. efforts and time.
      • The inconsistency of syntaxes and datatypes used in both modes.
  • FB mode:
    • -lang FB, upsetting people with a QB background:
      • Explicit datatype declaration, no variable suffixes..
      • FB is becoming C.
      • We want the new features too.
      • It is difficult to convert code from -lang QB to -lang FB.
      • FB is changing with every release, how can I maintain my code like this?
      • and so on.
    • ...
      • ...

My 0.2 cents:
  • QB IS DEAD, get over it.
  • FB (-lang QB) is NOT an attempt to revive it or build upon it.
  • -lang QB was created and maintained in an attempt to preserve what's left of it, and allow older QB(ASIC) legacy code to run on modern machines and operating systems, providing a free alternative to the long abandoned and most likely illegal to download, and also most likely now dysfunctional on modern operating systems binaries of QB(ASIC).
  • -lang QB is evolving in that direction, compile old code correctly.. that's about it, no new futures, only bug fixes and more QB compatibility.
  • -lang FB is the future of Freebasic, no matter how FB started out, it has come a long way, it evolved, and is now completely different than what it used to be 1 year ago, which is the nature of things, FB is maturing.
  • The C-like features allow for good/modern/professional programming practices that ease the process of writing code or make it look cleaner or even allow for less typing, they are not mandatory to use, so feel free to ignore them completely, but don't ask others to stop using them, and most certainly don't ask developers to stop adding them.
  • Old code is old, don't complain if you don't have enough patience to convert your code from QB to FB, don't go all the way at once, take a step by step, go for FBLite first (which I consider to be a code-conversion staging point above all else), once your code compiles there, try to move on converting it to FB.
  • Freebasic is still in BETA, that means that it's still in a hurricane of commits, adding and removing, changing and reverting code with every release, my suggestion is, stay tuned with the SVN builds, making small changes once at a time is much easier than making big changes all at once, updating to SVN helps your ongoing projects stay in shape for the final release (not to mention bug fixes), and ALWAY keep backups of your projects, it's not that hard.

I won't suggest forking -lang QB into a separate branch at the moment, but I'll most likely suggest that once we hit the first stable release.

And finally, I'm done, my fingertips hurt from all that typing, all intelligible comments and flames welcome.
Posts: 1759
Joined: May 23, 2007 21:52
Location: Cut Bank, MT

Postby notthecheatr » May 25, 2008 15:25

I agree with basically everything you said voodooattack. I'm one of the FB people, but I see both sides... your words matched my sentiments exactly.
Site Admin
Posts: 2901
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada

Postby coderJeff » May 25, 2008 16:07

I have worked on development of all three dialects from time-to-time because I wanted to and the other developers don't mind. It is my (free) time to waste as I choose. And I think it's been done in a way that allows the other developers to continue doing what they want to do.

FB dialect: I like the fb dialect. It suits my "option explicit" style of programming. Scopes and OOP offer convenient and structured ways to express a program and have the compiler find my mistakes at compile time instead of debugging for them at runtime. I use this dialect when writing anything of significance (size/complexity/importance).

QB dialect: If there is some old QB code I want to try, and is not too heavily dependent on 16-bit stuff, I use this first. To me, it offers a starting point for converting code up to one of the other dialects.

FBLITE dialect: QB-ism's but with FB's datatypes and the full run-time library at my disposal. I use this dialect sometimes for "throw-away" programs with the help of an IDE. Anyone complaining about how "un-BASIC" the FB dialect is should give FBLITE a try.

I know the manual is not the easiest to follow in some places. Up to date tutorials would be a big help for new programmers. I guess who ever forks the compiler could fork the docs too and rewrite them to be clear, consise and perfectly simple to understand.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest