3 ms·

The confusion here stems from the fact that the term QBasic is ambiguous. On the one hand, it refers to the IDE and interpreter included with later releases of

The confusion here stems from the fact that the term QBasic is ambiguous. On the one hand, it refers to the IDE and interpreter included with later releases of MS-DOS. On the other, it refers to the language accepted by that interpreter. Since QB64 is specifically designed to accept that same language (FreeBasic has a mode for this as well), I don't think it's unreasonable to consider QB64 a QBasic compiler. Would you find it similarly unjust if someone claimed to write a game in Python but they really wrote it in PyPy? > QB64, however, is basically just like any other modern scripting language. QB64 is not a scripting language. It compiles the QBasic language (with a few extensions) to C++ and passes it on to gcc. It seems like you're making a lot of assumptions about QB64 when you could instead be looking for facts.

laumars 14y ago
> The confusion here stems from the fact that the term QBasic is ambiguous. On the one hand, it refers to the IDE and interpreter included with later releases of MS-DOS. On the other, it refers to the language accepted by that interpreter. Since QB64 is specifically designed to accept that same language (FreeBasic has a mode for this as well), I don't think it's unreasonable to consider QB64 a QBasic compiler. Would you find it similarly unjust if someone claimed to write a game in Python but they really wrote it in PyPy? But the BASIC dialect that QB64 compiles is more than just QBasic in much the same way that QBasic was an advance on QuickBasic/BASIC. I'm not familiar with PyPy (from a developers perspective) so I can't comment on that comparison. > QB64 is not a scripting language. I didn't say it was. What I said was that it's LIKE a scripting language. And the context of that (which you've kindly cropped out thus distorting the point I was making) was in terms of the way how the language is extended via additional libraries (eg Perl libraries can be Perl modules or bootstrapped from C++ - and QB64 libraries have that same 'feel' to them) and the nature of the language (it compiles to byte code rather than machine code†, the relatively limited scope of the language without the C++ libraries and it's performance, etc). † It's also mentioning here that most scripting languages compile these days too, it's just that few offer a standalone ELF / PE with the runtime included (there's a limited need for the latter unless it's a niche language). Just to be clear, saying something is LIKE something else is a comparison, it's not the same as saying something IS something else. And the very nature of comparisons is that there will be elements of the comparison which are not equivalent (which is why comparisons rarely work in arguments as the opponents will focus in the differences rather than the similarities) > It compiles the QBasic language (with a few extensions) to C++ and passes it on to gcc. It seems like you're making a lot of assumptions about QB64 when you could instead be looking for facts. I've played around in QB64, compiled and decompiled binaries in it and browsed it's source. Where else would you suggest I "be looking for facts"?
- groovy2shoes 14y ago
  > But the BASIC dialect that QB64 compiles is more than just QBasic in much the same way that QBasic was an advance on QuickBasic/BASIC. The QBasic language is almost exactly the same as QuickBASIC 4.5. Every version of any Basic that Microsoft release had advances over previous ones. Furthermore, modern additions to the standard library hardly constitute a language change. > I didn't say it was. What I said was that it's LIKE a scripting language. You're right; I read into that too much. Though I still contend QB64 is no more like a scripting language than QB45 was. I didn't mean to imply that scripting languages cannot be compiled or that all interpreted languages are scripting languages. In my mind, something is a scripting language if it's primarily used for (read: makes easy) at least one of two purposes: automation or extension. Of course, nobody agrees on what constitutes a scripting language just like nobody agrees on what constitutes anything in programming. > I've played around in QB64, compiled and decompiled binaries in it and browsed it's source. Where else would you suggest I "be looking for facts"? Those are good places to look. Documentation is also a good place. I don't mean to be spewing condescending crap, but a lot of the comments in this thread seriously irked me. It's a problem with programming as a field that many (maybe even most) terms are ambiguous or nebulously defined.

laumars 14y ago

> The confusion here stems from the fact that the term QBasic is ambiguous. On the one hand, it refers to the IDE and interpreter included with later releases of MS-DOS. On the other, it refers to the language accepted by that interpreter. Since QB64 is specifically designed to accept that same language (FreeBasic has a mode for this as well), I don't think it's unreasonable to consider QB64 a QBasic compiler. Would you find it similarly unjust if someone claimed to write a game in Python but they really wrote it in PyPy? But the BASIC dialect that QB64 compiles is more than just QBasic in much the same way that QBasic was an advance on QuickBasic/BASIC. I'm not familiar with PyPy (from a developers perspective) so I can't comment on that comparison. > QB64 is not a scripting language. I didn't say it was. What I said was that it's LIKE a scripting language. And the context of that (which you've kindly cropped out thus distorting the point I was making) was in terms of the way how the language is extended via additional libraries (eg Perl libraries can be Perl modules or bootstrapped from C++ - and QB64 libraries have that same 'feel' to them) and the nature of the language (it compiles to byte code rather than machine code†, the relatively limited scope of the language without the C++ libraries and it's performance, etc). † It's also mentioning here that most scripting languages compile these days too, it's just that few offer a standalone ELF / PE with the runtime included (there's a limited need for the latter unless it's a niche language). Just to be clear, saying something is LIKE something else is a comparison, it's not the same as saying something IS something else. And the very nature of comparisons is that there will be elements of the comparison which are not equivalent (which is why comparisons rarely work in arguments as the opponents will focus in the differences rather than the similarities) > It compiles the QBasic language (with a few extensions) to C++ and passes it on to gcc. It seems like you're making a lot of assumptions about QB64 when you could instead be looking for facts. I've played around in QB64, compiled and decompiled binaries in it and browsed it's source. Where else would you suggest I "be looking for facts"?

groovy2shoes 14y ago
> But the BASIC dialect that QB64 compiles is more than just QBasic in much the same way that QBasic was an advance on QuickBasic/BASIC. The QBasic language is almost exactly the same as QuickBASIC 4.5. Every version of any Basic that Microsoft release had advances over previous ones. Furthermore, modern additions to the standard library hardly constitute a language change. > I didn't say it was. What I said was that it's LIKE a scripting language. You're right; I read into that too much. Though I still contend QB64 is no more like a scripting language than QB45 was. I didn't mean to imply that scripting languages cannot be compiled or that all interpreted languages are scripting languages. In my mind, something is a scripting language if it's primarily used for (read: makes easy) at least one of two purposes: automation or extension. Of course, nobody agrees on what constitutes a scripting language just like nobody agrees on what constitutes anything in programming. > I've played around in QB64, compiled and decompiled binaries in it and browsed it's source. Where else would you suggest I "be looking for facts"? Those are good places to look. Documentation is also a good place. I don't mean to be spewing condescending crap, but a lot of the comments in this thread seriously irked me. It's a problem with programming as a field that many (maybe even most) terms are ambiguous or nebulously defined.