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.

Anyway, if you’re reading this blog you’re almost certainly a VB.NET developer so I can just describe these concepts in terms of VB without straining analogies to natural languages like English.

Scanning

Given the string of characters: Await A.B(C) ‘ Comment, scanning chops the string up into a sequence of 7 tokens:

• Await
• A
• .
• B
• (
• C
• )

Scanning of course uses whitespace to separate tokens but whitespace (in VB) isn’t itself a token (other than newlines). Comments are, like whitespace, not tokens, they’re just something the scanner knows to skip over.

Parsing

The parser takes that flat sequence of 7 tokens and builds a tree structure

• ExpressionStatement
  • AwaitExpression
    • AwaitKeyword: Await
    • InvocationExpression
      • MemberAccessExpression
        • Identifier: `A`
        • Dot: `.`
        • Identifer: `B`
      • ArgumentList
        • OpenParenthesis: `(`
        • Argument
          • Identifier: `C`
        • CloseParenthesis: `)`

So, in this example the scanner decides that A, B, and C are identifiers (as opposed to keywords, punctuation, operators, or literals) but not what they refer to. The parser is what uses those tokens to build structure of expressions and statements (and declarations): C is an argument to an invocation, B is (presumably) a named member of A, etc. But again, parsing doesn’t decide what any of those identifiers refer to. Maybe none of those identifiers refer to anything and the program is an error. Maybe A is a namespace and B is a function in a module in that namespace. Maybe A is a local variable, B is a property that returns a collection, and C is being passed to the default property of that collection. The parser doesn’t determine that, that’s what Semantic Analysis does.

Interdependence

Again, in an academic context lexical analysis and parsing are very neatly separated but in practice in VB.NET the parser directs the scanner with context that only it knows about. For example, the parser knows whether it’s parsing inside of an Async method and that’s what determines whether Await is a keyword or an identifier (and thus whether Await (x) is a parenthesized expression being awaited or something called Await being invoked with argument x).

This familiarity between the parser and the scanner are what make it almost trivial to embed languages like XML, JSON, and the String.Format syntax for interpolated strings into VB; the parser is what knows whether it’s “in” an XML literal, JSON literal, or interpolated string and thus instructs the scanner to tokenize characters appropriate to that context.

Token values

Part of scanning also involves assigning what in Roslyn we call the value of a token. So identifier A, escaped identifier [A], suffixed identifier A% all have the value “A”—that’s the name that identifier declares or refers to. Decimal integer literal 10, hexadecimal literal &H0A, and binary literal &B1010 all have the value of integer 10. The value is part of the token, is what’s used by the compiler during semantic analysis, and is separate from text of a token. Another more relevant example is the string literal ”5’8””” which contains an escaped quotation mark, the value of that string is 5’8” what would be written to the console if you printed that string token. Likewise the value for XML text tokens in an XML literal replace XML character and entity references like &, &, & with the character &.

Immutability

Now, the last thing to keep in mind about the phases of compilation is that the output of parsing is an immutable syntax tree—a hierarchical data structure that cannot change once created and is fed into semantic analysis (along with project references) to determine the meaning of a program. There’s limited examples of parsing re-interpreting a scanned token in the moment (e.g. around contextual keywords) but that’s still in the midst of parsing. Once parsed there’s no going back during semantic analysis to decide that the developer typed something else.

OK. I think that’s enough of a review for the rest of this post.

A XAML Literal is a semantic distinction, not a syntactic one

With that understanding, note that whether or not an XML literal in VB represents a XAML literal is a semantic distinction. XAML is XML and syntactically (to the parser) a XAML literal will look like any other XML literal. It’s during semantic analysis that the XML namespaces in scope (which, remember, may be imported at the file or project level) are examined and checked against the available runtime extensions to determine what that XML translates to. Whether that’s an XElement instance, a System.Windows.Controls.StackPanel instance, or a instance of a class from an entirely different library is all determined semantically.

Markup extensions

This is all mostly good and well until you come to implement markup extensions because markup extensions have their own syntax.

