The TwinBasic IDE: VS Code

To learn more about twinBASIC, join me at this year's virtual Access DevCon where I will be presenting this exciting new project from vbWatchdog creator, Wayne Phillips.

A good development environment can make or break a new programming language.  That's why I love TwinBasic's decision to use Visual Studio Code as its preferred development environment.

Visual Studio Code

If you regularly write code in VBA, then just about any other modern development environment will be an improvement over the VBA IDE which has not changed much since the late 90's.  One of my favorite development environments is Visual Studio Code.  Here are some of the reasons I like VS Code:

• Open source*
• Lightweight (for an IDE)
• Massively configurable
• Tons of keyboard shortcuts
• Outstanding extension support
• Built-in debugging
• Version control integration
• Built-in debug console (aka, immediate window)
• Built-in terminal (Powershell, cmd prompt, et al.)

Extensions

I want to expand on the extension support in VS Code, because I believe that is its killer feature.  

Quantity

First off, there are a lot of great extensions for VS Code, such as Rainbow CSV.  There's at least one extension for every programming language you could imagine, including Ada, Arduino, COBOL, Commodore 64, Fortran, Pascal, etc.  You get the idea.

Below is a screenshot of the extensions I currently have installed on my home computer.

I should point out that as of this writing, TwinBasic is not available in the Extensions Marketplace.  The version in the screenshot below is a preview version I got directly from Wayne Phillips to prepare for DevCon.

Discoverability

Having a bunch of extensions does you no good if you can't find them or, more likely, aren't even aware they exist.  This is where VS Code really shines.  It has a feature that I will call Automatic Extension Discoverability.  

VS Code monitors the file extensions that you are working on and suggests extensions that you may find helpful.  If I open a blank file named Untitled-1.java, I see the following message in the bottom right corner of the application:

I believe this is how I learned about Rainbow CSV in the first place.  I opened a .csv file in VS Code and a message appeared in the corner of the application that said, "The Marketplace has extensions that can help with '.csv' files."

When you click on the [Search Marketplace] button, VS Code uses the file extension to display matching extensions in order of popularity:

Installation

Here are the steps to install an extension in VS Code:

1. Click the [Install] button

Yep, that's it.  The install runs without any further interaction: no downloading and extracting zip files, no admin prompt, no being sent to some web page where you have to then find the appropriate download link.

After the install finishes, you see a nice welcome page from the extension creator as a separate tab in the interface.  If you are so inclined, you can immediately customize the extension using the gear icon next to the Uninstall button.

TwinBasic Integration

TwinBasic has been built from the ground up to integrate closely with Visual Studio Code.  It achieves this primarily through the implementation of two protocols: LSP and DAP.

Language Server Protocol (LSP)

Here's some info from the official website of the Language Server Protocol:

Adding features like auto complete, go to definition, or documentation on hover for a programming language takes significant effort. Traditionally this work had to be repeated for each development tool, as each tool provides different APIs for implementing the same feature.

A Language Server is meant to provide the language-specific smarts and communicate with development tools over a protocol that enables inter-process communication.

The idea behind the Language Server Protocol (LSP) is to standardize the protocol for how such servers and development tools communicate. This way, a single Language Server can be re-used in multiple development tools, which in turn can support multiple languages with minimal effort.

The great thing about building a language with LSP support is that TwinBasic is not inextricably tied to VS Code as an IDE.  Theoretically, you could use a different development tool that supports LSP.  Or maybe it would just be straightforward to add such support to another tool.  I'm really not sure.  Unlike Wayne, I'm not out here creating new programming languages like it's no big deal.

Debug Adapter Protocol (DAP)

Here's some info from the official website of the Debug Adapter Protocol:

Adding a debugger for a new language to an IDE or editor is not only a significant effort, but it is also frustrating that this effort can not be easily amortized over multiple development tools, as each tool uses different APIs for implementing the same feature.

The idea behind the Debug Adapter Protocol (DAP) is to abstract the way how the debugging support of development tools communicates with debuggers or runtimes into a protocol. Since it is unrealistic to assume that existing debuggers or runtimes adopt this protocol any time soon, we rather assume that an intermediary component - a so called Debug Adapter - adapts an existing debugger or runtime to the Debug Adapter Protocol.

The Debug Adapter Protocol makes it possible to implement a generic debugger for a development tool that can communicate with different debuggers via Debug Adapters. And Debug Adapters can be re-used across multiple development tools which significantly reduces the effort to support a new debugger in different tools.

Just like the LSP, the DAP includes a list of supporting tools beyond VS Code.  This list is understandably shorter, as supporting a debugging environment is much more involved than simply applying code formatting and file navigation.

Image by DWilliam from Pixabay