Some thoughts...
The IDE is very customizable in regard to font-size, fonts, and color scheme. I immediately changed mine to LUCON with a 23 pixel size. I also got rid of most of the highlighting colors and number lines. The number of rows and columns can also be adjusted.
QB64 is 99% QuickBASIC compatible. There are just a few keywords that were not supported, like FN. So, if I wanted to give QB64 a bad fake news review, I'd just say something like... In QB64, you can't even make one FN statement that works! :D
Anyway, my point is if I read your review before trying QB64, I might not even bother to download it, and instead be off wasting my time on Chipmunk BASIC. Now that would be a shame.
About me and my programming experiences...
I started programming with punch cards in 1979, and hated it; but for some strange reason, possibly alien abduction, I bought a TI4a in 1981, and I was glad I did. Sure, it was a bitch trying to punch holes in the console, initially, but then I learned you could optionally type stuff on it! Wow, what an improvement over cards! I started learning BASIC by programming TV games, like Wheel of Fortune, Password, Card Sharks, and I was also able to write a 4K Monopoly program on the TI. I think that got me started on code optimization, which would be a necessity over the next 20 years. It recall I had a tape recorder for a drive. In 1984, I pitched that unit for an Atari 800. It had 64-bit with a real floppy drive. I didn't miss that bleep - bleep - bleep file saving and loading sound from the TI, one bit. Atari was also a great BASIC language, and the system had 4x more memory than my TI. Atari BASIC even allowed users to redefine characters, and offered extensive documentation of the use of PEEK and POKE addresses. Ah, the good ol' 16-bit days. Well, welcome to the 1990's, and with the "toy" computer age behind me, I ponied up 4,500 for a 486, state of the art, Windows 3.1 custom made system. It had TWO floppy drives, woooo-hooooo! Better still, it came with this little per-installed software program, called QBasic. QB was easy to learn, because it was very similar to Atari and TI BASIC dialects, but you still couldn't make stand-alone exe files. I solved that, by purchasing QuickBASIC, which I used to write my office software. I did appreciate code in the IDE, which helped in debugging, but I didn't appreciate the 64KB memory restriction, even with mulit-modular programming, the best you could squeak out was around 250KB. So, I had to make 16 programs to run my office, and develop a system to share the data between them. I was very happy with the results, and the ability to run over a network was a nice addition when I got my first internet setup. Anyway, the programs I coded worked much better than the "professional" software my colleagues were using. While I did have to debug problems when they arose, my colleagues were much more busy constantly calling in expensive I.T. to identify and fix their office systems. So all was going great, until MicroSoft abandoned the product. Windows systems could no longer natively run QB software. So, along comes this guy, "Galleon" who claims he was making a QB to C/C++ translator, which would run nearly all QB programs on newer operating systems. There was something about this guy. I remember I had to talk our forum owner into giving Galleon a sub-forum to showcase his work. Sure, our owner was correct we heard this song and dance from at least a dozen other accomplished BASIC and C programmers, and that it seemed quite evident none of them would ever finish anything to a workable completion, except, I had a hunch about this Galleon fellow. Good hunch, too. Somehow, this ONE guy devoted nearly 10 years of his time, and yes, he did create a finished translator, 99% QB compatible and by far the most QB compatible in existence today. He also created the IDE, the [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] forum along with contributed documentation to the QB64 Wiki. Galleon also added many new underscored keywords, and improved the compiler performance. He made a bold choice to switch from SDL to OpenGL, and he managed to make what I thought was a mistake initially, into an even better product. Now, far beyond what the QB family of products could do, the newly added keywords extended a programmer's capabilities to stay current with the times, but unlike so many other BS-BASIC languages of today, the keywords Galleon added remained BASIC in nature.
In general, the QB64 improvements over QuickBASIC are staggering, to say the least. No more limited memory. An incredible increase in speed, automated compiling and linking. In QuickBASIC, large projects had to be compiled and linked manually to get them to fit into memory. With QB64, there is no more platform dependency! QB64 has its own integrated mouse. QB64 comes with full online documentation as well as the help files in the IDE. Incredible improvements over QB in color rendering and graphics abilities. QB64 also has the speed needed to implement those improved graphics abilities. Now this is just stuff off the top of my head; so anyone else, please feel free to add more QB64 benefits.
When Galleon made some headway with the project, I decided to help debug it by consolidating my 16 office programs into one. If I found a bug, or other beta testers found a bug, Galleon did an exceptional and timely job at correcting the problem. So, amazingly, I ended up with one 86,000 line office program, and the compile time from the origination of the project, to what it is today, was remarkable. Believe it or not, early QB64 versions would take as long as 30-minutes to compile. Of course, computers were slower a decade+ ago, but still the fact that smae code now compiles in about a minute is a stunning accomplishment, especially when you consider it has to first translate all BASIC statements into C/C++ and whatever is needed for different platforms, OpenGL, etc, and then let the Mingw32 compiler do its thing.
So most of my life, I've programmed in BASIC, but about a month ago, I started learning C/C++. I think I'm starting to get comfortable with it, but I'm just finishing up my first program. It's a little over 1000 lines of code, which gets me a custom made, non-blocking text input routine, printed to the console. The screen text can be fully edited, and it has an added mouse routine, also non-blocking, which can highlight and select text, etc. So, it is a single line text editor, but certainly far from a word processor. Anyway, so, so many statements were needed just to do what QB64 automatically takes care of. I had to setup and control the console window, meaning I had to code to get rid of the vertical scroll bar, change the foreground and background colors, disable quick edit mode, size the console, get control of the cursor shape, etc. Arrays are also a pain in the ASCII with C/C++. I think I cheated my way around this first go 'round, as it works with no memory leaks or crashes, but I really need to study more on how to make and store arrays in C/C++. Now in comparison to QB64, there are little to no worries about crashes or memory leaks, which are so troubling in C++. How "Galleon" worked his way around those in translation from BASIC is really another thing to his credit. I also believe the ease in which QB64 works with OpenGL to render a real graphics window, that can act as a text window, is far better than the putting up with a C/C++ console. It would require even more programming experience for me to get a Win32 graphics window working with text editing. So it takes learning all this stuff, C, C++, and Windows API programming to accomplish what QB64 can accomplish on it own. My C/C++ experience has me even more appreciative of what QB64 can do. QB64 can even work with other libraries, if needed, and unlike the app I'm putting together, which will only work in Windows, a similar app in QB64 would run on Windows, Linux, and Mac.
Pete
