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 !
Possible Solution to threads like the one that was started.
-
anonymous1337
- Posts: 5494
- Joined: Sep 12, 2005 20:06
- Location: California
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:
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.
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$
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.
-
Lachie Dazdarian
- Posts: 2338
- Joined: May 31, 2005 9:59
- Location: Croatia
- Contact:
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.
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
- Contact:
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.
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.
-
notthecheatr
- Posts: 1759
- Joined: May 23, 2007 21:52
- Location: Cut Bank, MT
- Contact:
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.
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.
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?)
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?)
-
notthecheatr
- Posts: 1759
- Joined: May 23, 2007 21:52
- Location: Cut Bank, MT
- Contact:
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.
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.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.
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.cha0s wrote:I think it just goes to show how awesome FreeBASIC is, that people get so upset about it.
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?I do agree with Eclipzer in one way and one way only: the manual should read very clearly.
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.
-
PaulSquires
- Posts: 1002
- Joined: Jul 14, 2005 23:41
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.
I like the direction that FB is going. Once the gcc backend is complete it will be a major player in the compiler arena.