Possible Solution to threads like the one that was started.

For other topics related to the FreeBASIC project or its community.
Posts: 469
Joined: Dec 17, 2006 23:37

Postby Hezad » May 19, 2008 17:47

Well I'll use this thread to say what I think about FB from my (very) little coding level since I saw some flame topics and I REALLY don't understand why ! QB? C? OOP? What the hell, it's not important at all !

I really consider FB as a language on it's own and not "just" a QB adaptation (from my point of view since I don't really know what were the first objectives of FB) .

It can be used by QB lovers, cool.
It can be used by hobbyists, cool.
It can more and more be used for professional use.
As it already been said, it's powerful, simple, it's a BASIC deviation with more and more interesting features (with a lot I'll never use from my level ^^).

Seriously, congrats guys and thanks to all the community which makes me come to see what's new in here several times a day. It's a real pleasure to code with FB :)

Now, if people have ideas to improve it, that's really cool, and I understand that ol' QB scene people can be upset about this or that in the way FB handle QB syntax but hey ! FB is FB !!! FB's not QB ! And about people who flame about the functionalities and/or possibilities of FB, who the hell are they to spit on it ? Real people explain themselves, look for solutions, and discuss (a DIalog, not a flaming and useless MONOlog)

Sorry for english, I hope it's readable, and sorry I didn't write a more organized and reflected text but I'm not an ol' FB coder nor QB coder (raah GFA basic :D, TO7's basic, ZX Spectrum's basic :p) so I don't have a lot of elements to judge this or that. Once again, it's just my little opinion.

Congrats and thanks to all the dev team and all the community !
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

Postby anonymous1337 » May 19, 2008 18:14

My Solution: Force people to read the user manual.
Posts: 432
Joined: Oct 01, 2005 10:50
Location: Maryland

Postby Eclipzer » May 19, 2008 19:01

Honestly, these same issues are the issues that were brought up in the thread concerning lack of suffix support and I think they will continue to be brought up until FBs image is changed to accurately reflect it's current state.

The two most important things to keep in mind are:

1. FB evolved from the QB language and the QB community.
2. FB touts itself as QB-compatible.

This is FBs public perception, but the reality is: FB is NOT QB compatible and as such people moving to FB from QB are quickly dismayed to find that their QB code will NOT work with FB.

something as simple as:

Code: Select all

myString$="Hello World!"
print myString$

which is not only valid QB code, but common QB coding style, fails in native FB. Yes FB has a "switch" to enable QB compatibility, but you lose FB compatibility, so really FBs QB compatibility is an optional feature. It is not inherent in the FB language itself. This is entirely where all this conflict is coming from. The devs think a QB switch constitutes QB compatibility, and technically it does. Users feel misled by this claim, and personally I understand.

That claim of QB compatibility is more than just a sentence. It's more than just a few words. It reflects the intent of the devs and because the reality is not in alignment with this intention, as described, there is and will continue to be conflict.

I think the simple solution is to simply restate what FB is and that is a BASIC language that has evolved from QB and supports SIMILAR QB syntax. Elsewhere in the feature set, it should state that there is support for a QB compatible mode. But it should not tout itself as being QB-compatible, because this is not inherent in the native FB language. The way I see it, if I can't use it in -lang fb, then it's not FB.

In closing, l think FB is a fine evolution of the BASIC language. I also think it's time to accept that it IS it's own language, regardless of where it came from. Let's stop touting it as something it's not, because clearly, stating it is QB-compatible is misleading enough for multiple people to show concerns.

On a side note, with FB reaching, I believe, 500,000 downloads and THIS being the official public forum for the language, I feel it is quite inappropriate for the devs express their feelings here in immature and childish ways. It really reflects poorly on the language and the community. Just because some random guy decides to bash the language doesn't mean we have to resort to this type of behavior. There are more adult ways to handle these types of situations.
Posts: 242
Joined: Sep 26, 2006 16:30

Postby Skyler » May 19, 2008 19:44

@Eclipzer- Like writing a 2-page essay on the topic? ;)
Lachie Dazdarian
Posts: 2338
Joined: May 31, 2005 9:59
Location: Croatia

Postby Lachie Dazdarian » May 19, 2008 21:47

I’m quite happy with FreeBASIC as it is now, despite the fact that I was quite annoyed with the changes in FB 0.17b. Mainly because it broke compatibility with my old tutorials. Sigh. Anyway, I do sincerely hope that such huge changes won’t happen in the future, because it doesn’t benefit the language user base. Yes, it probably benefits the language on the long GCC front-end or whatnot run, but not the users today. Anyway, I will try to stay on the –lang FB wagon as long as possible.

