The twinBASIC Family Tree

When most developers see "BASIC" in the name of a programming language, it conjures images of line numbers, GOTO statements, and limited capabilities in exchange for a shallow learning curve.

Among a certain type of programmer, the shallow learning curve is reason enough to reject such a language out of hand.  After all, REAL LANGUAGES have to use arcane syntax, curly braces, and special characters because...reasons.  Though many would never admit it, one of the most important reasons is to keep the undesirables out.  

What would happen if suddenly all the normals realized that programming requires little more than thinking logically through a problem?

Easy to Learn <> Limited Capabilities

The ease of learning (and reading) a programming language's syntax has zero to do with that language's capabilities.

Heavy use of special characters in a language, such as Perl, can boost the signal-to-noise ratio of its code. (That may be a bad example since even the signal looks like noise in Perl.)  You pay that price up front, though, as you need to memorize the special meanings of several characters before you can even begin to understand the code.

And just because you can pack multiple levels of logic into a single line of code, that doesn't change the fact that your short-term memory can only hold about seven chunks of information at a time.  Whether those seven chunks are spread across ten lines of code or one doesn't really matter.

twinBASIC's Capabilities: About the Same as C++

This thought occurred to me as I was writing my weekly twinBASIC update.  

In that update, I mentioned that fafalone created a twinBASIC port of a C++ code sample.  Here's an excerpt from his announcement:

The [project] is a perfect replication of the C++ DirectComposition Effects SDK example, in twinBASIC with x64 compatibility.

If twinBASIC were some hobbled programming language, writing such a port would be impossible.  

So, while the syntax of twinBASIC looks nothing like C++, under the hood both are fully compiled languages heavily based on Microsoft's Component Object Model (COM) technology.  

twinBASIC's Capabilities: Far Beyond VB6

At first glance, VB6 and twinBASIC appear nearly identical.  

After all, one of twinBASIC's primary goals is 100% backward compatibility with VB6.  But that doesn't mean VB6 is 100% compatible with twinBASIC.  When VB6 was released, its niche was as a safer alternative to C++.  With VB6, Microsoft eschewed direct memory manipulation in favor of the Set keyword.  Memory was freed via automatic reference counting, as the language took responsibility for releasing memory when object variables went out of scope.

C# and VB.NET (which both run on the common language runtime [CLR]) were simply the next step forward in the evolution of safe memory management.  The CLR abandoned reference counting in favor of a more complex automatic garbage collection.

The point is that VB6 (and its "successor" VB.NET) were intentionally crippled in the name of safety.  

twinBASIC shares the same safety-first philosophy as VB6.  But, unlike VB6, twinBASIC trusts developers who know what they're doing to remove all the blade guards, riving knives, and assorted other safety features to work as close to the bare metal as possible.

Just how close to the bare metal can you get with twinBASIC?  Two words: device driver.

The twinBASIC Family Tree

I imagine the twinBASIC family tree looks something like this:

• twinBASIC and VB6 are twins, in the same way that Arnold Schwarzenegger and Danny DeVito are Twins, respectively
• twinBASIC and C++ are first cousins; both are fully compiled, COM-based object-oriented languages with no runtime dependency that rely on reference counting for memory management
• C# and VB.NET are first cousins; both "compile" down to a platform-independent intermediate language that runs on the Common Language Runtime (CLR) and uses a more advanced (though less predictable) form of automatic memory management than reference counting
• twinBASIC and VB.NET, along with C# and C++, are more like third cousins; while both pairs of languages are superficially similar in terms of their syntax, their underlying implementations are quite different