Type inference is great! You get the clean productivity of a dynamic programming language with the benefits of static typing. VB came out of the gate swinging back in 2008 with its type-inference but there’s yet more that can be done!
Flow-Sensitive Typing
The marquee feature is flow-sensitive typing, which I’ve been chasing (off and on) for 7 years now. It’s gone through several different names in that time: Option Infer Turbo, Smart Variable Typing, The Crazy Feature, Smart Casting (what Kotlin calls it), “That thing TypeScript does where…”, Smart Type Testing, and finally Flow-Sensitive Typing. I’m going to keep using that name because for 7 years I casually searched the internet for a consistent term to describe it across languages and didn’t find one until about a month ago so now I’m going to abuse it so that others may find it.
I was initially very hesitant to propose this feature to the design team. In fact, initially whenever a VB user would (always cautiously and in private for some reason, like they dare not hope) say to me “You know what I really want? I wish that if I test the type of a variable and it succeeds, I wish the variable acted as if it had that type inside the If”. And when this happened I’d say, “Oh yeah, but there are problems with that… and what we could do is declare a new variable with that type… pattern matching… easier”. And one day I got to writing out a long reply (presumably to someone online) explaining all the technical challenges and on one side of my brain I was enumerating the problems, and on the other side I was hacking out “well, actually…” solutions until finally I convinced myself that it was at least possible to do it.
So, I went to the VB LDM with my “crazy” idea. I let them know up front that I knew it was “crazy” but that I just wanted them to suspend their disbelief long enough to mull over some possibilities. And I didn’t exit the meeting with a resounding “let’s do it” but I did get some thoughtful head nods that it wasn’t quite as un-implementable as they thought it would be. And after the meeting, I was chatting to Mads Torgersen said to me in our 1:1, “You know, I think you’re underselling the feature and yourself. It’s not crazy at all, this is just one of those problems in programming and some languages solve it using pattern matching and some solve it this way” so I stopped calling it crazy and kept iterating on the design. Thanks, Mads!
Fortunately for you, you get the skip over the considerable time I’ve put into how it can actually be implemented in the Roslyn VB compiler without violating certain invariants and architectural truths I’d rather not disturb. You just get to just focus on the developer-facing implications, which are considerable. Let me walk you through the history
As I said, it all started from a very simple (to make) request: If I test the type of a variable and it succeeds, I want the variable to behave as if it had that type from then on.
As the saying goes, easier said than done.
IfTypeOf animal IsDuckThen
animal.Quack()
EndIf
Oh, I see now that I’m editing this that I should mention this isn’t Duck-typing, this is a compile-time Duck, I just picked that species by chance.
And, of course, the all time top requested VB feature, to be able to Select Case on the type of a value
At long last, in the last hours of the last day of the week that marks the 33rd anniversary of Classic Visual Basic, I am finally ready to share with you my comprehensive vision for the future of the VB.NET language via ModVB.
As mentioned, last year I started out with an 11-page outline including some code examples in Word, noting ideas for some 110+ investments in completely new features or modifications to existing features collected over 12 years as a VB.NET developer and 8 years at Microsoft as a VB.NET language designer combed from countless personal experiences, customer interactions, bug reports, forum questions, etc. I set out to decompress this outline into effectively a book of concrete, thought-out designs that I could share to illustrate the language-specific scope of ModVB.
If you’re a new reader, ModVB is a Visual Studio extension I’m developing which adds new functionality to the VB language and tooling. You could think of it as a modernized extended Director’s Cut of VB to empower and be enjoyed by VB enthusiasts such as myself. I’m both attempting to crowdfund and crowdsource the project so it’s urgently important that potential supporters and contributors have an idea of what all they’re supporting.
Having said all that, while the exercise of methodically and holistically working through the entire outline has absolutely paid off, my previous draft had 120+ individual blog posts (I called chapters) written in specification-ese, and it became apparent that most folks wouldn’t see the forest for the trees. “What’s in ModVB?”
Any normal human: What’s in ModVB?
Me: Start at this link and click the “Next” link 120 times. If you skim it you’ll be done in a couple months and it’ll all make perfect sense to you.
So I’ve been aggressively editing and refactoring for the last several weeks and I decided this anniversary was my hard-deadline. Instead of my design process memoirs in 120 chapters, I’ll be sharing a mere 18 section summaries illustrating the various features primarily in concise, compelling, code. Not endless prose. Code with a few sentences here or there and I’m going to trust my audience to ask questions when they need, provide criticism when they feel, and to generally trust that I’ve done my homework on this. As short as an example may be, the process to vet the design (both for worthiness and achievability) was not short. All of these investments have a scenario somewhere. A question I was asked, probably more than once; an API I used or was blocked from using; A tool I or someone else wished they had. And every feature I propose is a feature I know I can personally implement in the Roslyn compiler (not that I will be implementing all of them). Maybe that’s a fault in my designs that I limit myself to the box of my own capabilities but it’s also my bedrock.
@DualBrain has set up a VB Discord server for all dialects of VB, Classic and .NET—Join Today!
Hey all,
In my last post I said I might be finished in November. That didn’t happen and the publication I’ve been working toward is now coming up on 200-ish pages. I’m aiming through editing to keep it in that range (for comparison, the entire VB language specification is < 700 pages). Editing has been a mix of expanding some chapters and reducing/combining others. I’m really liking the improvements to flow now with each section having 1-3 deep chapters (like XAML literals) and the rest be shallower chapters. I know this document is huge so I’m really trying to keep it from being boring or monotonous. I’ve added a section (technically I moved some chapters from other sections to a new section). I am considering (no promises) a stagger publication of one section at a time, but I haven’t yet committed to that approach.
A friend has convinced me to come up for air this month to get some other things in my life ready for the new year so I won’t promise this monster of a publication will be done this month. I’m still working on it but I’m trying to be more realistic about other end-of-year competition for my time, including holiday time with family.
Happy Holidays and Warmest Regards,
-ADG
Special Thanks to ANYONE who is donating or has ever donated to me via Patreon! I could not pursue my dream of producing modern VB features and content without their support.
Dr. Donna M., Alex T., Kirill O., Neal G., Govert D., Dr. Anne J., Taiwo A., Jonathon M., Peter B., Kevin R., and Paul C.
@DualBrain has set up a VB Discord server for all dialects of VB, Classic and .NET—Join Today!
Hey all,
It’s November already. I’m still plugging away at the ModVB Language/Runtime/Compiler backlog reveal. I’m currently working on the section on “Null and Nothing”. This was the last section to be added explicitly and is the least or second least developed. After this I just need to pump out a few pages on performance and interoperability and I think I’m on track to drop the massive collection of posts this month.
In the meantime, a community member over on the VB Discord server asked for a quick reminder of the highlights of what’s planned for ModVB. I paired down my documents to something … highlight-y and I thought others would benefit from the summary. The exact order of sections is subject to change but the spirit and highlights of each are below.
Remember, ModVB is not one feature or a few features but a focal point for the continued evolution of the VB.NET language, based on the Roslyn codebase. With regard to actual capabilities/features/fixes, there are currently over 100 distinct work items on the backlog in the language, compiler, and runtime library, broadly organized into a dozen or so buckets (subject to change). Please understand these highlights are nothing approaching exhaustive.
UI, XML, and XAML
Enhancing VB’s existing XML capabilities for modern front-end development targeting the web and mobile.
Highlight:
XAML literals
+ at least 5 more!
JSON
Replicating VB’s amazing XML story with the JSON data format.
Highlight:
JSON literals and JSON pattern matching.
+ at least 4 more!
Smart Casting and Pattern Matching
Features for testing types and shapes of data and inspecting complex data structures.
Highlights:
Checking a local variable/parameter with TypeOf will cause its type to change where the compiler can infer it is safe.
The top-requested VB feature: Select Case TypeOf
General pattern matching against types, tuples, wildcards, strings, and other user-defined named patterns.
Streamlining and Boilerplate Reduction
Does what it says on the tin.
Highlights:
Key Fields & Properties, and Auto-Constructors
Top-Level Code
Type-Inference improvements
+ at least 10 more!
General Modernization and Evolution
Revisiting almost every statement in the language and a few other constructs to improve them in some way, long requested features, consistency fixes, etc.
Highlights:
Tuple deconstruction in several places in the language such as local variables, For Each loops, queries, etc.
Select Case on object identity.
“Closed”, Generic, and Nestable Module declarations.
+ at least 15 more!
Declarative Programming and Code Generation
Features which make it easier to reuse functionality across repetitive tasks both with and without source generators.
Highlight:
Source Generator support features
+ at least 2 more
Asynchronous Programming Enhancements
Deeper integration of asynchrony with the language.
Highlights:
Await Each blocks
Async Iterator Functions
+ at least 4 more!
LINQ Enhancements
Revisiting LINQ after 15 years with new features and fixes to make working with data even more productive.
Highlights:
Queries in For Each (and Await Each) blocks.
New operators
+ at least 7 more!
Dynamic Programming Enhancements
Revisiting VB late-binding to make it work better and work in more places.
At least 11 topics!
Interfaces, Inheritance, Extensions, & Delegates
Making OO fundamentals more productive.
Highlight:
Implicit Interface Implementations
+ at least 6 more!
Null and Nothing
Making working with the reality of nulls in code safer, more elegant, and more consistent.
Highlight:
Nullable reference types
+ at least 3 more!
Performance and Interoperability
Improvements to let VB developers write faster code for performance-critical components as well as interoperating with modern features of the .NET platform.
Highlight:
ByRef Structure story
+ at least 4 more!
Versioning
Better features for dealing with or initiating change between library versions.
Runtime Library Enhancements
Revisiting the VB runtime library so that it’s more portable, more performant, and more useful.
Highlights:
Runtime helper optimization
My namespace modernization
+ more.
Summary
If you were keeping count that’s over 100 separate topics! After I finish writing I’ll move things around some to make things flow better and I’m trying to combine certain very similar topics where it makes sense and each topic may be anywhere from half a page to 10 pages for the largest topics so it’s not an exact page count but as promised, this “post” will be massive. My next update should be that the artifact is “text complete”. See you back here soon-ish.
Regards,
-ADG
Special Thanks to ANYONE who is donating or has ever donated to me via Patreon! I could not pursue my dream of producing modern VB features and content without their support.
Dr. Donna M., Alex T., Kirill O., Neal G., Govert D., Dr. Anne J., Taiwo A., Jonathon M., Peter B., Kevin R., and Paul C.
I need every drop of writing power in me to go toward writing this monument so I’ll keep this short. Per my last post I’m taking my 12-page outline for the ModVB language enhancements and expanding it out into a high-ish level conceptual overview of each enhancement with a short-ish motivating scenario and/or example of each. I hoped to be done by end of July. That was pure foolishness. As it stands this overview will definitely be over 100 pages printed!
Unlike my original Exhausting List of Differences Between VB.NET and C# post, this won’t be a single monolithic document. To make it easier to publish, revise, read, comment on, link, etc. instead I’ll be publishing each enhancement as a separate post. They’ll all be published at the same time and linked from a master table of contents (and maybe an index) which will be the “post”. Right now that means something over 110 (and counting) separate posts each averaging about a printed page, organized into 14 sections (and counting).
I’m trying to keep them all at a similar level of detail which is more than “I got an idea”/suggestion on GitHub/UserVoice level but not as detailed as a feature speclet that a inexperienced compiler dev could immediately start work off. I have several reasons for not wanting to publish each post one at a time over the next 4 months, one of which is that it would mean publishing each post one at a time over the next 4 months. But also, doing it this way will empower us to have a much better conversation about the entire scope of the backlog, prioritization, and how and where it could make sense for future contributors to pitch in.
Sorry it’s taking so long, but this is the culmination of 20 years of professional experience working in and on VB.NET, we’re all going to have to be patient with it. Thanks!
Long-time VB MVP Cory Smith has set up a Visual Basic Discord server for all dialects of VB including VB.NET, Classic VB(6), VBA, and VB Script. All are welcome! Please consider joining today!
Several supporters have mentioned that Patreon is blocked in some regions of the world and that would be supporters would appreciate an alternative. I thank them for bringing this to my attention and am investigating additional platforms for crowdfunding, though more importantly I’m planning for more ways to contribute.
You’re loooooooong overdue for some updates so let’s get to it. So far this year has been an adventure and I’m going to give you a whole rundown of events in the second half of this post but first I want to talk about some changes (good I think) I’m going to be making to be more transparent as well as help capture and accelerate momentum for ModVB and related projects in the near future. The project isn’t vaporware, I just suck at scaling (I apologize) and I’m pivoting to address that.
What’s going to happen moving forward
I’ve been giving tremendous thought to how I can better scale. This ModVB project is important to me and a (slowly) growing number of followers and it deserves more than it’s been getting. Also a few of community members, including past community contributors to the Roslyn project, have reached out offering to pitch in. Taking on more contributors has always been in the cards and we’re rounding the corner to the right time to do so. One consideration to doing so has always been my own bandwidth for working with contributors and testing and reviewing code coming into the project. I’m not going to loosen up on my quality bar for the project, but I am readying myself mentally and practically to function in the role of project manager, tester, and code-reviewer. I also respect that simply having more hands involved in the work will lead to more steady progress and build confidence for would-be adopters that this project is a safer bet.
Here are some more concrete steps that I’m working on:
(Finally) publishing most of compiler/language/runtime backlog
I’ve frequently mentioned the 11 (now 12) page outline of language changes I have for tracking planned and potential modifications to VB. I know I’ve been pretty secretive about this list so far mostly just to avoid feedback flooding but also showmanship and other reasons. Those days are fast coming to a close. And I’m not going to just publish the outline as is but a true to form Anthony-style “Wall of Text” laying out each feature, key design points, motivating scenarios, and in even my thoughts on what the “demo script” for the feature would look like. This will go waaay faster than my current approach of waiting to do everything myself and revealing things only with a < 5 minute YouTube video and will empower others to go after the low-hanging fruit in parallel with my own work. In fact, one VB community member already has implemented a feature that I’m very interested in pulling into ModVB.
I’m putting this post together to inspire both contributors and supporters with my vision for the future of the VB experience that I truly believe is exciting and achievable by the community, completely independently. This document will be the basis for both project planning and myriad strategic and design discussions I’m literally aching to have so … I’m really excited to finally be preparing it to share! I sincerely hope that finally seeing most of the big picture will put new winds in this project’s sails.
Setting up the repos for more contributors (than me)
Feature speclets and full specifications (over time)
Timeframe
The timeframe I’m targeting for most of this is early-mid summer, so, either late June or sometime in July and just in time for the 1 year anniversary of my announcing ModVB.
And the XAML literals + top-level code work is still coming. It’s not vaporware, it’s just approaching release asymptotically while I’ve been juggling other projects and life events. Which brings me to…
What’s happened so far
When I decided, a year ago, to take some time off to kick start this ModVB thing, I imagined (and planned, and saved for) 5 months or so. Basically a nice self-funded sabbatical to dedicate myself wholly to a creative endeavor that truly matters to me. I want to re-emphasize that number: 5 months. I figured that was enough to get through the first couple of waves and parachute into a new job somewhere. SPOILER ALERT: The mass layoffs, various hiring freezes, and general contraction of the tech sector starting right about when I was supposed to deploy this metaphorical parachute quickly showed me the error of my presumption. So, when I write to you a year from the start line you can understand that at least 7 of those months of unemployment were completely unplanned for. I’ve basically been operating in survival mode since last fall and the great news is that I survived. I survived with a lot of help, from family, friends, clients, and those of my readers who became Patreon supporters.
Highlights
I was (briefly) writing a VB.NET book for a popular publisher
That’s right! In the beginning of this year I was approached by a popular publisher about authoring a book on VB.NET, adding to my list of 3 or 4 projects I was juggling at the time. I was excited for the opportunity but ultimately after going through the initial steps of authoring, I realized that in just explaining the feature work in ModVB in the near future I was already committed to writing like a book’s worth of content and that it was insane to try to write TWO books at once while also juggling project work. Maybe next year.
I changed health insurers… and lost my entire healthcare team and all my appointments
I switched to a more reasonably priced health insurance plan which has been a major relief. However, because healthcare is never simple in this country, doing so moved my entire healthcare team “out of network” and basically meant restarting my entire healthcare regimen from scratch with a new primary care person, a new team, etc. I still haven’t really recovered from the switch though fortunately my medications have been maintained.
Stunlocked
Having said that, it turns out that managing a workload of software projects from multiple contracts, managing my (mental) health, and managing ModVB are all full-time jobs on their own. Being one person, I’ve naturally been sucking at all of them.
“Enough about your personal problems, is this XAML stuff ever going to happen?”
Yes. Here’s what goes into a normal feature for me.
Designing/implementing/testing the feature in the compiler
Designing/implementing/testing basic IDE functionality around the feature in editor
Designing a compelling motivating scenario to demonstrate the feature in under 5 minutes and implementing any demoware sample projects that go with it
This is normally like ~2ish months of work. But XAML literals have extra steps because they implement a base pattern in the compiler but to really exercise the feature you need a mature implementation of the pattern. By comparison, the design of LINQ is a very meaty set of features in the compiler but imagine if LINQ couldn’t be coherently released or demonstrated without first implementing several LINQ providers—not just LINQ to SQL or Entity Framework but two or three other implementations. This is where the tail end of development has just been dragging on. I can’t just say voila XAML is implemented in VB now but I need to release it with:
XAML bindings for .NET MAUI
XAML bindings for Avalonia
These are important because while they both use the same XAML syntax the way that XAML is translated is wildly different, which is good because it exercises the generality of the feature but I also have to prototype enough of XAML bindings for a hypothetical/prototypical VB Web library which doesn’t yet exist but which we’ll want to start building pretty much immediately after launch. And each of those bindings has to be tested as well. And consider that the feature has to both be tested in a unit test in the compiler which does not import any of these UI frameworks into the compiler test dependencies, i.e. I’ve had to mock compiler extensions representative of all the real scenarios that need to be supported in in the initial release but ALSO have separate automated test suites for each of the real extensions. Right now I’m trying to distill a kind of “VB XAML standard” test profile that can be reused across multiple implementations to hit a set of key scenarios (e.g. object graph deserialization, data binding, styles, templating). It might seem like I’m boiling the ocean and maybe I am but what I don’t want to do is ship an incomplete pattern which then requires me to ship new revisions of the ModVB compiler every week or two as the implementations of compiler extensions uncover and fix more bugs. Now there’s a dependency hell where you need to upgrade the extension libraries AND the compiler constantly to get anything to work. I would like the compiler pattern to be mostly stable and the extensions themselves to do more of the churning.
All of that would be a lot if I weren’t, as always, struggling with mental health issues, and if I weren’t juggling multiple projects with multiple clients that I’m trying to meet obligations with. To put it into perspective, out of the entire backlog this is both the most important and the single largest feature I ever plan to implement in ModVB. That’s why my original (flawed) plan was to do this kind of work during a period where I could focus almost entirely on ModVB. But it’s OK, because soon talented folks are going to be able to help me scale better.
Summary/TL;DR
Juggling lots of smaller contract gigs and personal issues has really slowed progress but there’s more bandwidth on the horizon. Regardless, it’s always been the expectation that ModVB would welcome some additional contributors and that time is fast approaching this summer; preparations are being made, most importantly of which is publishing a wall of text detailing the full backlog for the language so that both contributors and supporters can gauge their interest to chip in. XAML work still incoming, gated by a high quality bar.
Wave 2 is progressing steadily though I think it’s approaching an inflection point. January was very challenging balancing out working on XAML literals alongside my contract work, but I still feel like I’m converging on a release. I want to share more insights into what’s going on behind the scenes, so I wrote this post. It’s really a chance for me to just nerd out about design so if it doesn’t excite you that’s ok. I find it cool because I’m a language design nerd. To appreciate some of the recent design changes and their implications you need some background on compilation that I’m going to try to sum up. A few years back I wrote a primer on Roslyn and how compilers work. Folks have been asking me to pick that series back up (and I know I’ll need to to involve more folks in mod development) so think of the first part of this post as a draft of doing so.
A quick review of compilation
At a high level, compiling a VB.NET program is broken into 4 phases:
Syntax—what you type
Semantics—what it means
Lowering—reducing high-level VB constructs like loops and Await into low-level CLR constructs like Goto (it’s almost all gotos at the CLR level)
Emit—writing the actual bytes that the CLR will load and run to an EXE or DLL file
The scope and separation between the first two are what’s relevant for this post.
Syntactic analysis means taking a sequence of characters literally one character at a time and assigning those characters to structure based on the set of rules that most people intuitively think of as “the language”. Syntactical analysis itself happens in two “phases”. I put that in quotes because in a textbook college-level computer science class you might think of them as “phases” that happen one after the other but technically in Roslyn they happen at the same time and are very interconnected. Those phases are scanning (also called lexing, or lexical analysis, or tokenizing) and parsing.
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 specification—the 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!
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.
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.
