twinBASIC Weekly Update

twinBASIC Update: January 2, 2022

Highlights include a feature to generate missing implementations, minor improvements to the Reference List UX, and some spirited debates.

Mike Wolfe

• 6 min read
twinBASIC Update: January 2, 2022

On April 23, 2021, I helped Wayne Phillips introduce the world to twinBASIC at the Access DevCon Vienna conference.  I boldly predicted that twinBASIC (along with the Monaco editor) would replace VBA and its outdated development environment by 2025.  With that goal in mind, this weekly update is my attempt to keep the project fresh in the minds of the VBA development community.

Every Sunday, I will be providing updates on the status of the project, linking to new articles discussing twinBASIC, and generally trying to increase engagement with the project.  If you come across items that should be included here, tweet me @NoLongerSet or email me at mike at nolongerset dot com.

There were over 300 comments made this week over on the GitHub twinBASIC issues site (that's about double the number of comments from a typical week).  I know this because part of my process in preparing this weekly update is to read every single one of those comments to curate the summary you find below.  

So, although there was not a lot of new development in twinBASIC itself this week, there was a large uptick in discussions around the project.  I suppose this makes sense given the holidays: Wayne hopefully took some time off from his impressive development pace, and outside observers had more time to check out the twinBASIC project due to their own increased free time.

Highlights

Experimental Feature to Generate Missing Implementations

There is a new IDE feature that supports creating missing members for classes that implement interfaces.  You can add one missing implementation at a time or you can add all the missing implementations at once:

As of version 0.13.59, the feature also works to add missing event handlers for WithEvents code.

Minor Improvements to the Reference List UX

As of version 0.13.60, the Reference List search box has improved handling for the Enter and Escape keys as requested by Kr00l:

1. ESC key should close the textbox and restore the initial filter phrase when the box was opened
2. RETURN key should close the textbox and apply the filter phrase. Just like now when loosing the focus.

Around the Web

Putting "Import from Visual Basic" to the Test

Over at vbforums, user jpbro reported on his experiences importing an existing .vbp project file into twinBASIC using the new "Import from Visual Basic" feature.

He includes several screenshots from the process and offers some feedback for how the user experience could be improved.  He also identified a memory leak in twinBASIC that's already been fixed.

There were a few bumps in the road, but ultimately he succeeded in getting his application running:

In the end, I'm very impressed with tB so far. It was relatively painless to take a non-trivial VB6 application and get it to compilie with tB. I'm looking forward to seeing tB continue to develop!

Debating the Bit-Shift Operator Syntax

A months-old issue regarding bit-shift operations suddenly sprang to life this week igniting a spirited discussion over on the GitHub issue page.

The issue generated nearly 100 comments in the past week.  To keep the conversation from spiraling out of control, Wayne waded in to resolve the issue once and for all by putting it to a vote:

  • Upvote this comment, "If you are IN FAVOUR OF adding LShift and RShift to the language, as alternatives for << and >> respectively"
  • Upvote this comment, "If you are OPPOSED TO adding LShift and RShift to the language, as alternatives for << and >> respectively"
  • Upvote this comment, "If you are NOT BOTHERED either way"

To be clear, there is no option to REMOVE the << and >> operators from the language.  Rather, the question is whether to add additional LShift and RShift operators as syntactic sugar, as words in general are more "BASIC-y" than symbols.

I voted OPPOSED because I think having two different ways to represent the exact same thing adds to–rather than reduces–confusion.  

Ultimately, though, I think jpbro's comment summarizes my feelings on the topic the best:

To me this whole debate is mind-boggling. The concept of bit-shifting is orders of a magnitude more difficult to understand than the << or >> symbol that represents the operation. If you're knowledgeable enough to understand bit-shifting, then you should be able to understand the symbols for it without much trouble.

I couldn't have put it better myself.

Guiding Principles for twinBASIC Language Design

Ben Clothier opened a discussion to encourage the creation of a set of language design principles for twinBASIC, inspired by the design philosophies of languages like Python and Rust.

I'm a big believer in this approach.  Years ago, I was president of our local youth soccer organization.  While in the position, I created a motto for the organization that doubled as a mission statement: "Learn the Game. Love the Game."

For every big decision we had to make, I would ask the other board members to consider it in that context.  I would ask, "Does approving this proposal help our players learn the game of soccer?  Does it help them love the game of soccer?"  If the answer to both questions was "No," then my vote was always No.  

I found this to be a very useful frame of reference.  It helped me not to lose sight of the forest for the trees.

Getting back to twinBASIC, the biggest value in having a guiding design philosophy for the language is that it helps you know what ideas to say "no" to.  

Innovation is saying no to a thousand things.  
 -Steve Jobs

Automatically Running the EXE After Build

This is currently a project-level setting:

However, this setting will likely be dropped in a future version of twinBASIC.  Instead, EXE projects will have two different build buttons:

  1. Build
  2. Build and Run

Icon suggestions are welcome.

Allow defining UDTs and Declares at procedure scope

Wayne opened a new issue to spark discussion around the idea of declaring user-defined types (and API Declares) inside procedures.  In VBx, these things must be declared outside of procedures and at the top of the module in the header section.

Here's his sample code that demonstrate the proposal:

Private Sub Foo()
    Type POINTAPI
        X As Long
        Y As Long
    End Type
    Declare PtrSafe Function GetCursorPos Lib "user32" (ByRef point As POINTAPI) As Long

    Dim pt As POINTAPI

   GetCursorPos pt
   ' more code

End Sub

This feature would provide two obvious benefits (there may be more I'm not thinking of):

  • Reducing unnecessary scope pollution (why should you have to declare a UDT or API function at the module level if you only intend to use it inside a single routine?)
  • Making code snippets more portable (by eliminating dependencies outside of the procedure itself)

The second point above would especially help with sharing code online.  Lest you write that off as an insignificant benefit, a thriving online community is critical to the success of any programming language.  Making it easier to share code snippets online would go a long way to supporting that sort of community growth.

That said, I don't necessarily think this is a slam-dunk feature for inclusion in the language.  I really don't have strong feelings on it in either direction.

Changelog

Here are the updates from the past week.  You can also find this information by installing the twinBASIC VS Code extension and clicking on the Changelog tab of the extension page:

[v0.13.61, 31st December 2021]

[v0.13.60, 31st December 2021]

[v0.13.59, 28th December 2021]

[v0.13.58, 27th December 2021]

Never miss an article.

Sign up to receive a Sunday morning email with links and recaps of the seven articles published that week.
(I'll never sell your email. Unsubscribe any time.)


All original code samples by Mike Wolfe are licensed under CC BY 4.0