4 ms·

QuickBasic could do this (IIRC it generated an EXE that bundled a bytecode interpreter along with your code). The slightly later QBASIC, which was a cut-down ve

QuickBasic could do this (IIRC it generated an EXE that bundled a bytecode interpreter along with your code). The slightly later QBASIC, which was a cut-down version of QuickBasic distributed free with DOS, couldn't make an EXE. The best you could do was to make a .BAT file that invoked QBASIC with the right options. It's amazing, in retrospect, how important it felt to create a "real EXE". Nowadays, we write huge professional systems in scripting languages that need explicitly invoking with an interpreter - but back then, "grown up" programs were the ones that didn't need that.

snuxoll 9y ago
To be fair, when you're on a UNIX-like system a program written in bash or a scripting language doesn't look any different from a compiled C binary from the endpoint of the user - shebang lines and the execute bit were a honking great idea. The whole issue with creating a "real EXE" was it was incredibly obvious when your program WASN'T an EXE on DOS and still to this day on Windows, to this day it still irks me when I download something and there's a .bat file to launch it - but I could care less if there's some wrapper shell script on Linux.
dceddia 9y ago
I remember this feeling too. It was one of the big motivations for me to learn C, back then: the ability to create a real .EXE that didn't need an interpreter. That, and the lightning-fast startup time of compiled programs. I remember simultaneously being excited about the fast startup time, and also feeling that my program didn't seem "real" if it finished its operations too quickly. Real programs took time to do things, and something about it felt fake when the program responded immediately.
dwyerm 9y ago
Sure, but now you've got the problem I've been dealing with day-to-day: You need to launch your code using a specific version of the interpreter that has been pre-loaded with all the specific versions of the libraries that you need. This is why Go's ability to compile to a self-contained, QuickBasic-like, exe makes it attractive to me.

snuxoll 9y ago

To be fair, when you're on a UNIX-like system a program written in bash or a scripting language doesn't look any different from a compiled C binary from the endpoint of the user - shebang lines and the execute bit were a honking great idea. The whole issue with creating a "real EXE" was it was incredibly obvious when your program WASN'T an EXE on DOS and still to this day on Windows, to this day it still irks me when I download something and there's a .bat file to launch it - but I could care less if there's some wrapper shell script on Linux.

dceddia 9y ago

I remember this feeling too. It was one of the big motivations for me to learn C, back then: the ability to create a real .EXE that didn't need an interpreter. That, and the lightning-fast startup time of compiled programs. I remember simultaneously being excited about the fast startup time, and also feeling that my program didn't seem "real" if it finished its operations too quickly. Real programs took time to do things, and something about it felt fake when the program responded immediately.

dwyerm 9y ago

Sure, but now you've got the problem I've been dealing with day-to-day: You need to launch your code using a specific version of the interpreter that has been pre-loaded with all the specific versions of the libraries that you need. This is why Go's ability to compile to a self-contained, QuickBasic-like, exe makes it attractive to me.