Checking in (Wave 2)

Season’s Greetings, All,

I hope this holiday season finds each of you and your families in good health and good spirits. I tried to get this update out before Christmas, but it was not to be. I have several announcements (all positive) to make across several topics both near and far. I know everyone’s wondering what’s the deal with “Wave 2” given that it was supposed to have a release or some demos out this month and I will get to that in this post, I promise, but first I want to get a few quick but important asides out of the way.

Patreon Launch Update

First, let me say a gigantic THANK YOU! to everyone who responded to my call to action regarding my new Patreon. Thanks to your support I’m already well on the way to my first fundraising goal! I’m very pleased with the initial uptake and will be working on getting those tier rewards out ASAP. Every drop of support means the world to me in both a very practical way and in a psychological way. It really keeps the fight in me to know other folks still give a darn.

Also, got some part-time freelance VB contract work, one project of which is thanks to a Patreon supporter answering my call for opportunities. Working on VB projects is always a dream come true so thanks to that special supporter for this opportunity and for the rest of my supporters, please keep ’em coming!

“Wave 6” Theme Update

I wouldn’t normally concern you all with an update on something so far out but I wanted to give my readers some assurances that I have been paying attention to their pain points and am making plans to help. Originally, I didn’t have a clear vision on any specific themes after “Wave 5” (which is themed after LINQ). However, based on observation, a theme for “Wave 6” has emerged around C# interop. More specifically, I’ve seen a number of VB users being blocked by new APIs both in the .NET 6/7 profile and in 3rd party libraries that use features such as the `unmanaged` constraint, stack-only “ref” structure types, and similar scenarios. Some cases where VB is being blocked, such as `required` members, are already being worked on by Microsoft and I sincerely thank them for it, but others they have announced no plans to address. I recognize the pain this causes VB users who are blocked from using these APIs and will be dedicating an entire milestone to designing and implementing some degree of support to unblock you, particularly with a focus on consuming these APIs and I wanted to share that intention with those impacted sooner rather than later. The wave plan is pretty fluid after “Wave 3” balancing several factors including the need for earlier design feedback but another factor is urgency so I may pull this new “Wave 6” in earlier. Stay tuned.

“Wave 2” Scope Update

“Wave 2” is all about unblocking new platforms through the repurposing of VB XML Literals syntax to enable declarative UI development on the web and cross-platform mobile development. This has always been the plan. What’s changed is that for a while now (years, in fact), I have been very cautious in describing the centerpiece feature of this wave as “Enhanced XML Literals”, “Target-Typed XML Literals”, “Pattern-based XML Literals”, or “a XAML-like syntax”, very intentionally avoiding the term “XAML Literals” because that term makes certain promises that I wasn’t willing to casually commit to. My intention was always to target a strategic subset of XAML syntax that would coincidentally produce the same result in common scenarios as what is used in Xamarin.Forms, but wouldn’t be bound to the full breadth of scenarios of a technology like WPF or the formal XAML specification. And for what I prototyped back in 2019 that was good enough.

What’s changed is the scope of technologies being targeted. WPF (and UWP) already support XAML design/code generation for VB.NET projects. The missing stories were ASP.NET Core for Web and Xamarin for Mobile. Xamarin.Forms (and by extension .NET MAUI) was designed to mimic the idioms of WPF but is implemented very differently in how those declarative idioms are translated to code. In places where WPF (and Silverlight) re-invented certain programming constructs in a distinct way from the .NET languages, Xamarin often embraces the “C#”-native way of implementing those idioms. For example, for control- and data-templating, WPF uses an arcane infrastructure behind the scenes using factories to instantiate controls, repeatedly in the case of `ItemsControls`, at runtime (deferred) given a declarative template written in XML. Xamarin.Forms on the other hand embraces lambda expressions. A lambda expression is the idiomatic way in C# (or VB or F#) for passing instructions to an object for how to construct something in a differed way that can then be called into over and over again. If you look at the constructor for the Xamarin.Forms DataTemplate class, it takes a Func(Of Object). WPF by contrast is not nearly so straightforward to use in an imperative code-only way.

Because I only needed to go after Xamarin.Forms, my design for the factory patterns an XML Literal would translate into were pretty narrowly targeted at what would unblock declarative Xamarin.Forms capabilities in VB with only loose consideration of what kinds of patterns would be necessary to target non-trivial WPF expressions.

With all that said, the scope of technologies I’m now pursuing has changed. I’m now targeting:

To be clear, though this might smell like “scope creep” as a language designer this is a really good thing! Designing a feature around a broader set of scenarios generally yields better, more generalized features with greater applicability, which is generally preferable to the accumulation of one-offs.

All of these potential targets are being actively and holistically considered in the design and implementation of this feature. Avalonia UI is the critical addition to this list because unlike Xamarin.Forms it embraces a very WPF-like translation of declarative XAML into .NET objects. Additionally, in designing the patterns for translation I am acutely aware that 1) someone will have to write the “builder” libraries that enable support of a particular technology and their life shouldn’t be overly tedious (e.g. they shouldn’t need to explicitly code support for every dependency property or conversion in an entire framework), and 2) VB users will want to consume 3rd party components written targeting these technologies that have no knowledge of this feature, or themselves may implement controls or user controls targeting those technologies and that I do not want to place a burden on those VB users to mediate integration of those components with the feature.

All of that has led me to the conclusion that I must embrace fully* the XAML-osity of the feature to provide the best experience for VB users. I’m effectively designing and implementing a XAML “meta-processor” inside the VB compiler—a feature that allows one to efficiently describe and implement multiple technology-specific XAML processors in a prescribed way. This design shift raises the bar significantly for the feature but it’s also very liberating in that I don’t need to employ as many workarounds to support certain scenarios in indirect ways. For example, markup extensions (e.g. {Binding}) until now were a concept I wanted to be completely opaque to the compiler with it passing enough information to the builder library that it could then parse and interpret those markup expressions at runtime. Or certain elements of the XAML language like x:Name, x:Type, and x:TypeArguments that are defined by XAML which before were meaningless to the compiler itself and very complicated to reproduce at runtime. Those are restrictions I placed on myself, but now these are things described by the formal XAML specification that the compiler can fairly know about.

