It’s been a while since my last post. As promised, I’ve spent the time tending to a variety of personal matters which I neglected during my seclusion producing ModVB Wave 1. One thing I got to do thankfully, was my semi-annual trip to Seattle/Bellevue/Redmond, which I say is for PAX but is really just an excuse to reconnect with my many friends there. I was super happy to see as many of them as I could in that limited time and to catch up with what’s been going on in their lives and catch them up with what’s been going on in mine.
I’m happy to share more of my personal exploits later but most relevant to this post is an individual interaction I had with a friend about my efforts around ModVB. Specifically, he asked (paraphrasing), “Is there are general theme to your future work? Is this all building around one big feature or what?”. Or, in my words, “Where’s this all going?”.
Which is an excellent question. I’m a mysterious hermit who lives in the woods of the South Side of Chicago and periodically I just show up and say some ominous stuff and then disappear. This summer I dropped some language features on you and crawled back into my hole for a bit. All fun, but maybe not as comprehensive as this effort deserves. Fortunately, I have (and have had for years) a massive itinerary (just outline of the language improvements is 10 pages to date) in my head and in OneNote and in Word docs that I’ve been building and following that could easily take a hundred or more of printed pages to detail so I’m not at a total loss for an answer.
It’s just a matter of giving you the forest and not the trees and so I set about sitting about and distilling that roadmap into this post. Hopefully it gives a better idea of the scope of things to come.
The VBest VB that ever VBed
No, seriously, if you take all of the good stuff that VB has been over its life and follow that throughline to its greatest expression in all aspects of the end-to-end experience without compromise, that’s what I’m trying to build. I don’t want there to be any lingering questions of what VB could have been if only things had been different. I want to build that thing, or at least my interpretation of that thing based on decades of experience using it, analyzing it, designing it, and communicating with other community members about their experiences, desires, and needs while using it too.
Still have questions about what that means or what it looks like? Well, over the next 1-2 years of building it I expect to design, discuss, initiate, or produce enough artifacts that you don’t. That’s the journey. Now let’s get a little more concrete about 3 layers being built.
- Core Language Experience: I want to build a massive, robust extension and modification of the vanilla VB.NET language and tooling that evolves, modernizes, and refines the language for current and future enthusiasts in a self-consistent manner.
- Extended Tools & Experiences: I want to build additional tools to enhance the VB experience beyond the core modified language to support certain platforms, technologies, and scenarios.
- Community: I want to build a self-sustaining community of VB enthusiasts around this modernized end-to-end experience.
These three layers make up the VB.NET UX I’m trying to build: language, tools, community.
Building for the enthusiast, not the user
Notice that I keep using the word enthusiast rather than user. Anyone can be a user just by using a thing. They don’t have to like or love the thing or have any particular attachment to the thing. They may even hate the thing. I’m not talking about those people. There is no victory to be claimed in planning anything around an audience that isn’t at some level already bought-in or capable of buying in to what you’re building. A VB enthusiast should feel like a kid of Christmas morning about this endeavor: they may not know what’s in the giftwrapped boxes but they’re excited. I want to justify and grow that excitement. If you don’t care, that’s fine, you just probably shouldn’t be reading my blog and I definitely shouldn’t be trying to court your approval. Personally, I believe it would be healthiest for the VB community to as much as practical consist of enthusiasts rather than users. This doesn’t mean they aren’t “real developers” or that their projects aren’t “real apps” and it doesn’t mean (primarily) people who aren’t getting paid to build software, but that the ones who are getting paid are enthusiastic to come into work and work in VB every day.
For a long time due to its popularity with businesses VB has accrued all sorts of users, including an unfortunate lot who were forced to use by circumstance. The problem is that group produces an awful lot of noise when planning and prioritizing feature work because ultimately they want to use something else entirely and they want VB to just become that other thing. I want VB to be a language of choice, not force, and to cultivate a community of folks who choose VB because the “Spirit of VB” resonates with them and empowers them. I can wax philosophical about the “Spirit of VB” for pages (and I know I must do so soon) but for the sake of some brevity I’m going to try to keep this post a little more concrete.
Breaking down the VB experience
Back in my Microsoft days, once a year during MVP Summit I’d get a chance to meet with the brightest minds in the VB community (diehard enthusiasts and absolute professional badasses) and present an early preview of what we were working on and get their feedback and hear their pain points from real world projects that they wanted solved in the next version (hopefully). In the later years, as lead language designer, it fell on me to not only participate in the summit (which I loved doing) but to present Microsoft’s side of the conversation for VB. I took to a format that I styled the “State of the Language Address” whereby I broke the VB experience down into four areas of concern for the VB audience:
- Platforms & Technologies
- Language & Runtime
- IDE & Tooling
- Community & Content
For each area we’d summarize the feedback we’d heard from the community over time, how we’d reacted to their feedback, and what our next plans were for the area. Having found this a useful structure in the past, I will frame the rest of this post around these four areas. Typically platforms & technologies would be the top-of-mind area for MVPs and I still think it’s the most impactful but for this post I’m going to lead with the language because a key priority for my language modding efforts is investing in features which enable broader platform reach, particularly in Wave 2.
Language & Runtime
As I mentioned earlier, I have a 10-page outline of just the language modifications I intend to produce over the next… 18-months(?) or so. Some are bigger, most are small, all are doable and I believe genuinely in the spirit of the VB language; they fit with the values VB has articulated thus far and will be designed and added in a manner which is natural and self-consistent.
Originally, I broke this outline into 4 major categories:
- Modernization—New functionality added to service modern scenarios or modern platforms. E.g. XAML Literals, JSON literals/pattern matching.
- Evolution—Enhancements that extend an existing construct to its logical “next step”, e.g. query operators in `For Each` loops.
- Streamlining—Reduction and in some cases elimination of boilerplate/ceremony in common scenarios or polishing “rough edges” in a scenario, usually through some addition to make the language more self-consistent, e.g. type-inference improvements.
- Bugfixes—Changes made purely for self-consistency, correctness, interoperability, or code-optimization, e.g. new implicit line continuation, VB runtime performance improvements.
In addition to language changes I intend to release a modded VB runtime with new support types and other enhancements as the language evolves. For the time-being I’ve baked these changes into projects compiled using ModVB as embedded code a la VBCore.
Those categories still hold true but I’ve since found it more practical for communicating with my readers to describe them in terms of time, specifically 6 or more “waves” each with a particular theme. Each wave is not exhaustive—every conceivable feature under a given theme won’t be added in that wave. Rather, I have prioritized certain features in that them around the need for feedback, the risk of adding them, size (time), and impact (the usual suspects). I’ve summarized the first 5 waves and beyond below.
Wave 1 – JSON
The first wave released this summer and was centered around JSON Literals and Pattern Matching.
This wave was intended to be short and to prove out the possibility of shipping language features via VSIX and NuGet at all. It is but a prelude—an amuse-bouche—to the full scope of language enhancements that are planned. In fact, it’s not even the complete story I imagine for JSON or pattern matching, both of which have deeper integrations on the backlog. Having said that, it was successful at its purpose and an update based on feedback should be released before Wave 2.
Wave 2 – XML
It is not my intent to be hyperbolic when I say this. Wave 2 contains the most important features that could ever be added to VB.NET. Seriously, if just these features were added and nothing else it would constitute a full step forward for the language over where we are now, though fortunately we won’t have to make that trade. The core feature of the wave are enhanced XML literals (every day I wrestle with calling it XAML literals though it just as well could be called HTML literals too), a feature I prototyped back in 2019 but am now rebuilding The Right Way™ along with the support feature of top-level code.
As demonstrated in these videos, these two features combined create a story for VB.NET building modern apps for web and mobile using ASP.NET Core and
Xamarin.Forms .NET MAUI and untold other DSLs for other technologies.
I do have work to do to account for the changes from Xamarin.Forms to .NET MAUI though from preliminary investigation MAUI is an evolution of Xamarin.Forms and adheres to the same design patterns. Libraries implementing the XML patterns for web and MAUI are being developed in lockstep with the patterns themselves. I have not had a chance to deep dive into the story for Blazor but the F# technology Bolero which enables F# developers to make use of Blazor tech to bring F# to the client-side gives me confidence that the system is open enough for VB to also benefit from Blazor, provided the right experience in the language. Alternately (or additionally), the OpenSilver project (which provides a plugin-free open implementation of Silverlight based on modern web tech) may also be a great opportunity to bring rich modern web application development to VB.NET!
This is the approach F# uses to reach new platforms and it works. I’m determined to use it to bring a high quality web and mobile story to VB.NET as part of the ModVB project.
I believe this work, especially when combined with the Roslyn scripting API (which will one day be completed for VB if only in this mod) will unlock the ability to create UI previewers/designers and other tools.
A detailed deep-dive into the design changes I’ve made since I wrote those initial prototypes as well as the libraries I’m writing alongside the features as part of Wave 2 to support web development and .NET MAUI will be the topic of a future post.
Wave 2 is planned for release around December 2022.
Wave 3 – Productivity
A grab bag of 4-7 productivity features I’ve been itching to add and demonstrating remarkable self-control by not adding. They’re all small to medium in size compared to waves 1 and 2 and will likely be released one at a time. I simply need to get these things out of my head.
Wave 3 doesn’t have a forecasted delivery window though waves are intended to be 2-3 months in duration.
Wave 4 – Async
I vacillate back and forth on whether this and wave 5 should be swapped. Today it comes first because the LINQ related features are all pretty straightforward and making any changes with Async deserves plenty of bake time to ferret out bugs and react to feedback. There are several missing pieces to VB’s Async story, e.g. an `Await Each` construct, `Async Iterator` methods, `Await` in `Catch` and `Finally` blocks, and more. Not every feature will be included in Wave 4 for time reasons but by the v1.0 release of ModVB I plan to address them all.
Wave 4 is after Wave 3.
Wave 5 – LINQ
There are no surprises in Wave 5. It’ll include deeper integration of LINQ into the language and revisiting several features added as part of the initial LINQ release way back in 2008. For example:
- Integrating query operators into the For Each loop.
- More expressivity in object member and collection initializers
- Range expressions
- Possibly more query comprehensions
Wave 5 is after Wave 4.
Wave 6 and Beyond
OK, so technically there isn’t a “Wave 6” so much as everything else is post Wave 5. This is where the less glamourous or most difficult work goes. Bug fixes. Optimizations. And one or two … high-cost/risk features like Nullable Reference Types live. This is the long tail of quality-of-life features, advanced features, and edge cases (many of them long requested by the VB community) that will easily eat up 60-80% of the time on the project. I may try to plan several formal waves or I might just loop through the list picking off low-hanging fruit until it’s all done.
So, for example, for ever VB users have been asking for Modules that don’t automatically promote their members to their parent namespace. I absolutely will address this request after over a decade of fielding complaints about it. It’s not super impactful or risky, so it’s just “on the list”.
A Note on Language Stability: My plan isn’t to release a million features every year. Many of the features alluded to above are long overdue and if I’d had my way would have been completed years ago. For this reason, I’ve built up something of a backlog. But after the v1.0 release of ModVB, I expect language iteration to comparatively slow because it’s simply not necessary to shatter the earth with every release of a language. I intend to code in VB.NET until they pry it from my cold dead hands. But I don’t intend to try to re-invent the fundamentals of programming every release in order to keep up with any other language; every major release won’t be Generics, LINQ, Async, or even dynamic. I truly believe that with the set of features I’ve collected VB.NET will be in an incredible spot as a language and will need relatively few new general purpose features. Instead, I intend to pivot to more evolution on the end-to-end tooling of VB.NET to recapture as much of that magic that’s always kept the language ahead of the pack. I say all of this not to dampen expectations; this isn’t a policy thing and I’m happy to be proven wrong. Rather, I say this to give the more cautious developers assurances that I’m not going nuts and throwing everything and the kitchen sink into the language. It’s not going to look unrecognizable when ModVB v1.0 releases and I intend to keep the pace of change sustainable after that.
Platforms & Technologies
As mentioned above, my immediate concern for Wave 2 is unblocking ASP.NET Core and .NET MAUI. In addition to the language features described in Wave 2 I will be shipping runtime extension libraries for .NET MAUI as well as a brand new VB-targeted web programming library and several templates for using both. Blazor will hopefully come at a future date. I might do a proof of concept for a web UI designer sometime after Wave 2 is complete but I don’t expect any serious pursuit of such a tool until after v1.0 particularly as this may require completion of the long in limbo Roslyn-based VB.NET Scripting engine.
Other technologies such as Unity are interesting to me because they’re interesting to VB enthusiasts though it isn’t an urgent concern; happy to collaborate with anyone who’s more fluent in that space about their needs or opportunities to light something up here.
IDE & Tooling
In addition to the core support for new language features in the VS editor I also plan a slate of VS extensions to supplement the VB experience. In fact, I’ve already started development on one that’s near readiness for a release but I’m pausing work on it while I finish Wave 2.
I’m very interested in partnering with anyone who has the know how of how to plug ModVB into a .NET Interactive/Polyglot Notebook.
Long term (as we approach ModVB v1.0 release—late 2023/early 2024) I expect to pivot toward looking for a cross-platform IDE for the modified VB language. The open-source F# Ionide and C# OmniSharp plugins for VSCode should provide excellent instruction for where to begin here and again I’d love to collaborate with anyone with expertise and interest in this area.
Community & Content
As I mentioned above, my endeavor is not merely to create a modified version of the VB.NET language but a revitalized VB.NET community around it. To that end, in early 2023 I will be launching a new community web site to promote and educate VB enthusiasts about a variety of topics, including this and other mods, news, and other tools in the broader VB.NET ecosystem. I would like to make this new site a gathering place for VB content from other community members with an aggregate blog, forums, and technical articles. The big question now is whether to roll something out based on an existing web hosting provider like WordPress or roll my own using the ASP.NET Core support I’m building in Wave 2.
I’m excited to be working to bring new capabilities to the community, not least of all because I love VB.NET and absolutely want to use it on all of my future projects, personal and professional. I’d love to talk more often and in greater detail about the design process I’m following but it’s hard. My (unsustainable) process has thus far been to quite literally seclude myself from the world and focus (and re-focus) myself relentlessly toward the next goal neglecting everything else in my life.
When I wrote “An Exhausting List of Differences Between VB.NET & C#” I literally hermited myself in my apartment for 5 or 6 straight weeks where I did little but eat and write. I didn’t even do laundry or clean my home. The journey to Wave 1 this summer was very similar; I was literally buried in
trash recycling by the end of it. I have no work-life balance, I think, because of my mental health struggles. I also have mental health struggles because I have no work-life balance. To do this project I have to wear every hat in the development process from PM/dev/test to marketing and docs. I have the experience to wear those hats but not all at once and switching modes is especially challenging. It can just be so hard to focus and stay on task and I build up so much guilt and self-loathing about not being faster or more consistent or more communicative. So often I just want to crawl into a hole and stay there. But when I muster the strength to crawl out of that hole all I can think about is all the wonderful stuff I want to build with and for VB.NET. Even in my depressed moments that’s what I’m thinking about. I realize, this is my life’s work.
I bring that all up to say, this week after dodging it for 30+ years I was diagnosed with ADHD and have been prescribed some meds to help me focus. I’m really really hoping this new chapter in my mental health journey will let me find more balance and that will be good for me and for you all. Thanks for your support and continued patience.
Look out for…
- Wave 1 Update 1 soon
- Wave 2 circa December 2022
- More design discussions from me sprinkled throughout
Everything we need is doable. Much of it has been done before. There will come a time for almost everything. We may be taking steps back but when we leap forward I believe we’ll be in a much stronger position than ever before.
The answer to “Where’s this all going?” is… Everywhere.
I am excited. You are a dreams make Anthony, and I wish you a good health and a long peaceful life.
Hi Anthony – I work on Excel-DNA, an open-source library to help create Excel add-ins with .NET. I would be very interested in knowing or discussing your thoughts about the VBA world, and how the ModVB improvements and your future vision might help VBA ‘enthusiasts’ take advantage of the .NET ecosystem through VB.NET.
An example of a relevant issue I’ve run into is that XML literals in VB.NET don’t give a good editing experience for creating the xml markup needed to describe Office ribbon extensions – I vaguely recall that this might be related to a lack of xml namespace support.
I’m also interested in knowing how one might use your ModVB extensions in a custom IDE we are building (based on Roslyn, but no VSIX services).
If you’d be interested in hearing a bit more about Excel-DNA, or these ideas, I’d be very happy to hear from you.
For the Excel user world that I try to keep in touch with, I don’t think there has been any movement away from VBA. While the official Microsoft policy is to focus all their development and support for extensions on Office JS, uptake seems very low, but I have no numbers. While the Excel Uservoice site was run, for many years the overwhelmingly most popular request was for Python integration. The Windows desktop version of Excel allows good integration for third-party add-ins written in any language, through a combination of the still-supported C API and the COM interfaces. In addition to Excel-DNA (for making add-ins with .NET) there are good third-party Python, Java, Rust etc. options using this approach. All of these still have very high friction compared to VBA, so they are mainly used by corporate or professional developers who have some other reason for picking the language and framework.
So in 2022, the ‘real’ Excel where people build complicated models and where companies target their extensions (especially internal ones), is still the Windows desktop edition. And the main Excel enthusiast and corporate power user extensibility language is VBA, using the ‘stable’ VBA editor. I think the web-based and cross-platform Excel is used in the roles the Google Sheets is – publishing reports, capturing lists, that kind of thing.
VBA can’t go away or be replaced, but I believe there is a (small) subgroup of VBA users that might benefit from using .NET. And for some of these, VB.NET might be more approachable than C#. The numbers involved would then suggest this could be one of the main sources of new VB.NET users in the coming years. And that’s why I think that any consideration of the future VB.NET should also be mindful of where VBA users could fit into the picture.
There is a flip side, which is that for many .NET developers, it can be very powerful to expose their work to users through the Excel interface. It might be making some web services easy to call from Excel or exposing some knowledge or logic in a way that is easy incorporated into Excel models. Excel-DNA lets this integration work be done in the same framework and language as the rest of a system.
This is a prof of concept that Blazor low level component classescan be written with VB:
The missing brick isto allow write high level components with XML literals and parse them to generate the component classes (Source generators will be helpfull here to add these classes to compilation). This will not differ than what is done with ASP.NET and WPF in ModVB.
So, let’s wait for wave 2 and see what we can do.
Do you have a blog? You should really post somewhere about your experiments with Blazor. Would make good reading!
If fact I didn’t dig deeper into Blazor, as I was busy developing Small Visual Basic (and other stuff) over the two past years, but I can start now, especially .NET 7 is about to release, and I expect Blazor to be mature enough now. So, I will try to provide something that can be usable in ModVB.
Antonio, thank you so much for all this! Undoubtedly you are the hope of the VB world today with VB.NET, you will make history and will be immortalized as the person responsible for making VB.NET one of the best and most used programming ecosystems in the world.
You just won an enthusiast!
My personal project now will be to continue studying to be able to effectively help in the development of this new future VB
Thank you for all of this!
Great post Anthony! Simplifying web development is a great idea. On the other hand, I’ve often wondered why we don’t adopt the gaming or phone app model where we just download an app from whatever website we want and then use that app for shopping, searching, whatever. It seems like it would make development MUCH easier since it would be a normal desktop app instead of a web app. It would also be far more efficient since the only thing needed to be passed over the net would be user input and data… i.e. none of the UI stuff.
While what we’ve been able to create by building a complete stack on top of basic text processing is impressive, it’s still the lowest, slowest common denominator method of “programming”… just slightly above smoke signals.
Pingback: Checking In (Wave 2) | Anthony's blog
For all those who love BASIC. Here’s a fascinating video about its origins at Dartmouth College in the early 1960s.