But I must express my certain annoyance with C++ users’ inability to tame their obvious preference of C++ in many aspects over FB. Yes, they use FB more because of certain reasons, but tend to enter in their “C++ OOP features are so #%$@ awesome” mode to often. I can’t wait for these features to be implemented in FB so these individuals would finally realize that these precious features won’t make them produce better and faster. Also, I would like to see less “isn’t DIM AS redundant?” type of thread because they are a slap in the face of “BASIC” in FreeBASIC, and in a perfect BASIC community would be bashed by the majority of people. Remember how we talked about C++ in the QB community and today we don’t. Interesting.
Hexadecimal Dude!
Posts: 360
Joined: Jun 07, 2005 20:59
Location: england, somewhere around the middle

Postby Hexadecimal Dude! » May 19, 2008 22:49

I think it's time we shed the fiction of a QB/C++ divide. Personally, for example, I hate c++, I also dislike, to a lesser extent, java. What I don't think is that these languages have nothing to teach us.

The idea that if a feature didn't exist in 1966 it instantly becomes part of "c++ users" preferences is simply absurd. As a further example, I don't even really know how much I like inheritance (which I'm guessing you principally mean by "precious features") as a concept, or, more precisely, the extensive dependence on inheritance of some languages, but I fail to see how it's addition could be anything but positive.

I have to agree with Eclipzer about the public image of FB, and how "QB compatible" seems to crop up frequently in descriptions. This doesn't annoy me because I don't find it QB compatible enough, but for the opposite reason: I feel like we could be driving away more potential users by tying ourselves to QB's atrophied corpse, than we are attracting (soon to be disillusioned) QBophiles.
Posts: 1759
Joined: May 23, 2007 21:52
Location: Cut Bank, MT

Postby notthecheatr » May 19, 2008 23:06

I don't dislike C++, but I think FB has a much nicer syntax. If only FB had all the features C++ had, so it could be considered directly compatible.

Which brings me to your second point. It is indeed absurd to say that FreeBASIC needs to be exactly like (or even similar to) BASIC in the 60s or even the 80s. Programming has changed - not just C/C++, but programming in general. Just because, for example, OOP is a feature in C++ doesn't mean FreeBASIC shouldn't have OOP too. It may just happen that OOP is an incredibly useful thing that makes certain programming tasks easier. FreeBASIC still has a syntax very different from that of C or C++, and it's certainly not getting any closer than it was - though it's getting more features, and that's a good thing.

QB compatibility? I have nothing against that, because QBASIC has been used long after its time as an effective and useful language both for learning programming and for writing programs more quickly and easily than other common languages (like C/C++). However, I don't think this should be the main focus, as we already have QBASIC - why make another compiler that is perfectly QB-compatible? We should be thinking of moving up, adding new features that QB never had, increasing the usefulness and efficiency of the language. And we should indeed be careful of our public image, not to seem too "old-fashioned" to the public. We're not the same as certain people from a certain site that starts with "n" and ends with "54" - we're modern, as is most of the world. We can retain a great deal of our heritage, but we don't want to look like radical traditionalists who won't listen to anything modern for any reason at all. There is, somewhere in there, a balance.

Backwards compatibility? This might be one of the real problems. If some 0.16 programs won't compile without modification, that could be a problem. We have to realize that the developers don't know the future, and backwards incompatibility happens. But it would be nice if things were planned enough to where that didn't happen. Nevertheless, in general I'd say that with the large goal of "moving forwards" you just have to expect such things. FreeBASIC is, after all, still in it's development stages.
Posts: 242
Joined: Sep 26, 2006 16:30

Postby Skyler » May 20, 2008 1:29

I'd just like to make a couple comments here.

We can solve the problems indicated in the flamefest, but that's just focusing on the symptoms. The reality is that where there's a group of people with mostly-similar interests, the points of difference will be magnified and explode into a flamefest. That's the nature of the Internet.

Flame fests are inevitable. Even if you try to address all the issues in a flame fest, new ones will pop up and another flame fest will start going. The best we can do is minimize casualties. I recommend a liberal sprinkling of humor in each flame fest and, after it's burnt out/locked, add a notice about how the preceding thread is a flame fest and, as such, should not be taken literally; it's being preserved for the entertainment of whoever finds such things funny.

So, in closing, stopping flame fests is like stopping forest fires. It may or may not be good. Some trees depend on them. And besides, who here hasn't said "Whoa, cool!" when watching a forest fire at least once? (Honestly?)
Site Admin
Posts: 5317
Joined: May 27, 2005 6:42
Location: Illinois

Postby cha0s » May 20, 2008 4:22

I think it just goes to show how awesome FreeBASIC is, that people get so upset about it. If it was "just another BASIC" no one would care and they'd move on the QB128 or whatever other language they wanted. Everyone wants to control it...

That's all.
Posts: 1759
Joined: May 23, 2007 21:52
Location: Cut Bank, MT

Postby notthecheatr » May 20, 2008 12:27

That's very true cha0s, but I do agree with Eclipzer in one way and one way only: the manual should read very clearly. There should be no mistake made about what kind of language FB is, and if people try to start things like that again, it will be very easy to put a stop to - in fact, it will just take four letters: RTM. I think FB is a fine (or, to use your word, awesome) language the way it is, but some people could misunderstand the manual if they're coming to FB from QB. I don't think FB needs to change, but these people might be a little surprised at what they find. So make things in the manual so clear that nobody can misunderstand them, then hopefully there will be no more problems arising from this sort of thing ever again. If a person can't even read the manual, why dignify his post with an answer? The ideas expressed here are (probably) everyone's opinion already, they just need to be set in stone so to speak. If the manual says it, nobody can turn around and say "but FB is supposed to be the same as QB and compile all QB programs" - because the manual will disagree with them.
Posts: 432
Joined: Oct 01, 2005 10:50
Location: Maryland

Postby Eclipzer » May 20, 2008 13:09

Skyler wrote:I recommend a liberal sprinkling of humor in each flame fest and, after it's burnt out/locked, add a notice about how the preceding thread is a flame fest and, as such, should not be taken literally; it's being preserved for the entertainment of whoever finds such things funny.

Though I agree that flame fests can be somewhat entertaining it's a bit foolish to look at them in only that way. Any conflict gone unchecked is destined to manifest itself. If we refuse to consider the source of the conflict and do something to resolve it, then we only have ourselves to blame when it happens again.

cha0s wrote:I think it just goes to show how awesome FreeBASIC is, that people get so upset about it.

Which means we have grown to a point where there is now a responsibility to FreeBASIC users and their concerns about the language. Ignoring the people who make FreeBASIC awesome ultimately hurts the language. Seriously, it doesn't matter how "awesome" the language is if nobody uses it.

I do agree with Eclipzer in one way and one way only: the manual should read very clearly.

That just seems like an odd statement to me considering that the purpose of my entire post was to make that argument. Curious to know in what ways you disagree with me. Maybe the part about devs engaging in childish name calling?

To be a bit more specific though, its more than just throwing things in the manual. I'm certain the -lang qb switch is in the manual. But not everyone reads manuals. And for those who do, who reads them straight through? You can't realistically fault someone for this. It's the equivalent of making a game today and burying the instructions somewhere in a manual and then getting upset when few people play it. That's just poor design. Though clarifying the manual is important, this issue stems more from FBs perception being in conflict with how it actually works.
Posts: 880
Joined: Jul 14, 2005 23:41

Postby PaulSquires » May 20, 2008 15:26

My opinion: Cut the cord with QB altogether. Concentrate efforts on making a modern, progressive, BASIC compiler. Fork the project or feature freeze the QB compatability. I would much rather see efforts spent on the FB feature set rather than diverting the limited number of developers to handling a language that Microsoft killed off long ago. No disrespect to QB (and I mean that) - I used it heavily in the 90's, but it has had it's days of glory.

I like the direction that FB is going. Once the gcc backend is complete it will be a major player in the compiler arena.
Posts: 2482
Joined: Sep 25, 2005 21:54

Postby srvaldez » May 20, 2008 23:44

I second what PaulSquires said.
Posts: 717
Joined: Dec 04, 2005 0:16
Location: Varazdin, Croatia, Europe

Postby duke4e » May 21, 2008 0:54

i third that.

i think that supporting people which are too lazy to convert their code into FB syntax is just dumb. FB started as QB clone and/BUT evolved. period
Posts: 332
Joined: Oct 27, 2007 15:23
Location: NC, US

Postby Mentat » May 21, 2008 1:14

I agree. I think the future FBCs should still keep -lang qb, but modern FB is its own language, and shouldn't be held back by nostalgia for QB. Onward!

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 4 guests