In my original prototypes, I didn’t implement any special handling of markup extensions in the compiler. There were just hooks for extensions to process attribute values before assigning final values to members and those extensions could inspect XAML values for things they knew about like StartsWith(”{Binding “) and do whatever they wanted without the compiler having to know anything about it.

There are a several problems with this approach.

Markup extensions can be nested

OK, so one problem that comes up is that markup extensions aren’t just a pattern of simple values, they can be nested:

Text=”{Binding Name, Source={StaticResource Company}}”

But this isn’t the end of the world. Yes, it means the any implemented extension has to be able to recursively parse and process all of the supported markup extensions recursively. Annoying, but doable.

Markup extensions can be user-defined

Supporting all of the familiar markup extensions like Binding, StaticResource, DynamicResource, etc, would be very tedious on its own. But then you have to consider that XAML allows anyone to define their own markup extensions. And it’s not unreasonable to expect that if a user has defined such an extension that they’d be able to use them in a XAML literal just as they would in WPF, Silverlight, or WinUI.

So, ok, the extensions can try to parse and resolve custom binding extensions. Since these extensions will likely be mapped to arbitrary XML/XAML namespaces rather than in the default namespace it does mean the compiler must have a way to supply the XAML namespace mappings in scope for the extensions to do this but for other scenarios (type converters) the compiler would have to do that anyway so it’s not the end of the world. It does mean a lot of parsing, converting, and reflection at runtime which is a perf hit but again, it’s doable.

Users should expect a rich IDE experience typing markup extensions

If you were typing a XAML literal what kind of editor support would you expect? Completion on XAML namespace prefixes? Markup extension type names? Maybe data-binding property names? What about colorization within the attribute?

Technically the Visual Studio and Roslyn APIs do supply enough hooks that someone could, with a lot of work, implement these things over an opaque string (e.g. RegEx syntax colorization). But…

Markup extensions can have errors

Since all of this handling of markup extensions is deferred until runtime through extension helpers, when something goes wrong the way it would naturally be surfaced to a developer is at runtime—which stinks. What if you mistype a markup extension name—wouldn’t you want a compile-time squiggle for that? Of course you would! And then what about syntax errors—if you fail to close a markup extension you’d expect to hear about that early too.

But that’s where things get tricky! Because as I mentioned a while back, a XAML literal is a semantic distinction. In other words, …

<TextBox Text=”{Binding Name” />

…is an error if and only if that XML element expression is also a XAML literal. It would be too grievous a breaking change if otherwise valid XML literals all of a sudden started reporting syntax or semantic errors based on the fact that they would be erroneous XAML.

At first glance this made me think that compile-time error reporting should be left to an analyzer rather than the compiler because the compiler has a higher bar for correctness than an analyzer, which can only report warnings which can be ignored. Now you have a situation where the XAML provider extension is reparsing attributes values at runtime, and the IDE and analyzers are each reparsing attribute values as you type which really erodes the promise of Roslyn. So, eventually I decided that I wanted to do some analysis of markup extensions in the compiler.

Now that the compiler is processing markup extensions, it has to be decided how this information is represented. Naively, you’d add to the Roslyn Syntax API several nodes modeling markup extension syntax like you would when adding any new syntax to the language. But once again, remember that we only know that an XML literal represents a XAML expression at binding time—during semantic analysis. It would be … problematic for the syntax API to report that something “looks like” a special kind of XAML attribute. But, maybe not too crazy. By analogy, the compiler already has the concept of “structured trivia”. This technique allows the compiler to attach structure to a comment in a way that sits beneath its normal representation and this is what is used for XML documentation comments—interested parties can inquire on whether a comment has structure and other parties can treat it as just a comment. Maybe I could do something like that with the XML text tokens of an XML literal but I’m extremely hesitant as while structured trivia (comments) are a concept in the Syntax API, there’s no such analog for a potentially structured token.

Circling back to the question of how errors are represented, …

<TextBox Text=”{Binding Name” />

In our example we only want to report a syntax error here for a XAML literal, not a regular XML literal. But as I mentioned, once created a syntax tree is immutable. We can’t decide later that it has syntax errors or that it does not have syntax errors. So this is the cleverness that I propose:

We parse the markup extension but throw away any errors we find. If there were no errors we produce a valid WellformedMarkupExtensionSyntax node and if there are any errors we produce a valid MalformedMarkupExtensionSyntax node. In either event we don’t report ANY errors during parsing. When it comes time to bind a MarkupExtensionSyntax, if it’s a WellformedMarkupExtensionSyntax AND contained in a semantic XAML literal we bind it using XAML rules. If it’s a MalformedMarkupExtensionSyntax (inside a XAML literal) we reparse the entire expression but reporting this time reporting “syntax” errors alongside semantic errors. If it’s not a XAML literal we ignore the structure and just use XML value of the text in a regular XML literal.

Voila! Now we can have our cake and eat it too. We can report “syntax” errors for markup extensions but only inside XAML literals, and we can provide rich structure to the IDE and analyzers that they don’t have to recreate for themselves, and XAML provider extensions don’t have to do almost anything because the compiler is handling the semantic analysis of the markup extension (which is a XAML concept by the way, so it’s entirely reasonable that the compiler would do this). This is great because the actual rules for parsing and binding “text” inside a markup extension are arduous enough that to force anyone else to re-implement them would simply be mean spirited.

Spoiler: This isn’t what I ended up doing.

Markup extensions II

As I indicated in my last post, this whole thing has been part of the process of embracing the scope of the core feature of “Wave 2” as a true to name XAML literal, not just XAML-like enhancements to XML literals. This shift in mindset both frees me and binds me to lean on the formal XAML specification. For the most part this has been liberating and the XAML spec is actually a bit of a fun read. It describes a type system for XAML without actually depending on that type system being implemented by the CLR or any specific XAML vocabulary such as WPF, with notions such as “assignable to the x:MarkupExtension XamlType” rather than the CLR notion of inheritance from the WPF MarkupExtension class. It describes relationships between “types” and “members” and lookup without depending on the concept of a CLR property or classes or even static typing per se. If this doesn’t sound like a fun read to you, that’s normal. I am not. Not anymore.

So, there I am reading the XAML specification and for the most part everything is making sense and on page 72, in Section 8.6.3 “Member Node Creation from an XML:attribute”, I come across this one line:

Let attributeText be the string xmlAttribute[normalized value].

…and my head explodes.

The normalized value. Not the text as written. That’s when it clicks that the processing of attributes isn’t an alternate interpretation of XML but a subsequent step. In other words, in XAML (and you can verify this in the Visual Studio XAML editor right now), all of these (and more) are equivalent and perfectly valid markup extension usages:

• {Binding Name}
• {Binding Name&#x7D
• {Binding Name}

So it’s not enough to simply look at the text as we’re scanning an XML text token and check for a { character, one has to first tokenize the entire attribute value as XML—then retokenize the normalized value (the value after all XML character references and entities have been resolved). And there’s a further layer to this because markup extension syntax itself has an escape syntax where the value of {}{Binding} (or e.g. {}{Binding}) is not a markup extension but whatever follows the {} (however they’re encoded). And I hear you right now thinking “Who cares, though? You’re never going to run into this in the wild” and you’re right but we’re doing this The Right Way™️ so… in for a penny…

While at first this realization may seem like a complication, it actually simplified the design in that it left me firmly resolved that all computation of XAML “values” should happen entirely in semantic analysis. That is to say that once again parsing will be completely pure of any involvement of the rules of XAML or markup extensions or markup extension escapes and will purely handle the interpretation of text as valid XML. This is great for all existing code that handles XML literals as no special handling would be needed to undo pre-emptive XAMLfication of any speculative WellformedMarkupExtensionSyntax, MalformedMarkupExtensionSyntax, EscapedXamlAttributeTextSyntax, or anything else like that.

Designing an API for efficient tooling

As I mentioned above, the XAML specification provides a whole type system describing XamlType and XamlMember instances so it’s very natural to represent these concepts as first class in the compiler internals and to expose them through an API so that the IDE and analyzers can ask questions like “What type does this element construct?” and “What member does this attribute initialize?”; reasonable questions for providing a rich editing experience with completion and quick info, etc.

However, the Roslyn APIs are designed such that semantic questions are normally asked in relation to syntax nodes that very efficiently convey which span of text is being asked about and with XAML literal translation happening entirely in semantic analysis there is now a need for some way to ask these questions about offsets in an attribute’s text (and that’s a simplification). Long story short, I’m creating a pseudo-syntax API that captures the markup extension syntax so that tools can still be written efficiently. It’s very consistent with the true syntax API as I feel that’s ideal for API consumers. Having said that, I do think that XAML code editing tooling will have to wait for a future minor ModVB release because I need to get this feature out into your hands for testing/feedback ASAP. Maybe I’ll enlist help in building the code editing tooling from a community member.

Separations from and Interactions with top-level code

A few more design points…

InitializeComponent

In my earlier prototypes I planned to have the binding of top-level expressions special-case XML literals to support the common case of a XAML window or root object being initialized by a single literal. However, with this revision I’ve decided to move this behavior from being a special case of top-level code to being inherent behavior of a XAML literal expression statement inside a Sub (a method which does not return a value) whose name matches some configurable identifier such as InitializeComponent. This means that whether as a top-level expression statement, an expression statement in a top-level method, or an expression statement in a normal method in a normal class XAML-based initialization will work as expected. Aside from being a little cleaner this design is critical to enable testing of the XAML initialization scenario in isolation without top-level code, which is not implemented yet.

Name and x:Name/Code-behind

Another use case which is essential to reproducing the experience we’re all familiar with from WPF is backing field generation and wire-up for named controls. As it stands, the design of XAML literals is that using the x:Name directive (defined by the XAML spec) or setting the equivalent member (also a specified concept) on a XAML object will lookup a field or property on the specified x:Class and initialize it with that object. It does not cause that field or property to be created.

Part of the reason for this is because of a separation of subphases within Semantic Analysis—XAML literals are just normal expressions and are bound in the context of a method. Method body binding happens after the phase of semantic analysis that processes declarations. Of course, it would place undue burden on users if they were required to defined all their backing fields for named controls manually so the tension right now is between having these declarations created as a part of building declarations from top-level code (in contrast to the previous heading regarding InitializeComponent methods), or generating the fields explicitly through a source generator. The generator approach is closer to how WPF works today but the problem is to correctly determine which fields are generated and even their types requires semantic information. For example, if I assign a name to a control inside of a ControlTemplate or DataTemplate, Style, ResourceDictionary, or other deferred content that name technically exists within a separate namescope (A XAML spec concept). Only named objects within the root namescope should have fields generated. Which classes create their own namescopes is semantic knowledge which incurs a heavier performance penalty when using a source generator because the compilation must first be built up to the point where that information is available in order for a generator to ask about it.

Of course, a source generator could be hard coded with this knowledge (unlike the compiler) on a per-XAML vocabulary basis. One could even squint if the generator created too many fields in this case. But the alternative is to allow the compiler itself to do just enough semantic analysis of XAML types while building the declaration tree to create these fields. Both solutions can be elegant if you throw enough code at them and I’m currently trying to resolve this tension, though it won’t hold up testing/stabilization of the XAML literal feature because of my original design point—the XAML literal need only find the fields and initialize them, it takes no dependency on how those fields or properties are defined.

Another scenario that benefits from this separation, sort of, is the use of a XAML literal as an expression within a method. Having the literal take no responsibility for generating any new symbols means that a) I don’t need to design what to generate in such a use case, and b) it’s straight forward to design backing such objects with local variables.

The long tail of XAML scenarios

I hinted at the special handling of deferred content such as ControlTemplate and DataTemplate instances in the previous heading. There’s more testing and implementation to be done there beyond just namescopes. For example, .NET MAUI handles these very differently from WPF or Avalonia UI so I have to implement and test both approaches.

Another trailing work item I need to implement is ambient properties, which are a WPF concept rather than a XAML concept but an essential one for styling. I’m tempted to defer supporting this until later but styling is a pretty central WPF use case. Either way I think this scenario defines the cut line for wrapping the initial implementation of XAML literals. There is bound to be a long tail of minute technology specific scenarios the community will find when trying to port examples of different technologies to use ModVB and I’ll simply have to address those bugs as they come up.

Once and only once I feel confident in the stability of this subset of XAML literal capabilities will I move on to the implementation of top-level code. I expect a lot more stability bugs to come out of that feature than XAML literals and I want to make sure I’m not fighting two fires at once by mixing the two. I do think my original design for top-level code is pretty elegant and still the correct way to go and should be fairly quick to implement so fingers crossed Wave 2 should release this month. I already know supplemental features and tooling will come in a future wave.

Wrap-up

Thanks for listening to a rambling nerd to the bitter end. My next post will be a short personal update talking about what it’s been like juggling 4 projects in the month of January and other stuff.

Regards,

-ADG

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 3^rd 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:

• ASP.NET Core
• Blazor
• Xamarin.Forms/.NET MAUI
• Avalonia UI
• possibly OpenSilver
• other technologies

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 3^rd 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!

Regards,

-ADG

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

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.

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

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.

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