I know some folks might find such deep integration of yet another language into the VB language/compiler distasteful and it’s absolutely not a coupling I take on lightly but over the last 14 years, time and time again new technologies have taking bets on the XAML language and I believe it is now stable enough, mature enough, and enduring enough to take a bet on too, not unlike the bet VB (and C#) both took on the SQL-like syntax of LINQ.

That said, even though I’ve fully* embraced “XAML Literals” as the north star of the feature I still put an asterisk on that word “fully” because I want to be clear that I’m still very consciously constraining myself on the minimal integration of concepts absolutely mandated by the XAML spec (with which I’m now becoming intimately familiar) and required to support these targeted platforms. I fully believe that “limitations foster creativity”. Accordingly:

Examples of things I’m ok with the language having some awareness of now:

  • The basic conventions of XAML with regard to object creation and member setting (including “attached” properties and events).
  • Things in the x: (xaml) namespace.
  • That an attribute value represents a markup extension.

Examples of things I’m NOT ok with the language having any awareness of:

  • Any particular technology or assembly names.
  • Any particular technology namespaces.
  • Any particular type specific to any particular technology (e.g. FrameworkElement, MarkupExtension, ContentPropertyAttribute, DependencyObject/DepedencyProperty).
  • Type converters

I’m holding the line on the latter list, which means building the necessary layers of indirection for those scenarios. Every concept the language understands must be very carefully considered, even with this bold new shift. For example, I don’t want VB to “know” about type converters. It’s OK for a builder library to know about them but not for the language to know about them. They come with a lot of design baggage and raise questions I really don’t want to answer right now such as “Why do XAML literals understand and use type converters, but the basic casting syntax does not?” and that would be a fair question if the language or compiler did actually know about them. But as I am implementing them, these dependencies are properly hidden behind the abstraction of a XAML conversion without a direct requirement on how such a conversion is implemented. Further, such knowledge isn’t even hinted at by the XAML specificationthe term type converter does not appear in the spec even once—this is an implementation detail coincidentally associated with WPF but not strictly mandated by the XAML language per se.

Oh, and FYI, here’s a picture of an Avalonia UI app running on Android built using VB!

So, yeah, in summary, they’re called XAML Literals now. I gave up (for the better).

XAML Literal Entanglements with “Wave 7”

OK, technically this isn’t an update because I never told anyone this to begin with but it’s impacting the schedule so I’m sharing to be a little more transparent. There’s a critical piece of the pattern of XAML Literals that was designed in a certain way that’s a little… special. But the plan was to have this specialness be a subset of some specialness that I’d expand on more in “Wave 3” with an otherwise unrelated feature. This matters cause if you do a thing once in a language it’s a one-off, but if you do it two or three times it’s a design pattern and that’s legit so that plan was to do both things the same way and introduce a new pattern.

The problem is that the feature in “Wave 3” also needed to be reconciled design-wise with the existence of source generators—a feature of both the VB (and C#) compilers that Microsoft introduced “recently”. UI frameworks are squarely in the set of core scenarios for source generation and the democratization of source generation should make any language designer consider very careful what goes in the language and what goes in a generator. Until recently I’d written a “TODO” to reconcile new features with source generation with a note that some of the stuff in waves “2” and “3” could change drastically or disappear once I took a serious look at source generation “in the future”. The idea of presenting to you all a design in “Wave 3” which could be obviated entirely by source generators just kept nagging at me so this month I took the time to seriously think through how the mysterious feature in “Wave 3” and source generation would co-exist in one sensible experience and the short of it is that the entire design of the feature in “Wave 3” was obliterated. The design made a lot of sense before source generators were shipped (I’d started designing it at a time when source generators seemed very complicated and unlikely to release) and with them having released, putting some serious design thought into it caused me to throw away … everything other than the end-developer experience I’m holding to, though the implementation will be completely different.

This design sidebar crystalized to me that the theme behind “Wave 7” would be exploring the impact of source generation on language design further. The feature tentatively in “Wave 3” might just move back to “Wave 7”. “Wave 7” might move up. And the piece of design shared between XAML Literals and the feature in “Wave 3” either becomes a strange one-off in the language or needs to be changed. So, I’m changing it to align with the design pattern I now anticipate using elsewhere in the language. It’s coming along well. It simplifies the design, actually. It’s not nearly as “clever” as it was before which is a surprisingly hard to let go of for some reason, but ultimately better for everyone else but my ego. As part of doing things The Right Way™ for ModVB, I strive to never ship an implementation which I can’t say in good faith is expected to be a durable design or implementation. Prototype code is meant to be throw-away, what ships in ModVB is not.

Conclusion

“Wave 2” did not and will not release in December 2022 as planned due to valuable design changes, namely: targeting Avalonia UI to enable cross-platform UI development in VB for Windows, MacOS, Linux, Android, iOS, and the web; embracing the XAML specification as a first-class goal; and the integration of forward-looking design intentions from “Wave 3” and what is now coalescing as “Wave 7”. Implementation is otherwise going well and the deliverables for “Wave 2” are now expected in January 2023. I promise that I believe these changes were the right and necessary decisions to make given the information at hand and look forward to showcasing the fruits of all this labor early in 2023.

I thank everyone for their continue patience and support and wish everyone continued Happy Holidays and a very Happy New Year!

Regards,

-ADG

Path to Sustainability

In my last post, I discussed the high-level “what” of my current endeavor—to fully actualize the design potential of the VB.NET experience. This post is a little more practical about one necessary aspect of how we get there and sustain everything that’s built along the way.

To be blunt, this is a post about (crowd)funding and there is a Patreon call-to-action at the end but ultimately, I want to create a more robust solution that is community-centric rather than company-centric or me-centric and that’s what I’m going to talk about first. I’m going to lay out my long-term vision for how the VB.NET community can collectively sustain itself in an independent way and then in the second part I’m going to talk in a very pragmatic way about how I can maintain my own level of contribution through the short- (read: starting today) to medium-term. Both the long- and short-term views, I believe, are critical to ultimate success so I encourage you to read through both and understand if, what, when, and how you see yourself contributing.

Long-Term Vision

I remember a few years back catching a Tweet from Xamarin founder and then Microsoft Distinguished Engineer Miguel de Icaza advocating for the unionization of tech workers. I had been questioning (in my own head) for a while the assumption that as software developers we already have it “so good” that we don’t need unions and that beyond wages and benefits packages there’s not really value to be added for the tech worker. I don’t believe this assumption and I was so glad someone else in the industry and someone so successful therein had said it out loud.

Continuing this as a thought exercise I considered that employees aren’t the only other participants in the business of technology who could benefit from the ability to collectively organize, bargain, and act. The customers are often also at a huge disadvantage in the relationship with big tech. If you build on any technology produced and controlled by a singular corporation, you’re at the mercy of that corporation and whatever its transient agendas are. And if one day that agenda requires or benefits from, bluntly, abandoning that technology, as an individual developer or even a small-medium sized company with a large investment in software built on that technology your options are often few. This power imbalance becomes more drastic when doing business with multi-trillion dollar massively diversified companies like the ones that lead the tech industry in the US and abroad.

My thinking in the moment was, wouldn’t it be an interesting dynamic if, for example, a large portion of Microsoft Azure subscribers could “go on strike” to prevent the sudden and rather graceless abandonment of, e.g., Silverlight, etc.

That idea is ridiculous. Or at least, improbable, I think, but the point of the thought exercise remains that a more equitable structure between the producers and consumers of technologies would benefit consumers. And philosophically, this isn’t about VB.NET alone—we all could rattle off a long list of successful productive technologies that have gone out of favor with their original creators. If the business is looking out for the shareholders, and a labor union is looking out for the employees, who’s looking out for the customer?

Fast forward some thinking and research, and you come to the idea of a consumer cooperative. An organization collectively owned and managed by its members—the consumers—which optimizes not for profit but for consumer value. I would like to see a collective, technology adopter-owned model gain traction in the industry. The membership would be made up of individual developers and companies that adopt one or more related technologies. Some members would contribute to the development of those technologies and the membership would democratically make decisions on how to manage the lifecycle of those technologies, presumably without disproportionate regard to fads or any one member.

And again, I’m not saying this just as a VB.NET enthusiast but honestly as someone who’s followed the full Microsoft technology stack for like 20 years now. I’m just fatigued with the cycle. I’m tired of feeling anxiety about Thing K because other Thing M came out. I’m not saying new technologies shouldn’t come out, or that as consumers we should never migrate to a new platform or library but that I personally want that process to be entirely driven by a community of pragmatic individual choices about the real benefits and tradeoffs of new technologies over established ones rather than any sense of fear about the motivations or limitations or ambitions or caprice of any single company or the coupling of that company’s business interests in one space to another.

Using Silverlight again as an example, I am more than happy to adopt modern web-assembly based technology to provide rich desktop-like experiences on the web over Silverlight, in my own time and for my own reasons. I just don’t want Apple announcing that iPhone won’t support Flash and how that relates to Microsoft’s phone business (or any phone business) to be one of those reasons. (Shout out to OpenSilver for their modern, plugin-free, open source re-implementation of Silverlight!) I don’t want to go without a reasonable incremental update to the technology I’m using to not happen because a newer technology exists and “they” are pushing folks to use it instead so what I’m using today is frozen to provide some perverse incentive to migrate. I don’t want fear and frustration to be my forcing functions. I want an inversion of control.

Now, I’m not saying Microsoft or any other company should be forced to invest heavily in any particular technology indefinitely or even one more day than is in their business interest. What I don’t want is the outlook and lifecycle of, as much as practical, my tools to be dangerously and at times violently coupled to those interests. It’s just stress I don’t need for the next 30 years of my career. I want a setup where they don’t have to and the world can keep spinning productively.

So, with all that said, I believe that what the VB.NET community needs is an independent, community-owned (adopter-owned) non-profit organization unequivocally devoted to advancing the VB.NET experience and to growing and supporting the ecosystem of related tools and technologies to maximize community-value.

In this last year many VB enthusiasts have come to me privately and said, “if only we could pool our resources … all the developers and companies with important codebases in VB and fund more work on VB…”. Well, we can do exactly that, not unlike the Python community with their foundation, and the F# community, and the Haskell community, and the Rust community, and so many others. There are going to be tools and websites and samples and templates and extensions and packages and videos and more and ultimately, I would like the assets I build around ModVB or anyone else builds to further the VB.NET experience to be owned and maintained by such a VB.NET “foundation”. But that’s not an overnight process and I’m only very early in researching the practicalities of such an organization and how it would relate to Microsoft and the .NET Foundation and regardless building the membership required to fund VB.NET’s bright future will take considerable time. Which brings me to…

Short-Term Realities

Okay, so that’s the long term and the broad view for the community. How do I personally keep a roof over my head and food on my table while building up all these goodies for myself and fellow VB enthusiasts? Several potential approaches present themselves:

  • Get another part-time or full-time job, or recurring “gig”
  • Independent consulting/contracting
  • Support contracts
  • Crowdfunding

Until this summer I worked a full-time consulting job in Chicago and while lucrative it left virtually no time or energy (mental and otherwise) to pursue the various designs I had in mind for ModVB. In fact, having worked completely full-time for two straight months on the JSON literals and pattern matching features in Wave 1 of ModVB, I cannot imagine in hindsight what I was thinking before. The idea that I could put in that kind of effort on the side or on the weekends is laughable and to achieve just what I achieved in Wave 1 could easily have taken me a year putting in a few hours on Saturdays and that’s assuming my every consulting project was zero-stress, on time, on budget, just one project at a time, going smoothly every week with late nights or weekends. In my experience this just isn’t realistic.

As for part-time work… it’s a strange thing in our industry that you can make a very good living working 50+ hours a week but if you just want to work 20-25 hours it doesn’t just cut your earning potential in half. Time is the most valuable resource we have in life and it’s very difficult to negotiate for more of it while also not struggling and that’s been the challenge for me with part-time work. This paradox is exacerbated with the “gig economy”. I’ve tried to work Uber part-time to allow me the freedom to pursue my vision but the earnings compared to working in my field just aren’t there. Why stress out 30+ hours a week to barely make ends meet when I could stress out full-time and earn many multiples more.

So that’s the options that offer security. That leaves me with a blended strategy of the other three. Independent contracting gives me more flexibility on time insofar as I can decide after a project when to take on more work (if available). I’m currently looking at some VB freelancing opportunities and welcome any offers or connections from any of my readers or supporters for more.

Support contracts are the way I’ve heard of other freeware projects getting funded, like various Linux distributions. I make ModVB great and then companies that want to use ModVB can pay me a support contract to help them use it or prioritize their bugs or train them. While I’m committed to producing a quality product and fixing bugs regardless it’s certainly possible to prioritize some things to contract supporters. I don’t have much experience with this kind of dual-licensing strategy but I do believe you need a critical mass of functionality before you can offer support contracts and ModVB isn’t there yet. As the project matures this option will hopefully become more realistic.

Finally, I’m left with crowdfunding. Doing great work and hoping that the community of VB.NET enthusiasts and other interested parties will support me doing more of it. As scary as a leap of faith can be I feel this is the right time to take one. And so, today, I’m officially launching my very own Patreon. I don’t have much to offer by way of swag or private discord servers, but I am open to suggestions for more ways to connect with my supporters. I expect this will be a long journey. I’m not expecting everyone to dig deep in their wallets overnight but with each successive wave of features and tools I’m optimistic more and more of the community will come on board and lift me and the project. If you look at my page you’ll see I’m not trying to be greedy or make a fortune; it’s very pragmatically structured around my making ends meet to empower me to deliver the most value for the VB community. Every day I’m chasing alternate opportunities to earn money is a day I’m not spending advancing VB.NET to be all it can be, so, please check it out, support if you can, and share it with your colleagues and fellow community members. Thanks!

Next post

My next post will be an update on the state of Wave 2, which is currently targeted for one or more potentially incremental releases starting around the middle of this month (December). It should be fun times so look forward to it.

Regards,

-ADG

The Road Ahead / Where’s This All Going

Featured

Hey all,

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.

  1. 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.
  2. 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.
  3. 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.

JSON Literals & 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.

ASP.NET Core Web Programming with VB.NET Pattern-Based XML Literals
Client-Side VB.NET in Browser with VB.NET Pattern-Based XML Literals
Cross-Platform Mobile Development with VB.NET Pattern-Based XML Literals

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.
Extending VB.NET For Each loop with LINQ comprehension operators
  • 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.

Wrap up

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

TL;DR

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.

Regards,

-ADG

ModVB “Wave 1”—JSON Literals & Pattern Matching

Thanks everyone for your patience these past two months. I had to learn and do a lot to bring you this first release so I hope you find the wait was worth it. Today I’m launching an alpha of my mod, imaginatively titled “ModVB”. Installation instructions here for how you can safely install it to use JSON Literals and Pattern Matching right now! (Spoiler: You install a VSIX and reference a NuGet; that’s it)

This post is about the new features included in “Wave 1”. These are not prototypes like in my previous videos. Prototypes are quickly implemented to demonstrate the utility of one or few narrow scenarios taking whatever shortcuts possible to get to something that “works” (enough to solicit feedback) as quickly as possible. But the functionality in my mod is done “The Right Way”™ and should be extremely stable (crashes or freezes should be rare; please report immediately) and pretty close to what could be the final design. Read more about them below.

I’ve talked about JSON literals in previous posts, so I’ll start off with the newest feature on the block, pattern matching.

Pattern Matching

With respect to JSON, pattern matching is essentially the opposite of a JSON literal. Whereas a literal makes it easy to construct a JSON object in a way that preserves and reflects the structure of the JSON you’re trying to create, pattern matching allows you to deconstruct JSON in a way that likewise preserves and reflects the JSON’s structure.

Patterns

As of the time of this writing, here are the patterns that are supported by the Select Case ShapeOf syntax:

In all cases, null-ness may be “runtime extension defined” (see “Runtime Extensions & API Compatibility” below). This just means the compiler calls a helper method to determine whether something is true or not rather than purely CLR semantics. This is necessary because, for example, a JValue object is not null but represents the concept of null in the JSON space. Likewise, a JsonElement structure isn’t nullable but may still represent a null value.

The JSON Object Pattern

{
  "<name 1>": <pattern>,
  "<name 2>": <pattern>,
  ...
}

Matches a value if it: is not null, represents a JSON object (as defined by runtime extension), has the non-optional members named, and each member found matches its corresponding pattern, recursively.

This is evaluated top to bottom (depth first) so the entire first member and its pattern are evaluated before the second member is searched for.

This is not exhaustive; the JSON object may include more members than the ones listed and still match.

May be marked optional by placing a question mark ? after the closing brace. In which case, the pattern will also match a null value, i.e. the value is null OR matches the above criteria.

An individual name-value sub-pattern can also be marked optional:

Case {
  "firstName": required,
  "middleName"?: optional
}

In this example pattern requires that a firstName be included in the JSON payload but the middleName may not be present at all. This is subtly distinct from being present but null. Some JSON producers may not include null values by default. This syntax provides an easy way of consuming JSON from these producers in a way that treats an omitted value the same as one that is explicitly null.

The Empty JSON Object Pattern

{}

Matches a value if it: is not null, represents a JSON object, and that object has no members.

Unlike the non-empty JSON Object Pattern, this pattern is exhaustive.

May be marked optional by placing a question mark ? after the closing brace. In which case, the pattern will match a value that is null or is an empty JSON object.

The JSON Array Pattern

[
  <pattern>,
  <pattern>,
  ...  
]

Matches a value if it: is not null, represents a JSON array (as defined by runtime extension), that array has at least as many elements as listed, and each of the first n elements matches its corresponding pattern, recursively.

This is evaluated top to bottom (depth first) so the entire first element and its pattern are evaluated before the second element is searched for.

This is not exhaustive; the JSON array may include more elements than the ones listed and still match.

May be marked optional by placing a question mark ? after the closing bracket. In which case, the pattern will also match a null value, i.e. the value is null OR matches the above criteria.

The Empty JSON Array Pattern

[]

Matches a value if it: is not null, represents a JSON array, and that array has no elements.

Unlike the non-empty JSON Array Pattern, this pattern is exhaustive.

May be marked optional by placing a question mark ? after the closing bracket. In which case, the pattern will match a value that is null or is an empty JSON array.

The Constant Value Pattern

<constant literal>

This can be any constant literal in VB (including Date and Decimal values and Nothing) or the JSON constants true, false, or null. These JSON constants behave exactly as VB True, False, and Nothing respectively.

Matches a value if it (for constants other than Nothing or null): is not null, is convertible to the type of the constant, and after conversion has a value equal to that of the constant.

If constant is the literal Nothing or null, will match if the value is null.

May be marked optional by placing a question mark ? after the literal. In which case, the pattern will match a value that is null or equal to the constant.

The Variable Declaration Pattern

<identifier> As <Type>

Captures a value in a variable. The As <Type> clause may be omitted.

Matches a value if it: is not null and is convertible to the specified type. If the type is omitted the pattern will match any non-null value and the type of the variable is inferred from the type of the value.

Convertibility considers reference conversions and intrinsic language conversions as well as runtime extension defined conversions. In the absence of one of these a conversion may also be attempted if the value represents a String and the specified type defines a TryParse method or the specified type is an Enum type, in which case the pattern will succeed if a call to TryParse succeeds.

May be marked optional by placing a question mark ? after the type. If the type is omitted, the question mark ? may be placed after the identifier. In either case the pattern will match all values null or otherwise.

A note on optional patterns

When a JSON object pattern, one of its name-value subpatterns, or a JSON array pattern is marked optional, any variable declaration patterns within are necessarily nullable; if the parent pattern matches a null value these variables will also be initialized to null.

More to come

More patterns will be added later, as well as an expression version of the ShapeOf operator.

Runtime Extensions & API Compatibility

Both pattern matching and JSON literals are pattern-based, in the same way as LINQ and the For Each loop; they aren’t tied to any particular library or set of types. Instead, the implementations of these features look for helper types in a special Extensions namespace, decorated with the correct attributes, and having methods with certain names and shapes. The indirectness of that sentence reflects the levels of indirection built into the compiler to achieve this flexibility. You don’t need to worry about any of that other than that you should reference particular NuGet packages from the ModVB NuGet feed when you want to use these features with the corresponding APIs.

If you want to use JSON literals and/or pattern matching with:

  • Newtonsoft.Json.Linq types (JObject/JArray/JContainer/JValue/JToken/JProperty)

Reference package: ModVB.Runtime.Extensions.NewtonsoftJson

  • System.Text.Json types (JsonElement/JsonProperty) or System.Text.Json.Nodes types (JsonObject/JsonArray/JsonValue/JsonNode)

Reference package: ModVB.Runtime.Extensions.SystemTextJson

More such libraries will be released for other JSON libraries in the coming weeks.

It’s worth noting that these are not mutually exclusive. You can reference as many extensions as are applicable to your project without conflict. Pattern matching only pays attention to the extensions required for the type being matched against and JSON literals are target-typed (more on that below).

JSON Literals

I talked about JSON literals in this blog post and this blog post. Please check them out. The scenarios still apply, and the behavior is still the same except the JSON literals in this mod are far beyond prototype quality. There are two new behaviors as well: flattening and target typing.

Flattening

The properties of objA are “flattened” into objB (objA isn’t changed, of course). If instead of adding another object directly you add e.g. an IEnumerable(Of JObject), each JObject is flattened into the result in sequence:

The query yields a bunch of objects, but those objects are all flattened into the one outer object. This is a convenience feature particularly in LINQ as it allows you to yield a list of objects as a collection of properties, without requiring either an explicit syntax for a name-value pair or instantiating JProperty explicitly.

Target-typing

JSON Object expressions and JSON Array expressions are target-typed. Meaning, if you for example, assign a JSON literal expression to a variable or pass one as an argument to a parameter of type JObject/JArray (or one of their base types), the expression will construct that type. You can also use an explicit cast to determine the type of the resultant object.

Default JSON Object and Array types

In contexts where no target-type is available such as when using local or method type inference, or contests where the expression is being converted to Object, the expression will be evaluated as if it has the default JSON Object or Array type.

This lets you have a project that references multiple JSON APIs but doesn’t require explicit casts everywhere if one API is preferred. So, if for example, you have a project that predominantly uses the Newtonsoft JSON.NET types but you need to interoperate with APIs that work with the new System.Text.Json.Nodes types you would probably set your default object and array types to JObject and JArray and use target-typing in those specific times when you need to construct a JsonObject or JsonArray.

The default JSON Object type can be configured by setting the DEFAULT_JSON_OBJECT_TYPE preprocessor constant in your project settings to the fully qualified name of the type you wish to use. Likewise to set the default JSON Array type set the DEFAULT_JSON_ARRAY_TYPE constant.

If you didn’t know that VB pre-processing constants can have actual values—they can. A fact that I’m going to exploit heavily in future releases to avoid more cumbersome changes to MSBuild or the project system. Besides, after decades of being in the language, it’s time that capability start pulling its weight!

A few more notes: If this setting isn’t in your project settings the compiler defaults to the JSON.NET types because 2.17B downloads can’t be wrong and System.Text.Json.Nodes only exists in .NET 6 and later. I am thinking about making this default change based on whether you’re targeting .NET 6 and up or .NET Framework though.

The default JSON Object and Array types do not impact pattern matching except when trying to use an JSON object or array pattern against a value of certain types like Object or interfaces. In that situation you’re assumed to be testing the reference against the default object or array type and so the pattern will fail if the value is an object-typed reference to a different JSON library’s object or array type. To solve this you have to cast the value to at least the root of the correct type hierarchy (e.g. JToken/JsonNode) to let the compiler pick up the correct extensions.

Why Not Just Use Serialization?

On a previous post one or more commenters asked (paraphrased), “Why bother with this when everybody uses serialization?”

Well, for starters everyone isn’t using serialization. Only people who are using serialization NOW are using serialization. There are developers who aren’t exploring the power of the cloud or NoSQL database techniques at all and maybe this way of doing things makes it more appealing or more productive for them to do so, myself included.

I love types, I do. But honestly I’m a little fatigued on superfluous data transfer types that only exist to be serialized/deserialized. I had a project recently that was inundated with these anemic domain “models” for the sake of “doing it right” even in situations where no class was really needed.

For example, we had this dashboard API, part of which returned data to be rendered in the browser by a client-side JavaScript charting library in a SPA. There was absolutely NO value in trying to recreate the API of the JavaScript library. Ultimately, to the chagrin of my peers, I just constructed a returned a bunch of JObjects and JArrays matching what the charting library expected rather that “pretending” to build some rich type safe object model that was just going to get stringified immediately.

I worked on the Roslyn APIs for over half a decade; I believe in the benefits of types. But I also spent a good chunk of my career chasing after the ideal of “persistence ignorance”. The idea that domain objects are pure and free floating abstractions that are the true model of all software and the fact that objects happen to get saved to databases, or happen to get saved to the file system, or happen to get sent back and forth over the network via services is just an implementation detail. And in plenty of cases that’s absolutely true.

But there are also cases where the goal is to talk to a REST service you don’t own, or to manipulate some JSON in a database. If the currency of truth in an operation is JSON, it’s not the implementation detail, your POCOs are. The JSON is the whole point. Serialization classes are just something I would have done to make the SPA’s JavaScript charting library fit into a .NET world; I didn’t own that model.

And besides, if it’s true that serialization is the be all and end all of dealing with JSON no one would make types like those in the System.Text.Json.Nodes or Newtonsoft.Json.Linq namespaces. They exist both for convenience and because sometimes you’re working with highly heterogenous, schema-less data where the impedience mismatch between your data and the OOP world imposes a cost you deem not worth paying.

Another example that comes to mind is DataTables.

Wait, hear me out!

We’ve had typed DataSets in .NET for almost 2 decades now. Strongly typed. IntelliSense. All that. We’ve also had popular ORMs on .NET for almost as long. Yet often when I look on Facebook or a forum, there I see people using untyped datasets. Why?

My hypothesis is that when thinking about databases DataSets and DataTables are this remarkably minimal abstraction over the natural domain of a relational result set/table/row/column. They are to databases what HTML and CSS are to Web UI (as contrasted with the abstractions of Web Forms). Some people just like that thin abstraction, or need it, or benefit from it. My hypothesis is that untyped JSON objects are the analogous abstraction for the Cloud and NoSQL and that providing them will bring more developers to modern paradigms beyond the ones who are doing it now.

And then there are interactive and exploratory scenarios… if I’m in an interactive or exploratory context (and as part of this modding endeavor I plan to pursue more interactive and scripting contexts for VB.NET) I don’t want to jump through all the hoops of serialization to explore an API or a database. This convenience empowers me at different phases of my project or different activities on a project where speed and ease (for me) are paramount.

Sometimes when I’m mocking out a UI I don’t make any classes, I just whip out some XML literals and mock up an entire data model to bind to in XAML because that’s the fastest way to get a prototype going. And don’t even get me started on all of these reporting-only small classes that only exist for one UI or another, no domain purpose: OrderSlim, OrderSearchResult, OrderSummary, OrderInfo, OrderViewOnPage4. I’m very interested in exploring CQRS and I think raw JSON is a perfect fit for a lot of the Query responsibilities instead of all those fake domain objects.

In short, after all that rambling, there are tradeoffs and these features exist on a spectrum, and I’m making them to give the language more versatility and appeal to a broader set of users and scenarios. Serialization still cool.

What’s Next?

Why, “Wave 2” of course! It won’t be a big secret like “Wave 1”, I’m going to be upfront with what’s going to be in it but I need a little recovery time before getting started on that and to tend to other matters in my life which have gone neglected these last two months. I also plan to blog a little more about the contents of “Wave 1” and release a couple more NuGet packages with JSON literal and pattern matching support for a few more JSON APIs such as MongoDB and Oracle NoSQL.

  • Read this post for instructions on how to install ModVB for yourself
  • Try out the mod—do anything you’re interested in doing with the new features
  • File bugs at https://github.com/modvb/backlog/issues
  • Feedback and discussion on my blog, your blog, Twitter, YouTube, or wherever you hang out with other VB.NET enthusiasts!
  • Don’t forget to SHARE!

Introducing ModVB—A free, independently-created “mod” for VB.NET that gives you new features just by installing a VSIX…

Featured

…and referencing a NuGet package. That’s it. That’s the whole thing.

As mentioned in my previous post, I think modding represents one path forward for my favorite programming language, VB.NET. So, I’ve created my own mod to help me explore the years of ideas I’ve had for VB and to share them with others!

ModVB

ModVB is more than just an unimaginative name. Yes, it means “modified”. But it also means modern. And modulo (with respect to).

And the mathematically inclined will note that: (VB + ModVB) Mod VB = ModVB

(Assuming ModVB is less than 2x VB, which it is). You see, I really did put a lot of thought into this!

The first wave of new functionality is introduced in the very next post on this blog: ModVB “Wave 1”—JSON Literals & Pattern Matching. Please check out the post and the accompanying video for more details on what you can do with this first pre-release version. I’ve labeled it an alpha because it’s very early in the development of the mod and semantics will likely change. That said, I’ve built it for stability so crashes or hangs should be very few (and please report them if you find them so I can fix them ASAP).

Look forward to future posts from me about how you can make and distribute mods of your own!

About the Developer (Me)

A man in a suit (auto-generated)

My name is Anthony D. Green (he/his/him). I’m a 37-year-old VB developer from Chicago, IL, USA. I previously worked at Microsoft for 8 years on the Managed Languages team. For most of that time I was the program manager for the Roslyn compilers; communicating with customers and working with Microsoft architects, developers, and testers on designing and implementing the VB.NET and C# compilers in VB and C# respectively as well as a large part of the Roslyn APIs that power the VB and C# IDE experience inside Visual Studio.

For my entire Microsoft career, I served as a language designer on the VB language design team, which I led for 2 years, during which I also served ex officio on the C# language design team. Both before and after my time at Microsoft I’ve worked as a software architect consultant in Chicago for a total of 5 years, mostly working with .NET and other Microsoft technologies.

VB.NET is my passion and I’ve enjoyed working with it both as my profession and as a hobby, starting with VB4 when I was just 13-years-old. I’m building this mod mainly for myself because I want to see the language and experience evolve to their limits but I hope others will get benefit from it as well because I really want to see the VB.NET community grow and flourish. To everyone who chooses to join me on this journey, thank you for trying my mod!

Installation Instructions

This process is easy solely thanks to the heroic efforts of the Roslyn infrastructure teams throughout the years. I just implement the features; they made it possible for me to share them with you.

Prerequisites

  • Visual Studio 2022 (any edition, including Community) and VS2022 Update 17.3.1

Steps

  1. Launch Visual Studio 2022 in a new hive

This creates an isolated configuration of Visual Studio 2022 that you can install the mod into. ModVB is currently in pre-release and installing into a separate hive means you can always launch Visual Studio 2022 normally if you encounter bugs or blocking issues or simply want to return to the behavior of “Vanilla” VB.NET. Even when the mod eventually releases you may wish to use separate hives to maintain this flexibility.

  • Open the Visual Studio 2022 Developer Command prompt (Start > “Dev…”)
    • Enter the command `devenv /rootSuffix ModVB`
  • Click “Continue without code” (bottom right)

You can always confirm when you’re using the ModVB hive because “MODVB” will appear in the upper right corner of Visual Studio 2022 when you’re using that hive.

  1. Add the ModVB MyGet VSIX feed to Visual Studio as an additional VSIX gallery
    • On the menu, open “Extensions > Manage Extensions”
    • Click “Change your settings for Extensions” (bottom left)
  • Click “Apply” and then “OK”
  1. Download and install the ModVB Language Services extension
    • On the menu, open “Extensions > Manage Extensions”
    • On the left, select Online > ModVB
    • Download the “ModVB Language Services (Built with Roslyn)” extension
  • Close Visual Studio 2022
    • The VSIX Installer will open. Follow the instructions in the installer to complete the installation
    • Re-launch the Visual Studio 2022 ModVB hive by entering `devenv /rootSuffix ModVB` at the Developer Command Prompt. You may wish to create a separate Windows shortcut with this option for convenience.

Installing the language services VSIX enables any new or modded IDE experiences inside of Visual Studio 2022, including the IDE experiences for new language features such as IntelliSense, syntax highlighting, and code actions. However, for building projects using new or modded language features and semantics you’ll need to reference the ModVB compiler from those projects. This also enables those projects to build as part of your CI/CD process on build servers which won’t have Visual Studio 2022 or the ModVB Language Services VSIX installed.

  1. Add the ModVB MyGet NuGet feed to Visual Studio as an additional NuGet package source
    • On the menu, open “Tools > NuGet Package Manager > Package Manager Settings”
    • On the left, select “NuGet Package Manager > Package Sources”
  • Click “Update” and then “OK”
  1. Install the ModVB.Compilers.Toolset package to any projects you want to compile using new language features
    • On the menu, open “Project > Manage NuGet Packages…”
    • At the top, select Browse
    • Select the ModVB package source in the drop down at the top right
      • Make sure “Include prerelease” is checked (next to search box)
    • Select “ModVB.Compilers.Toolset” on the left
  • Click “Install” on the right

Congrats! Your project will now build with the ModVB compiler and have access to new features for VB.NET. Of course, if you’re not using these features the behavior of building will be exactly the same as before. Remember to add this package to any additional projects where you wish to use new functionality. Happy coding!

Next steps

  • Read this post detailing the new features in “Wave 1” of the ModVB alpha
  • Try out the mod—do anything you’re interested in doing with the new features
  • File bugs at https://github.com/modvb/backlog/issues
  • Feedback and discussion on my blog, your blog, Twitter, YouTube, or wherever you hang out with other VB.NET enthusiasts!
  • Don’t forget to SHARE!

Checking in (Wave 1) Update 2 SP4 R3

This is waaaay overdue, I know. So here’s what happened. That little bit of scope creep I decided to take basically reset the whole sprint. I didn’t have to throw away any of the code but it did expose every assumption that was in code and multiplied my testing matrix by like 4-5x because I’m supporting many more use cases than before. I’d say the effort has been 40% new code, 60% testing.

Also I took a week off due to prior commitments away from my keyboard with friends and family.

So why did I decide to increase scope so late? Precisely because of how disruptive this change has been. If I didn’t do it now I’d be compelled to do it immediately after Wave 1 and it would interfere with waves 2-3 which are entirely different feature areas. All of the assumptions would be more entrenched and there was a good risk of shipping things that were wrong in subtle little ways–I definitely had to withdraw certain functionality that was overly specific. And aside from the “happy path” experience which was originally designed, I had to design and test a whole “graceful failure” path. This is essential work for tooling anyone else is going to use. Nothing has been wasted in this effort.

So where are we at? I’m writing more tests. I admit I’m not nearly as fast a tester as I am a dev and switching hats makes me miss the days of having dedicated QA. I’m fixing minor bugs. Don’t have an exact release date but “soon” ™.

Regards,

-ADG

P.S. I’m going to publish what’s in Wave 2 BEFORE it starts. I appreciate that the suspense is problematic.

Checking in (Wave 1) UPDATE

After due consideration I’ve decided to delay today’s release to next week. I’m concerned that rushing testing/stabilization will only hurt … everybody so I’m giving it more “bake time”. Additionally, I’ve relented on some critical (minor) scope creep in the same areas being tested/stabilized now; it’s beneficial for a lot of reasons to do it now instead of as part of Wave 2. This new work is thematically consistent with what I had planned to release today, very important to the broad utility of that feature set, was half-implemented already–it was designed for from the beginning, and I’m kind of excited by it in an ice cream on top of pie kind of way.

Regrets,

-ADG

Checking in (Wave 1)

Just leaving a quick note for readers curious about my progress. In my last post I said I was working on an initial preview release of my mod with some new features. I’ve basically been heads down coding since I wrote that post and I finally punched through and end-to-end spike of an initial set of use cases.

I pull up a video of this scene literally any time I get any non-trivial amount of code to run as expected.

Now comes the fun part, rigorous automated testing of 100+ test cases and more bug fixing. Making sure that not only do things work the way I expect where I expect but that they don’t work in other ways where I don’t expect and that everything that does work does so for the right reason(s) and that nothing crashes. The bar is far higher for even a preview of a mod than for my past prototypes so I have to really go at things with hard pipe-hitting, blowtorch- and pliers-wielding permutations now.

This bug bashing is what I’m up to for the next 48-hours then on Friday (just in time for the weekend) I plan to publish some bits to play with. I also have to script and record a brief video explaining what to actually play with.

Fingers crossed! We’ve got a long road ahead of us and this first step is tremendously important. See you soon!

-ADG

An Alternate Path

Featured

It’s funny how a tiny bit of feedback can change the nature of a post. I had originally planned to write about modding in the gaming community and the impressive accomplishments independent developers and enthusiasts have had in expanding and extending the experience of games, sometimes vastly, beyond the intent of the original creators (e.g. Breath of the Wild: Second Wind). In some cases, games have come to be defined by their modding culture (e.g. Skyrim) and in others mods have taken on a life of their own to become products that arguably overshadow their base games (e.g. Counter-Strike) or even spawn new genres (e.g. Dota). I had some anecdotes about the first software I ever “modded” (Mavis Beacon Teaches Typing) or twiddling with QBasic games’ source code as a young teen.

That said, I got a bit of feedback after my last post that something maybe a little broader (yet also more direct and specific) would probably be better received so I’m going to try to fumble through distilling at least some of two years of thought and research and—yes, planning—into an elevator pitch. Well, maybe not that short, but still a challenge of brevity.

For starters, let me set a few expectations. Firstly, what I’m proposing is without a doubt going to be a pain in the ass, at first at least. It’s a lot of work. When I say a community-driven­­ path forward, I don’t mean a community-accentuated path forward. I don’t mean community-supplemented or community-enhanced. We need to shift our entire paradigm from being a Microsoft-centric developer experience to one where almost (*) everything we enjoy comes from us. That means features, tools, designers, docs, samples, templates, and even the respect that I mentioned in my last post. These are all things we’re used to getting from Microsoft and lamenting when we don’t get them from Microsoft and complaining to Microsoft about it. That entire inclination has to die and we have to rebuild a community that holds itself primarily accountable for its own capabilities.

This is not going to happen overnight and it’s not going to start just because I say “go”. I’ve seriously thought through the process, and I can’t see it taking less than a year or two to build out an experience with the kind of polish that can sustainably grow our community. But virtually all the technical pieces we need to build… well, anything, are available somewhere. The extensibility points are there; we just have to do the work both functionally (in code) and culturally (in ourselves). If you were looking for “ThatVBGuy” to post on his blog with some tablets in hand explaining how with a few reg key fixes I can make this all go away, sorry, this ain’t that post. We’re talking 3 steps back, 5 steps forward.

Though technically we’re not sliding backward, we’re just not moving forward right now, so I guess it’s just 5 steps forward while the world is moving forward like 2-3 steps maybe but we’re going to accelerate so that by the end of it we’re far ahead of where we are and even ahead of where we would have been if we just floated along with the current. Yes, we’re in a boat now even though when I started this parenthetical I was thinking about a land-vehicle like a car or a train.

I also want to be clear that not everybody is going to make it to the other side (we’re back on land now, the metaphor is some kind of chasm, I think). It’s completely foreseeable that a lot of us are going to take a faster, easier path and move to a developer experience that’s already propped up elsewhere. There are always going to be those who need a Microsoft-sanctioned/supported solution and either can’t or won’t give up the Microsoft-centric mindset. And that’s okay! I just can’t be one of those people and I’ll explain more about my personal investment in this (other than quitting my job to focus on kickstarting this effort for the next few months) in my next post.

Now, I know I’m not the first to say this is what needs to happen. Everything I’ve said so far will need to be said again, and expanded upon, and most importantly discussed and debated amongst ourselves—we few. So I have to imagine when people say, “Well, what’s the alternate community-driven path?” they already get that the path is to be community-driven. What they really are asking is “How?”, or “Where do we start?”, or “What can I do?”. Maybe they want a roadmap to give them assurances or confidence that this can really be done or how likely it is to be done in a way and timeframe that is applicable to their projects and needs.

For starters, what can you do as a VB.NET developer who wants to help?

Get comfortable with discomfort. We can build some great experiences but first we’re going to build some pretty raw ones. If the minority of the larger VB community that cares to push it forward can’t suspend our discomfort with doing things in a way that may seem initially hacky, we’re not going to get to the place where the majority can follow. Remember that most other languages outside the Microsoft ecosystem are built up like this. VB has enjoyed a long period of being the exception. Now we must rise to meet the rule.

Understand the systems that exist today. You’ve used Visual Studio and .NET but do you understand the extensibility points? Have you ever built a VS editor extension? How well do you understand the dotnet command driver? How’s your NuGet package authoring skill? Do you truly understand how new UI platforms work under the hood? Have you ever written a .NET Analyzer? A source generator? This is the time to pick an area of interest and study up. We’re all going to have our areas of strength and no one person can know or do it all.

Be ready to engage. It’s easy to be attracted to the allure of being the one who comes up with or builds exciting stuff. But what gets projects done and done right is feedback. I’m going to post a lot on my blog as things progress. Be ready to share your opinions and discuss with others. Be ready to test things that are built by others. Roslyn is arguably the largest VB project ever built and it crossed the finish line not just because of smart devs churning through features but equally smart testers constantly testing the bits. Giving feedback on the design. Filing bugs. Fixing bugs. Building projects with what was ready. I hesitate to quantify it but an amazing tester filing bugs is worth maybe 5+ good devs checking in features.

What’s Anthony doing?

First up, I’m building a mod as a proof of concept. This is a different animal than the prototypes and stuff I’ve built so far (think more Resharper than io.js). I’m targeting this month (June) so I plan to have something more concrete to talk about in the next two weeks. Aside from the at-times agonizing process of authoring these posts, this is now my full-time (unpaid) job. And as I learn more, I hope to educate others about how to do the same and begin to coalesce our identity and efforts into everything I can see in my mind’s eye that the VB experience is capable of being.

Need more info?

Sound off in the comments below!

-ADG

Two Anxieties and One Unarticulated Need

Why doing nothing is sometimes the right thing to do

In several of my recent conversations with folks in and out of the community, I’ve shared some things that they found—and a lot of my readers will probably also find—surprising.

A few years back I penned (as I do) a voluminous response, regarding VB, culminating in an open letter. What may surprise you is that after writing it I really didn’t attempt to socialize it much. I shared it on Twitter but in my experience that’s not actually a VB community hotspot at all. I had initially planned to make a bigger fuss but as I considered next steps and took counsel with those I trust I came to realize that the cycle of inaction-fire-response was just as likely to produce a terrible outcome as a good one (if not more so). Also, I was sleeping a little easier.

You see, in my first 2 years post Microsoft I wrestled with (among other things) two different anxieties regarding VB. I feared that:

1. The C#/.NET org wouldn’t do anything.
2. They would do something and it would be horribly wrong.

And every few months I’d peek in on vblang and find neither an announcement that they weren’t doing anything nor any announcements that they were doing anything in particular. And strangely I’d feel relief for both.

As a side note: if either had happened in 2018 or 2019 I genuinely wouldn’t have been mentally healthy enough to handle it so “do nothing, say nothing” in this case worked out well for me at least.

The Anxieties

In my 8 years at Microsoft attending VB language design meetings and product planning meetings I was constantly pushing back against the idea that the ideal for VB.NET was to “just do what C# does”. “That’s what the customers said they want! They’ll yell at us if we don’t!” Countless discussions that “co-evolution” never meant copying. It was exhausting but a fight worth fighting and after several years eventually I’d built the credibility to really shake that idea out of the heads of those within my sphere of influence.

That idea is wrapped in arrogance and bias and short-sightedness and genuine ignorance and intellectual laziness and yes, good intentions. But good intentions don’t always yield good results.

I’ll restate this plainly because people don’t seem to believe this about me (and I say this with no malice or insult intended): I experience no jealousy toward anything C# has. C# is a phenomenal language with great tooling, but C# has never produced an end-to-end experience in language or tooling that I have wanted to make my permanent home. The “spirit of the language” is different than mine and it can’t be gently nudged into being a great or even begrudging substitute. C# can add functional features, I don’t think the F# community will ever be like, “Yeah, good enough! I’ll switch” and I don’t think adding more imperative/mutable features to F# would allow one to wholesale lift-and-shift the C# community over to F#.

That’s not to say that I dislike capabilities that come to C#. There are many things I’ve wanted before C# even thought of them, and things they’ve gotten that I’ve only been grateful to have missed, and other things I’ve wanted in a very different way than they’ve appeared in C#. But there is nothing that I want because it’s in C#. But the problem is that “everybody” thinks that’s what I would or should want and frame decisions in that way.

Examples time!

So in 2015 we were working on the first release of VB powered by Roslyn. At one point in the cycle we’re prioritizing our backlog for the compilers/languages and I note that we’re doing question-dot (?.) aka “null-conditional member access” next. My dev lead had somewhat recently (re)joined the team and hadn’t been exposed to my philosophy over the years.

He nods his head agreeingly and says, “…Right! Because of co-evolution”.

Me: “No.

Not because of co-evolution.

Because in a private discussion thread with VB MVPs they expressed to us emphatically that `?.` was a top value-add for them. It has nothing to do with C#. The fact that C# also decided to do it is purely coincidental but has absolutely zero bearing on the fact that VB is doing it. We were always going to do it and if C# decided not to do it tomorrow we’d still be doing it“.

Interestingly, there was a heated internal debate on the question-dot (?.) operator while designing it. I can’t recall if this ever went public but the team was split on whether it should be left-associative or right-associative. That is to say whether a?.b.c should mean the same thing as (a?.b).c (left) or a?(.b.c) (right). The former is more compositionally pure and that was the argument that initially led the C# LDM to push forward with left-associativity. But there’s a pitfall there because if a is null, .c will throw an exception. Instead, in order to avoid the exception you’re forced to type a?.b?.c, which is what led the VB LDM to immediately push for right-associativity. Ultimately C# swung around to the right way but it was only after escalating the debate to an executive override. I honestly didn’t expect it and was fully prepared to die on the hill that VB go its own way here despite how “easy” and “comfortable” and “safe” it is to “just do what C# does”. Fortunately that fight never came but I still maintain that it was a fight worth fighting and that it could have very easily gone the other way.

Again you might be surprised to learn that I spent half my time on that release and the one following it convincing folks that we didn’t need to do features in VB. Specifically, that we didn’t need to deprioritize capabilities that would be genuine value-adds to the VB community and the VB experience for the sake of implementing or even pursuing the many ideas that were coming out of the C# design process. The vast majority of those ideas never even made it into C# because of various problems but the impact on the VB side was that they took time and oxygen away from features and approaches that would have benefited VB greatly. But C# was considering them so we had to spend cycles deliberating how they might work in VB.

When we first reached language completeness on the Roslyn compilers and were officially ready to implement new features rather than just attaining feature parity with the native compilers written in C++, I recall a moment when my dev lead (a different one) came to me inquiring about the necessity of the VB LDM: “Maybe we’re at a place where we ought to just ya know, let the C# LDM handle it?”. You see, he truly read both the need of the VB community (and the meaning of the co-evolution strategy) to be that the C# LDM would just do its thing and then skin those features into VB. I explained that this was not the case, but it takes a lot of time and credibility (which fortunately I had) to correct that misunderstanding one person at a time across a giant organization and then across an entire community. I see now that my inability to scale myself was one of my many failings.

The last interaction that comes to mind was from a high level director within developer tools. You see, we had this private mailing list where all of our VB MVPs and trusted influencers could talk shop and give feedback to the team. And anytime anything was amiss anywhere in the .NET ecosystem with regard to VB that list would flame up with someone dramatically proclaiming that this tool or that template was the last straw and that all hope was lost unless nascent technology Y got 500 samples immediately (care to guess how many of those tools, templates, or technologies are now “dead” btw?). Anyway, I sent out a reply asking for patience and calm, as I often did (another failure of mine) and this director privately replied that it was a good response but that he didn’t really see a way out of it as the only way the VB community could ever be happy was if we did everything for VB that we did for C# (in the same way and) at the same time. I absolutely do not believe that could make the VB community happy. I don’t believe doing that ever could have made us happy.

That mindset is like a virus running rampant through both the halls of Microsoft and the broader .NET community and for 10 years of my life I was steeped in anxiety about it all the time. More at some times than others and especially for the first two years where I wasn’t there to fight against it. And then one day “The .NET Team” announced that they had no plans to “evolve” the language further and that anxiety quickly went away. No more fear that some unconcerned and maybe well-intentioned person’s “whoopsie!” mistake would permanently mar the language with an inconsistency or some other mistake. No more fear that the loudest voices in the VB community which really do (for lack of leadership or imagination) yell as often as not for complete replication of C# in almost all respects would find purchase amongst some newer and unwary members of the team and we’d finally get that Semicolon keyword.

And my other anxiety, that nothing would happen. Well, that happened, so there was nothing to fear there anymore either. And in the first few months following the announcement while certainly anxious about COVID-19; racism, police violence, and civil unrest; murder hornets, and economic collapse, for the first time in a very long time VB was something I wasn’t anxious about.

The Need

In the past when Microsoft CEO Satya Nadella has spoken of using empathy to meet the unarticulated needs of users he’s reiterated that this isn’t the same as going off and doing exactly what the most and loudest users tell you; that’s why it’s (often) unarticulated. I haven’t found an exact quote but the closest was here where he says, “It’s not about going where people tell you to, but how you get there before there is conventional wisdom”.

So, if “feature parity” with C# is the red herring—the articulated want that doesn’t actually meet the need—then what is the thing that VB users need. What is all the clamoring and complaining and commenting and protesting really about (beyond the obvious cases of being technically blocked in some task)? The answer is surprisingly human:

Respect

The VB audience articulates a lot but behind it all is a very human and professional need to feel respected. Everything else is just a means to that end. Respect from their peers in other language communities. Respect from Microsoft for their decades long business relationship. Respect for their code, and their projects, their knowledge, and skills.

I have a t-shirt (that I never wear) that was given to me one year at MVP Summit that reads “VB.NET IsNot VB6”. What that shirt really says is “Respect me (unlike you treat people who use VB6)”. Every time any VB.NET developer has uttered a phrase distancing themselves from VB6 or VB6-isms it’s because they perceive that doing so gets them more respect. In the mid 2000s, when I was getting into .NET, I did the same thing. “Oh no, you don’t understand, it’s not like VB6 anymore—it’s okay, you can respect me now—I use inheritance!”. I’ve never worn that shirt, that I can recall, and have no plans to because I no longer believe that it’s okay to disrespect someone else as a means to building up your own cachet. But for many VB.NET developers this is still an instinctive and desperate move to scratch up what they really want: respect.

And co-evolution. When a VB.NET developer said “We have the co-evolution promise now” it wasn’t because they were getting the features they actually needed, or wanted, or used. It was a defense from a disrespectful industry. The oft-misapplied idea of co-evolution was a shield that said “You have no concrete examples to disrespect me because I will have the same things as something you do respect”. But make no mistake, copying C# doesn’t create respect. It just deflects superficial disrespect. If you have two children, is it respecting one to treat them exactly like the other always? “I took your sibling to baseball games so I always took you to baseball games ergo I respect you; I bought them blue shoes so I bought you blue shoes—ergo I respect you both equally”.

I recall once 5+ years ago we put out a preview of some potential new features in VB. One of which was the ability to perform a Select Case on the type of a value. Someone wrote in through the “Contact Us” form on the VB team blog and said (paraphrased) “I’m very worried about the direction of VB.NET. I see that you’re thinking of adding this Select Case on type feature but object-orient developers should use polymorphism and method overriding to get different behaviors based on the type of an object and I’m afraid this feature teaches bad habits and is dumbing down the language”. I can’t remember if I replied or what I said but I do recall asking Mads to chime in for some reason and he politely explained that while polymorphism was certainly one way to approach such problems, in functional programming languages it’s very common to use constructs like a type case or pattern matching to do the same things and that we were looking at expanding the languages with other constructs and techniques popularized in functional programming, etc. I’ll never forget the complete 180 in the customer’s response (paraphrased) “Oh! Functional programming! I’ve heard of that! Sounds neat!”. You see, once he understood that the feature was coming from a position of respect for his intelligence and not a crutch, he was completely open to it. Tying it to modern programming techniques like functional programming rather than pre-OOP procedural habits lent legitimacy and respectability to the feature and him and his code in using it by extension.

I can’t tell you how many times someone in the VB.NET community has come to me and said they read that Microsoft was going to evolve VB in a way that was true to the spirit of the language and that this meant “dumbing it down” and that we needed to change to present it as raising the bar of entry or removing the training wheels or some other condescending metaphor. This defensiveness is about respect. Co-evolution was about respect. The distancing from VB6 is about respect and the envy of C# is about respect but none of these things actually meets the need of respect. It’s an unmet and unarticulated need that can’t be solved easily or quickly or superficially.

This isn’t a need that can be met by everyone just “resolving” that they “respect” VB.NET developers. But it can be met, I believe. It’s going to take a lot of work and as much or more of it is cultural (about the community) as it is functional (about features and support). So, you see, I didn’t make as big of a fuss as I thought I would because the last thing we needed then and now is for “The .NET Team” to be startled by some fire drill or protest into doing “whatever” puts out the fire most quickly. Any little addition or change from “The .NET Team” no matter how innocuous or well-intended is as likely to cause as much harm as good to the VB experience unless rooted in the deepest reverence for what VB has already and is, has been, and still can be. I don’t think this is a change that can come from Microsoft and that it’s best that we, the community, take the lead for now. i.e. it’s for the best that outsiders sit on their hands for a bit longer. In my next post I’ll begin to talk about an alternate (and exciting) community-driven path forward that I see. Stay tuned.

Regards,

-ADG