What were the contributing factors to BASIC playing second fiddle?
Biases aside, I think one of the issues it continues to face is that at some point you need to wrap your head around some C in order to do more advanced programming tasks. It raises the question: "If I have to learn how to read and interpret C to do something like use an external library in BASIC, why not just use C or a higher level C-derived or centered language?"
John, your DLLC SB module is a good example of this, I think. You grappled with using libffi, and first had to learn how to use it using documentation centered on C, along with examples in C, then how to incorporate it into the SB ecosystem.
Then you have the BASIC implementations that translate the code to assembly. Taking those cross platform in order to widen it's exposure is an extreme challenge, as is going from 32bit to 64bit. And you STILL need to interface with C-based libraries at some point. I personally learned this the hard way when I worked on the HotBasic Linux port.
Finally, if a BASIC user decides to learn another language, they have to unlearn so much while also learning a new way to do things. IOW, the skills acquired programming BASIC from a syntax and mind-set point of view don't translate well, in my personal experience.
In the end, I feel that the single biggest reason that BASIC has been relegated to the gray pages of history is the insistence that BASIC must remain "Pure". OOP aside, C evolved with C++/Objective C, PASCAL evolved with Object PASCAL, but BASIC purists throw a hissy-fit if you try to incorporate any sort of dot-syntax/object-based (which is not OOP) approach.
(disclaimer: I'm typing this before having my morning cup of coffee, so if I rambled a bit or if I'm talking out of my arse, that's why. LOL)
AIR.
P.S. Hi John!