Tourist Trap wrote:Unless someone came here to declare that the way fb works today from the user side (left appart the need of the IDE...) is not in its opinion very satisfying, that is what should be done. I doubt that such an user can be sighted around sincerely ( note that I say user, I know that this is only one half of the affair but I'm in this side ;) ) Other way may work or may not, this way can only be successful.
The problem is not FB, it's QB. FB syntax and behavior was modeled to be
compatible with that of QB, and it's not that QB was such a great language to begin with. So, it had to be expanded without breaking compatibility with the crummy syntax of QB. The namespace project could offer both sides what they want: the ones that like the QB way of doing things can use it as always, the rest can move on. Neither of them bothers the other, and if/when people decide to migrate to the
new way of doing things, they could do so more or less seamlessly.
I could never understand, for example, why the 'Defenders of the True QB Faith' think that things like this:
Code: Select all
line( x1, y1 ) - ( x2, y2 ), color, b
are more un-BASIC than this:
By the way, the first one draws a rectangle, not a line. See what the whole point is about? If all funtions/subs
follow the same signature, adding new functionality/exposing other is simply a matter of code the function, expose the prototype, and that's it. Only one simple parsing function could be used to parse almost all the code (sans control statements and other small quirks, of course), instead of needing a function for each QB keyword in existence. There is much to be gained, and little to lose. Other additional bonus:
Imortis wrote:Correct. I want to make development on the language itself as simple as possible. This will mean more people will be able to work on it. This means more bug fixes, more progress.
Which can be translated both to development of the
compiler itself (the fbc program) and the
language (the Basic dialect).