RE: OLPC's concerns

"At least the way I read your post, it sounds like you are giving priority to built-in libraries over support for QB commands."-OLPC
In this particular case, yes I did. I don't get paid to write QB64. I love coding and if I feel "in the mood" for adding something I will do so. This hasn't changed the overall goals of QB64.

"The first problem is, if people write QB64 code that uses MP3, it will not be backwards-compatible with QB; you are purposefully breaking compatibility with QB, and this some thing is one reason people here do not like FB."-OLPC
I agree, the same can be said for QB64 supporting arrays larger than 64K, unsigned data types, etc. The difference is these keywords have an underscore in front of them, so even if a QBASIC program had a variable in it called INTEGER64 it couldn't clash with the data type _INTEGER64 in QB64. I should certainly hope QB64 will be able to provide more features than QBASIC, otherwise I'd just use DOSBOX.

"The second problem is, what if the library is limited; how will people play .MOD files? How will this be ported to DOS? This would not be a problem if you let people select external libraries such as FMOD instead of building them in. M$ has been criticized for building poor programs such as IE and WMP into its OS."-OLPC
Actually the library already does play .MOD files, it is also adaptable so new music file formats can easily be added in the future. I've never had any intention of making QB64 produce DOS exe's, QB64 is being developed for Windows, Linux & Mac.

"The big problem is, if you focus on libs and extended features before QB compatibility, you could develop forever without ever being QB compatible."-OLPC
The main focus of QB64 has never changed. It has always been and is still 100% QBASIC compatibility.

"On one of my programs, I ignored bugs and focused on adding new features. Now that program development is postponed, and the bugs are still there."-OLPC
Been there, done that, it ain't gonna happen to QB64.

"The main QB incompatibility in FB is 16-bit low level functions / ASM, and you won't be much more QB compatible until you support those."-OLPC
QB64 already supports 16-bit referencing via DEFSEG, PEEK, POKE, VARSEG, VARPTR, VARPTR$, SADD, etc. and support for CALL ABSOLUTE and CALL INTERRUPT will be the focus after user defined types are supported first.

"If you don't set the #1 priority to these challenging compatibility issues, your project will end up just as incompatible as FB (with some Blitz Basic like libs for good measure)."-OLPC
I agree

Finally, there is the issue of internal libraries VS external libraries. QB64 will support external libraries such as for 3D work via OpenGL, however it is also important to keep QB64 BASIC. If you need an external library for basic things like playing sound the following happens...
Newbie: How do I play an mp3 file?
Answer: Um, I think someone made a library for that, try a google search with "QB64 mp3 library"
Newbie (3 days later): I finally found the library and worked out how to include it, but I have some questions...
Newbie: How do I unload the sounds?
Answer: Dunno, ask the people who made the library.
Newbie: Can't contact them. Can it play .wav files too?
Answer: Dunno, I'm not that interested in sound so I've never used the library, but others say it works.
Newbie: There's a bug when I try to load certain mp3 files but I don't know why, can you help?
Answer: Sorry, ask someone else.
Newbie: I wanted to play some background midi music, how do I do that?
Answer: You can't, no one made a library for that! Why not write one in C++ yourself?
...and so on...
So although supporting external libraries is very important, a solid base of consistent internal subs/functions to perform basic actions must support it.

Galleon