In my last post I introduced the idea of pattern-based XML literals—XML literals which construct arbitrary types other than XDocument/XElement/XAttribute/etc. And as promised, I have recorded a video showing off the practical benefits of this design when using Xamarin.Forms from VB.NET. If you’re not familiar with Xamarin.Forms it’s an API that abstracts over the differences between mobile platforms like Android and iOS to make it easier to create and maintain cross-platform apps while sharing the maximum amount of code. Watch as I explore the Xamarin VB sample app from the official Xamarin samples repo using this new prototype:

As you can see, it’s pretty empowering to be able to use XAML everywhere.

• I can leverage my XAML skills from WPF to a degree and be more productive.
• If I’m looking at the documentation or a sample or blog post (most likely written from a C# developer) that uses XAML, I can use that XAML in my code rather than first translating it to VB imperative code.
• In places where today you’d possibly have to give up markup for code like dynamic view creation, I can still use declarative XAML even if it’s in the middle of a VB method (this scenario comes up in writing VS extensions to the WPF editor too).
• Even with object initializers there can be situations where you have to fallback to imperative syntax like using attached properties but that’s not an issue using markup.
• I get to embed any VB expression inside my markup in places where that expressiveness is a benefit over XAML.

WPF XAML vs Xamarin XAML

Xamarin has its own flavor of XAML. It’s essentially the same on the surface (syntactically) as what’s used in WPF and Silverlight (and UWP) but it’s not the same XAML engine and it uses different types internally. Not just in the “Controls” or as Xamarin calls them “Views” but in the infrastructure itself:

• So rather than DependencyObject and DependencyProperty, Xamarin has BindableObject and BindableProperty.
• Xamarin has its own base types for type converters, and markup extensions, etc.

So, even though both it and WPF use the XAML syntax (which is XML based), Xamarin.Forms is powered by a completely different engine entirely. Possibly as a consequence of this the XAML used by Xamarin.Forms doesn’t support VB.NET. Which would normally mean you have to create your UI imperatively, rather than declaratively. VB guru Klaus Löffelmann wrote about how to do this back in 2017 on the VB team blog. It was a good post but the no-XAML part was kind of a bummer. This prototype changes all of that!

The Xamarin differences actually highlight another benefit to being pattern-based. Because the language understands patterns—certain methods with certain names and shapes existing—rather than specific types (like DependencyObject) it’s possible to apply the feature to a completely different system than WPF. If the feature were just WPF XAML literals built to understand the specifics of the WPF infrastructure you couldn’t turn around and apply it to Xamarin but by being pattern-based you can do that easily.

Under the hood

As I indicate in the video, the compiler knows XML and how to translate certain idioms in XML into call-outs to extension methods that encapsulate all of the Xamarin-specific knowledge. I’m pretty sure the pattern will change as I explore more but the first page’s code:

Translates to this:

As you can see, the compiler knows how to translate attribute values to enum members at compile-time. So if I misspell and enum member I’ll get a compile-time error:

Likewise the compiler knows how to translate an attribute value to a delegate creation, so that too gets compile-time validation:

Both of these make it easy to give in-context completion support in the IDE for these cases.

The keen observer may have also noticed that when I selected name CalculateButton in the value of the Name attribute at around the 2:45 mark in the video that references to CalculateButton in code were highlighted. This is another example of the power of Roslyn. Because the compiler binds that text to the CalculateButton variable, the IDE understands it as such and features like Go-to-Definition work automatically!

THIS IS A WORK IN PROGRESS!!!

I accidentally edited out the part where I show what turns a regular XML literal into a pattern based one and it’s a magic "clr-namespace:" XML namespace import at the top of each file (could also be in a project-level import). If I comment out that import you can see that I get conversion errors because the XML reverts to producing an XElement as it does today:

I expect to find a better way to enable the feature though because of some trade-offs with that approach. This is just a draft version of the pattern and I fully expect it to change as I explore other shapes of XML to apply it to and weigh certain experiences that could be built.

For example, right now the pattern respects both a SetChildContent and AddChildContent bridge methods so that the compiler can report an error if you include more than one child element in a situation where only one child is allowed, but maybe it’s better to simplify the pattern and enforce things like that in a Roslyn Analyzer (let me know what you think).

If you’re really curious as to what each of these bridge methods looks like, I’ve uploaded the content of the XmlExtensions.vb file from the sample app I showed in the video as a Gist. It’s just what I wrote out while exploring the pattern and shouldn’t be taken as the “best way” to write such methods and I played around with different approaches. Just take it all with a grain of salt.

Next steps

I know Xamarin.Forms has been around for quite awhile now but honestly I haven’t been as excited to try it out until now. I can see some places where the Xamarin team made extremely reasonable choices in their content model (like how templating works). I’m anxious to see how I can broaden the pattern to work well with those patterns and to just generally explore mobile app development from VB.NET.

Fun Fact: Due to Windows Mobile and Compact Framework and then Windows Phone and Windows 10 Mobile, I have not owned a phone that I couldn’t program in VB.NET in almost 15 years. I’m excited to continue that tradition.

One thing this video didn’t show off was tooling. Because it’s all just the VB.NET language and the IDE is powered by Roslyn, getting things like completion, go-to-definition, F1 help, etc. to work in such XML literals is much easier than it would have been pre-VS2015. Also, there’s this other unrelated prototype I plan to show off… 4-5 prototypes from now that could really improve on both desktop apps using WPF/WinForms and mobile apps using Xamarin too. So whether it’s to show off better tooling, to show off another prototype, or just because I’m having fun exploring Xamarin.Forms I don’t think this will be the last video I make featuring this topic.

As for my next post it’ll be a continuation of this series about this prototype but instead applied to web development. I think you’re going to love it so look out for it.

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.

Regards,

-ADG

P.S. As in my last series, I’ll upload all of my notes from implementing the prototype in a GitHub issue after the last post in the series. Don’t sweat the specifics of the pattern too much, they’re subject to and very likely to change. This post took me much longer than intended before the first few iterations of the video were over 30-minutes! It took some re-recording and aggressive editing to get it down to 5.X minutes, but I think that’s optimal for online viewing and sharing. I hope you agree!

“I have made this [letter] longer than usual because I have not had time to make it shorter.”
-Blaise Pascal

Hey all!

I’ve been down in the laboratory since my last post and I’m back with a brand-new prototype. I was working on scripting the first video for this prototype when I realized there’s just a lot of context to set beforehand so I’m taking a break to write a quick introduction.

What do I mean by pattern-based?

When I describe a language feature as “pattern-based” I mean that the feature is designed to work with any code that fits some pattern the compiler knows about rather than a specific limited predefined set of types. Not every feature is pattern based in VB.NET but several of them are. For example:

`For Each` doesn’t require a type implement `IEnumerable` (or that `IEnumerable` even exist) but rather that it meets the Collection pattern. A type is a Collection Type from the perspective of the compiler/language if it has an accessible `GetEnumerator` method that returns a type with a Boolean returning `MoveNext` method and a readable `Current` property and the `Current` property determines the type of the elements of the `For Each`. None of this requires `IEnumerable`, that’s just convenient and it means that library authors can write specialized enumerators which are more efficient in some way, usually by being structures rather than classes.

`Await` is another example. Everyone knows you can await `Task` and `Task(Of T)` but the language doesn’t require that, rather that the type have a `GetAwaiter` method that returns some type with the right set of members on it. If the type meets that pattern it is considered Awaitable. An example of this in action is the `Task.Yield` method which returns a `YieldAwaitable` structure, rather than `Task`.

Query comprehensions (the SQL-like LINQ syntax) aren’t tied to `IEnumerable` or even the `System.Linq.Enumerable` type either, but rather work on Queryable types—types which have a `Select` method that take a delegate that itself takes 1 parameter, the type of which is the element type of the `From` operator and may have other operators like `Where`, etc.

A big win from the pattern approach is that often a type can be made to support a pattern after the fact through an extension method. This is great when you don’t control the library that type is defined in but still want it to work well with new features. C# and F# also use this approach at times to varying degrees (F# turns it up to 11, actually). There are other features that use patterns (and ones that don’t) those are some big examples. Eric Lippert (of course) talked about some examples on his blog and one of the ones that don’t in either VB or C# (occasionally to my chagrin), the `Using` block.

Why?

Right now, XML Literals are in the ones that don’t bucket and I’m looking at what possibilities open up if that changes. These first three scenarios are minor. I definitely thought about them but I understand if they’re not top of mind of a lot of other people. They were stops along the train of thought. The last two though are pretty major so feel free to skip ahead if you aren’t interested in trivia.

Minor Scenarios

Windows Runtime/UWP XML

One of the first concrete scenarios I had was back when I was exploring the Windows Runtime/UWP library and I noticed that WinRT defines its own `Windows.Data.Xml.Dom` namespace which is, of course, not the `System.Xml.Linq` namespace that VB XML literals work with and I got to thinking, wouldn’t it be nice if VB could work natively with the WinRT types. If you look at the docs for creating live tiles and sending tile updates, the whole tile template system in Windows 8.x/10 is built on XML and their code examples look like they would benefit from XML literals and XML axis properties.

That’s one idea. It’s good language hygiene but fairly limited.

Rich WPF Message Boxes

I’m a big fan of Alan Cooper “Father of Visual Basic” (big surprise) and specifically his books on user experience like “The Inmates Are Running the Asylum” and “About Face: The Essentials of Interaction Design”. In one of those books he talks about message boxes and points out the ways software provides poorer, less situationally appropriate experiences because the default APIs are “good enough” and programmers just try to squeeze whatever problem they have into what the API provides rather than writing a custom dialog. It’s been years but I recall him showing an example of some program that wants the user to do one of two things and it puts up a dialog box that says something like “How would you like to proceed? Click ‘OK’ to file your taxes jointly or ‘Cancel’ to file separately with a 1099c extension”. Obviously, this choice shouldn’t be in terms of ‘OK’ and ‘Cancel’ but the programmer was too lazy to write the custom one-off dialog. The programmer has delegated mapping concepts from user-domain to the API to the user and that sucks.

The MessageBox.Show in WinForms and the other one in WPF are a little bit more customizable than this but sometimes I call MessageBox.Show and think “I wish I could provide a formatted string as the dialog text, maybe include some bolding or color or an image but the API just takes a string”. Ideally I’d be able to use all of WPF’s TextBlock primitives and just hand that to a generic built-in dialog presenter. I could write one, of course but there’s still some tedium to it because in my code I can’t use XAML, I have to imperatively construct a potentially elaborate object graph and that stinks.

XML-based DSL’s

If you look at the unit tests in the Roslyn source code, you’ll see thousands of examples of things like this:

The test team created these DSLs for setting up tests for the compiler and the IDE that other code then parses to create the actual test environment. XML has just enough structure vs strings while being flexible around multiline content. It’s neat and in a lot of places convenient to use XML to describe these test cases declaratively but it’s unfortunate that everything that happens in the XML literal is opaque to the compiler so you don’t get any tooling assistance at compile time. You could help this a little with analyzers but there are still seams in the experience.

Major scenarios

ASP.NET Core

In an earlier post I showed you how one could use XML literals to make a basic view engine for ASP.NET Core. It was nice but because it’s just producing an anemic XML DOM there are some limitations on how kick-ass it could be. I’m trying to see how far I can take it.

Xamarin.Forms

On the other side of the spectrum we have Xamarin.Forms. I’ve been interested in Xamarin for a few years now but one thing that bugs me is that to use it in VB I have to use code to construct my UI. I can’t use my XAML skills (until now).

So, I made a prototype…

The challenge is, can I come up with some reasonable pattern that would enable an XML literal to construct and/or interact with things other than the XLinq API. I’ve got a first-draft and some notes and a about 2-3 scenarios to show you based on what I came up with that I hope you’ll like. The first one up is the Xamarin scenario and it’ll be the subject of my very next post. I just wanted to get all the background out of the way so I can focus the video and the blog post on the scenario itself rather than general context setting.

Regards,

-ADG

At last we’ve come to the last of my planned scenarios for this prototype–a little thing I like to think of as a WYSIWYG Web Service, or WYSIWYGWS for short. A few months back I had recently finished the JSON literals post and video and was anxiously combing my immediate vicinity for more scenarios when Scott Hanselman came along quite serendipitously with his post, Converting an Excel Worksheet into a JSON document with C# and .NET Core and ExcelDataReader to inspired me.

I asked myself “How simple can defining a REST endpoint be?” and here is the result.

Of course there are myriad ways to approach this problem with various trade-offs, this is just one.

One developer on Twitter asked Scott (paraphrasing) “Why not just use PowerShell?”

To which Scott replies, “Very useful, yes, but would require additional PowerShell to get the output JSON I wanted”

Very useful, yes, but would require additional PowerShell to get the output JSON I wanted

— Scott Hanselman (@shanselman) March 12, 2019

And another developer says, what are the benefits of using ExcelDataReader over this PowerShell command?

And Scott reiterates, “Control over the result is all”

Control over the result is all

— Scott Hanselman (@shanselman) March 12, 2019

And that’s one key aspect to this scenario. Scott had an idea of what shape he wanted at the end and it was just a matter of getting what he had into that shape. And in the video above that’s exactly how I approach the problem as well, I start with that shape and then populate it. Now that’s what I call… Design by Contract! (ba dum chhh)

Another element to the scenario is data that is… uncooperative:

• You can’t control it
• You can’t annotate it serialization attributes
• The shape isn’t right for default serialization
• It’s coming directly from an external (not .NET objects) data source like a database, mainframe, device, other service, or in this case a file

And that last point is more important than you might think. Every day (on Facebook) I see a lot of developers working on apps that use DataSets as their data layer and/or are using an RDBMS that doesn’t have SQL Server’s fancy `FOR JSON` clause. Without getting into a big argument about whether those folk need to “Get with the times” and “Move everything over to X”, what’s the fastest way for them to Cloud- or Mobile-enable that data? And even if you do have POCOs for your domain-objects, there are a lot of reports in life and not every report deserves its own custom EndOfYearSalesByRegionReportRecordRow class just so you can use JSON serialization.

It’s also just a useful way and crazy easy way to mock up an service end-point. When I was exploring the GitHub Gist API I was very conscious of how my debugging might look to the GitHub service. Was I hitting the live API up too much? Will I hit a request limit? With this I can just go to a service, grab the output, and paste it and develop against that until I’m ready to hit the live service. Ease in testing is its own reward.

Conclusion

In my last post I combined top-level expressions with XML literals to create a basic VB.NET view engine for web pages on ASP.NET Core. In this post I took the same strategy but swapped out XML for JSON literals to make ASP.NET Core REST services a breeze in VB.NET. The approach has trade-offs and shines especially when dealing with one-off data sources such as files, database reports, and objects you can’t modify for serialization but yet still need to end up in a particular shape in the end, as well as testing.

So what about you?

Do you have any data you need to get out of some less that reputable places as painlessly as possible?

Does the low-ceremony abstraction I presented seem like the kind of thing that would make that easier or more attractive for you? Let me know in the comments below, or on Twitter.

Thanks for your time, your shares, and your feedback!

Regards,

-ADG

P.S. This is the last scenario 😥 in this series so my next post will be letting you know that the write-up of my design notes from exploring this idea have been posted on GitHub. Thanks for your patience!

In Scenario A I talked about the 1-line program—a single statement that prints the value of some expression to the console.

The next logical mental exercise (for me at least) is, “Gee, what if you get tired of typing Console.WriteLine all the time. Wouldn’t it be great if a program could be a single expression and the printing could all be handled auto-magically?”. I said it was a mental exercise, not a practical one 😊

Outside of making expression evaluator bots really simple that idea isn’t actually great at all, but patterns I came up with to approach it are useful for applications of other project types and many many lines of code. The Process looks something like this:

1. “What if a source file could be just a single expression?”
2. “You know what’s an expression in VB? XML!”
3. “XHTML 5 is XML”
4. <stuff>
5. This video of me demostraing a VB ASP.NET Core 2.0 MVC app with an XML literal-based “View Engine”:

Special shout-out to book author, former VB MVP, and current Microsoftie on the WinForms team, Klaus Löffelmann for doing the heavy lifting on creating the ASP.NET Core 2.0 Web API project sample I used to make this demo. It really distilled things to the bare minimum which was a huge help to me conceptually and also a great time saver!

What about “Razor”?

Here’s the thing about “Razor” (Is it a code-name, do I need quotes?). It’s an alternate view engine to ASP.NET Web Forms that aims for a particular aesthetic. That aesthetic has value but is definitely designed around C# (not dissimilar from the way Web Forms was designed around VB and Classic ASP). The Razor that is part of ASP.NET MVC 5 supports VB but the experience isn’t a bespoke VB experience. I’m pretty sure it doesn’t support VB XML literals at all (and I understand why) and that whole Code / End Code block syntax, while… well-intended does show the seams a little. And when we talk about ASP.NET Core there’s no vbhtml at all. I’m really not saying this to knock Razor at all. I think it’s cool. And as a guy who spent 5 years spelunking two parsers, I appreciate the challenges of building and maintaining a component that understands the nuances of code while the user is typing—a  problem that is even harder when the language itself is hosting another language nested in it (XML)—while also wanting to provide a great tooling experience. (I appreciate in part because I was working on Roslyn when the ASP.NET team was working on Razor and Web Matrix and they weren’t shy about telling us about the challenges 😉). And new language versions present new conflicts if new features don’t play in the way your view engine was coded to support: I mean, can you imagine what Razor would do if VB added JSON literals?

But, we (VB programmers) are in luck. Because Microsoft already owns an incredibly well-tested, well-oiled, well-maintained component that knows the ins and outs of the VB language and seamlessly transitions between VB, and XML, and interpolated strings, infinitely nested with an incredibly rich IDE experience just deeply integrated into it. It’s always maintained, it can’t fall out of sync with new features, and it’s basically free. It’s called Roslyn; we should use it!

Once again, as I did in Scenario B, I’m asking “What if we invert the problem?” and instead of getting VB into the views, we get views into the VB. Or better yet use what’s already in VB to make something idiomatic and aesthetically pleasing just for us at a comparatively much lower cost?

WWFSD—What Would F# Do?

Over the years since its introduction I’ve been continually impressed with the grace, creativity, self-reliance, and pioneering spirit with which the F# community has approached being unique members of the broader .NET community. It’s incredibly easy to assume that there’s only one way to approach programming and that it’s whatever the newest way Microsoft has released or whatever way C# is doing it because it’s intrinsically good for everyone and the best anyone can come up with for all situations (until the next thing comes out). F# is very good at remaining rooted in its own identity while looking for solutions to the same scenarios that C# or VB coders face but in a way that is complementary to and often strengthened by F#’s unique capabilities.

For example, Razor doesn’t support F# either but when I hear F# aficionados talk about web programming they aren’t talking about Razor, they’re talking about homegrown solutions like Suave and Fable and Giraffe and CloudButt and other made up names that are built with F#’s differences (read: strengths) in mind.

It is my sincere wish that we, the VB community, learn from their many examples and that one day we too have a catalogue of colorful names on a web page somewhere built by us for us. This is my opening contribution to what I hope will be an ongoing conversation.

Conclusion

I’ve still got one more scenario to post and then I’ll do the full write-up on GitHub the ins-and-outs of the proposed top-level code feature that made this video possible. Web programming is just one potentially application of it that I thought up but there’s another guy who’s been thinking on this topic a lot longer than I have, VBAndCs. I really wanted this scenario to be a surprise but VBAndCs saw it all coming in my comments section all the way back in Scenario B.

I have another planned prototype in my head that would go even further on this scenario that I hope to put out later and I’m really looking forward to seeing what awesome tailor-made experiences passionate folks in the VB-Web community like VBAndCs can build given the right language tools.

Share your feedback with me, share the video with your friends. And as always, thanks and see ya later!

Regards,

-ADG

Getting away from Console apps and Console paraphernalia, “Scenario C” is all about how top-level code can plug in to more interesting orchestrations.

Here’s a quick 5-minute video showing off top-level code forming the body of a game loop:

I really wanted to re-create the simplicity of my earliest experiments with animation and writing very primitive games in (you guessed it) Qbasic. So I pushed all of boilerplate into a base class in a library and now this one file can accomplish more just based on how the base class decides to run it; it’s pseudo-scripting. A great use of inversion-of-control in action 😊

And this same approach can be used to solve other problems too, depending on your style. Sometimes have situations where a class is dominated by one (or a few) very important methods that maintainers should focus on, particularly in derived types. Does this happen to you and if so, how do you highlight that? Do you just put a comment over it that says ' Keep this method at the top or do you put it in a separate partial file?

I really wanted to do something fun and not-console centric with this scenario. In my next scenario I’m going to expand on this approach to do something even cooler (and remote from Console apps) so look out!

Feedback welcome, please share, thanks!

Regards,

-ADG

P.S. Reminder: This is Scenario C. It’s the third of 5. I’ll post the usual GitHub issue with my writeup of all the design details/questions I ran into at a future date.

There’s a lot of excitement these days for interweaving code and rich-text in the same environment. In my last post I touched on this referencing some of the work going on with “Try .NET” and the .NET docs. Other cool approaches to this are Jupyter Notebooks and Xamarin Workbooks. In this video I combine my top-level code prototype with with a proof-of-concept Visual Studio extension I hacked together to show an alternate approach that VB could take:

Special Thanks to the folks at Marked.js for saving me from having to roll my own markdown renderer for this demo.

Finding the balance point

This approach leverages all the flexibility of the Visual Studio editor to give you a rich text experience while sacrificing absolutely none of the capabilities of a full professional IDE.

I love the experience of Notebooks/Workbooks but the trade-off of starting to build-out an experience for VB outside of VS is that you end up spending a lot of cycles rebuilding the capabilities you already have. It starts with “let just have a run-able code block embedded in a page” but the next thing is:

• But that code block should have the right syntax highlighting; can’t be just black text—that’s weird.
• And… well, semantic colorization of types would be nice too.
• Some semantic tooltips could really liven up the place…
• And wouldn’t it be nice to step through this code one line at a time?
• Wouldn’t it be nice if you could edit the code.
• Well now we need completion.
• Completion isn’t using the right keys, it doesn’t feel right because it doesn’t complete on <space> or <.> or trigger in the right contexts…
• Hmm, definitely going to want that end-construct-generation… I’m tired of typing “End” blocks.
• Probably going to want to get squiggles for syntax errors…
• Hey, do you think we could get a Roslyn analyzer running up here?
• How does a person graduate this experience out of a document and into a real-project?

Of course these are problems you can solve and have been solved but there are more challenges behind them and it all stems from digging yourself out of the hole you jump into when you start from scratch. This scenario is about inverting the problem and asking “How lightweight and rich of an experience can we get in the same Visual Studio where we’re going to be spending the vast majority of our time anyway?”

Many years ago I wrote several of the Roslyn API “Getting Started” docs. To really get Roslyn you have to have the Roslyn Syntax Visualizer running while you explore, you need to be able to inspect live data while learning. This is the kind of experience I envisioned when we I first wrote them.

Summary

I’m definitely not knocking great stuff like Notebooks/Workbooks but I can imagine rich, interactive, workbook-like experiences in VS, using amazing capabilities like inspecting data using custom debugger visualizers that would be very expensive to recreate elsewhere. So, again I’m asking “What if we invert the problem?”

Ultimately there’s a spectrum and this is just one point on it and I respect that we can end up up having more than one solution for different situations. At a minimum top-level code in VB potentially let’s both solutions share a file format. So I’d love to hear from you folks on where you draw your lines.

Let me know your thoughts the feature and this potential application of it. And please share!

Regards,

-ADG

P.S. This is Scenario B, it’s the second of 5 (though yesterday I tripped over a 6^th). I’m trying a different approach with this prototype than in the past and I’ll post the usual GitHub issue with all the design details/questions I ran into sometime after I post Scenario D.

While most of my prototypes allow you to write more (new) kinds of code this prototype is all about writing less of what’s already in the language. The idea is simple:

• You should be able to write a complete VB.NET program with exactly ONE line of code; no namespace/class/method declarations.
• You should be able to write a complete VB.NET program that’s just a sequence of executable statements in a single file, if that’s all you need.
• You should be able to declare methods and classes as needed in these simple programs in the same files without giving up the lightweight/low-ceremony syntax.
• This syntax should integrate seamlessly with the rest of the VB.NET language rather than being an alternate dialect/project type/compilation-mode.

Here’s a quick 3 and a half-minute video showing off those ideas in action:

There are benefits for VB coders at every level of experience from first-time programmers to veteran developers:

Simple programs for learning concepts and trying out ideas

A program that’s only one statement is not usually* very useful outside of the fact that for a newcomer to the language to conveys in the most succinct way the smallest (often fundamental) useful thing you can do in that language. This is why “Hello, World!” programs matter. 20 years ago when I discovered QBasic on my Windows 95 upgrade CD I didn’t know how to do any programming at all. Then I read a tutorial and in one line I knew how to display output to the user (myself). Before that line I was not a programmer and couldn’t make a computer do anything that wasn’t already installed and after that line I was a programmer because I could make my computer do that one thing.

I didn’t know anything else but I knew that one thing. And then I learned a second thing, and a third thing, but the journey of a million miles that led me to being a language designer at Microsoft started with one step and ONE concept. Not “This is an import statement, let me explain what a namespace is, here’s a class/module, don’t worry about it, oh yeah, subs, can only write code that runs in here, entry points, gotta be called Main, now let me tell you about Console.WriteLine”.

VB lost that simplicity in the jump from QuickBasic, though it has its own flavor of “Hello, World” in the Command_Click handler demo but for learning language/programming fundamentals outside of GUIs the simplicity of a bunch of statements in a single file can’t be beaten. I can’t tell you the dozens of console applications I spin up and throw away during the course of working on a project to try out ideas, approaches, algorithms, etc.

Scripts (maybe?)

And by this I don’t mean scripting engines (a la VBA) but scripts a la VBScript, PowerShell, Batch files, etc. Even if you’re not learning but just automating some task it’s convenient to be able to do so with as little ceremony as possible. But if the language supports such simple programs natively it could be as straightforward as compile-and-run. It doesn’t even have to be interpreted.

I have little VB.NET programs I’ve written over the years for all sorts of tedious little chores on my computer like re-naming and/or re-tagging all my newly downloaded MP3s that could just as easily be ‘scripts’.

There are upsides, downsides, and concerns to this, of course (like security), but clearly shell scripting languages haven’t stopped being a thing so I’d love to hear your thoughts on whether you’d prefer scripting in VB.NET to PowerShell or Bash.

Better documentation and tools for everyone

Whenever I write a blog post or an article or documentation for something there’s always a tension between writing “all the code you need to copy, paste, & run this as a complete example” and “just the code I’m talking about”. If you look at my “Exhausting List of Differences” post you’ll see that I usually opted for the former. A lot of those code snippets have Module Program : Sub Main : End Sub : End Module boiler plate in them because I wanted it to be fairly easy (and consistent) to just paste them in your IDE and go. It’s less of a win if it’s just a few statements to drop in your Main method but once you start having helper functions you’re calling or data classes you’re referencing it becomes a hassle to “copy this part at the class level, and this part inside the Main method” and with a feature like this all of that goes away in my documentation.

If you look at the docs for VB String Interpolation, for example, you can see the doc writers balancing these same concerns.

And to take it to the next step you have a tool like try.dot.net which aims to let you run code right on a documentation web page. Other great examples include sharplab.io (previously known as TryRoslyn), .NET Fiddle, and more.

I’ve seen the same issue multiple times throughout the years. I’ve seen more than one developer set out to make a IRC bot that will run some VB code but on the back end they have to do some transformation to make the code legally compile-able. That interaction becomes much simpler if the language itself naturally supports simple programs. A feature like this removes that entire step if you can literally hand those statements wholesale to the compiler like a black box and just run its output and send back the result (modulo all the security issues with doing that).

Summary

Top-level executable statements and declarations in the vanilla VB.NET language is great for documentation, education, and sets up an easier play for things like shell scripting and tools like Try .NET, SharpLab, .NET Fiddle, and the like.

This is Scenario A, it’s 1 of 5 that I’ve worked out. That’s right there are 4 more demo/posts on this one prototype and they’re different from this one so you’re going to want to pay attention.

I’m trying a different approach with this prototype than in the past because my first video was over 15 minutes and my last video was over 20 minutes long and I think it’s better both for you all and for me to break these prototype-focused posts up. As my friend Jon might say, “Ain’t nobody got time to watch a 30-minute video someone shared on Twitter” and the whole reason I make these videos is so they can be shared and viewed. It also lets me post a little more frequently and longer on a single topic without “going dark” as long to work on the next big project/video and requires a lot less editing.

Let me know your thoughts on this approach and of course on the feature itself. And, as always, Please Share!

Regards,

-ADG