This isn’t anything radical (outside of the common use of the word meaning cool, in which case yes, it is!). This is the same technique developers all over the world use every day with LINQ and Entity Framework. Leveraging expression trees to write code in VB.NET that is then transformed into SQL and executed on another machine. I’m using those same capabilities to let me write glue code with the same convenience.
And to be clear, this is the exact same pattern I used for my Xamarin post last month. I haven’t changed it to support this new use. It’s just sufficiently flexible that it could enable this “out of the box”, so to speak. You see, because the XML pattern can instance and initialize arbitrary types, when those types make use of other types like
System.Linq.Expressions.Expression that rich information is available to the compiler so things like the natural ability to convert to lambdas to expression trees just “falls out”, as we say.
An interesting bit of trivia: Originally, I did plan on (and I am proposing) extending the currently limited set of language constructs supported by expression tree conversion. However, I did not have to extend it nearly as much as planned. 1) Statement (
Action) lambdas are already convertible to expression trees in a very few cases, 2) I was surprised to learn that assignment is one of those cases if and only if the target of the assignment is a property. I’ll add that to “The List”. So, for this demo I just relaxed the restriction that syntactically the lambda had to be a single line lambda just to further clarify for viewers that this is an assignment, not a comparison. But even without that, the ingredients are all there.
The product of the whole is much greater than the sum of the parts
This is the power of orthogonality in language design. Every feature doesn’t have to be “big” if a number of smaller seemingly less sensational features can work together to produce a great result.
- Top-level code has been independently requested throughout the years; it’s not a “big” feature to design or implement nor a massively disruptive addition to the language.
- XML literals were added to the language over ten years ago with a narrow focus on providing a declarative syntax for using the XLinq API; it’s not a radical suggestion to generalize this useful albeit niche feature to bring that declarative productivity to other types.
- Expression trees have also been around for a decade and members of the community have independently suggested extending the languages to support more of constructs on multiple occasions throughout the years.
Each of these is a mere evolutionary step of 10, rather than a revolution step of 100 but 10 x 10 x 10 is 1,000! And if you think about adding JSON literals to the mix there might be even greater rewards!
Somewhere out there in the VB web development community is the author or authors of the next built-for-VB web framework a la DotNetNuke (originally written in VB.NET) or Suave (built for F#). My question to those community members is:
- If you had a language with the richness of capabilities and tooling like VB.NET—things like Async/Await, string interpolation, and LINQ
- And that language was homoiconic—you could easily get a data structure representing the code written in that language to manipulate and even translate as you see fit
- And that language could natively describe the two most important data structures on the modern web, the DOM (via XML literals) and JSON (via JSON literals)
- What could you do with that?
I’m personally very excited to find out!
I’m certain I’ll probably do a one-off post showing more on this topic in the future but this wraps up the series about this prototype. I’ll decompress my design notes on GitHub ASAP and post an update on this blog when that’s done. I absolutely want to discuss a whole bunch of interesting design questions about a hypothetical VB.NET web app framework built using the techniques I’ve shown in these last two posts, but I want to be clear that that effort is orthogonal to this feature. To that end I’ll decompress a separate set of thoughts about it specifically in the post after my next one.
Until then, as always, thanks for reading, thanks for watching, please share this post, and let me know your thoughts in the comments below and/or on Twitter.
This is very interesting. The thought of supporting VB in web client programming is exciting although seemingly far off.
Please can you provide more clarification about what you meant by “…but I want to be clear that that effort is orthogonal to this feature.”
I was hopeful that Blazor would support VB.NET everywhere but Dan Roth’s comment at https://github.com/aspnet/Blazor/issues/171 erased that hope:
“The Razor syntax (.cshtml) used to author the component rendering logic is C# based, and there is no plans to change that, but all of the rest of your app logic I believe could be written in VB.”
“Orthogonal” is a term often thrown around by language designers. It actually means something specific in mathematics but we just use it as jargon for “a separate issue”, usually to say that we can solve one thing without figuring out or doing anything about another or that we can deal with them separately.
So, the design of LINQ expression trees is orthogonal to whether query comprehensions support extension methods. Both of them work together to create a great end experience but neither feature has anything to do with the other.
In this case, I am proposing an open-ended feature that /could/ let enterprising VB library authors do an unspecified set of things. I’ve prototyped a few examples to demonstrate the soundness of the idea but it’s not necessary to make decisions or commitments to any of those examples in order to move the feature forward. They can happen in parallel, after, or never, and any design decisions about them, branding, dependencies on other libraries, etc, are beyond the scope of the proposal. Please note, that doesn’t mean I’m uninterested in the ideas. To the contrary, I’m more excited by them than I’ve been in a long while. It’s just that as a matter of discipline you have to deal with them separately.
The Razor syntax is C# based. That’s a 100% true. And I don’t care. The web is big enough for have multiple languages and view engines with multiple different styles.
So, if you look here: https://stackoverflow.com/questions/1451319/asp-net-mvc-view-engine-comparison
There’s a list of many view engines that have been made for ASP.NET MVC. I think they’re all pre-ASP.NET Core but that doesn’t matter. They all balance trade-offs differently. Some support C# or VB or F#, some don’t. F# has an entire list of strategies for targeting ASP.NET and the web without Razor. Those ideas are built on F#’s strengths and its design philosophy (functional).
IMO, Razor isn’t interesting for VB. Something built for VB, that plays to its strengths, and that respects is various design philosophies are interesting for VB, or at least to me.
I’ll take a look at the Blazor stuff eventually. If it’s like the rest of the ASP.NET Core stuff there will be re-usable composable extendable logic in there. I really tried to emphasize in these posts that all the web stuff I’ve shown really is just the released bits of ASP.NET Core 2. I didn’t do anything unnatural to it (like modify its source). It IS an ASP.NET Core 2 app. It’s not that VB can’t target or run on ASP.NET Core. There’s no bouncer at the door saying “I see a call to CInt in the IL, you shall not pass”. VB lacks a proper view engine and I don’t think Razor is the best solution to that lack.
LikeLiked by 1 person
Hi Anthony, I didn’t receive notification for your response. Thanks though.
Do you have any roadmap for this ( no pressure 🙂 )?
What about Blazor and WebAssembly?
I think you should consider them in creating the client side controls.
I haven’t looked at them but hopefully there’s some reusable stuff there. This post is purely to show that the proposed language feature would allow someone (it could be me, it could be you, it could be multiple others) to make and consume frameworks that do cool stuff. The specifics of how to do that stuff is up to the library author(s).
Blazor needs to create a new VB.NET-to-WebAssymbly Compiler. After that, we can use all blazor components. There is already an effort to create such a compiler:
The pattern-based xml is extremely useful when Xaml is not available. But this feature will not have any chance to be merged into the official build of Roslyn 😦
I don’t know why the .NET team decided to stop adding new language features to VB.