I’ve been learning to love PHP every day for a little over a month now. Not that one—gotcha! No, I mean I’ve been attending a Partial Hospitalization Program. So 5 days a week for 5 hours a day I’ve been at a facility with a team of mental health providers (therapists/social workers, psychiatrists, nurses, etc.) doing everything from finding me a new medication regiment for my depression and anxiety to regular individual therapy sessions as well as group therapy up to 3 times per day.

If that sounds intense, that’s because it is. Once again, I find myself on a mental health-related medical leave from work. This time I’ve taken 12-weeks of protected time under the 1993 Family and Medical Leave Act to try to finally get some treatment for various conditions mental and physical that I really wasn’t able to deal with last year in 2020 the way that I wanted to. As literally everyone on the planet knows, the entire healthcare infrastructure of… Earth was overloaded throughout 2020 and the mental health component was no exception. At times I had one or two month waits just for a single visit with a therapist and now I’m almost living with a whole crew of them.

I’ve actually recently transitioned out of PHP and have just started what’s known as IOP or the Intensive Outpatient Program. It’s just a truncated form of the same program as PHP, I just leave 2 hours earlier and will eventually transition down to 3 or fewer days of program per week as I try to transition back into “normal” life.

For a minute I wasn’t sure why I decided to write this other than simply as an update for the small number of folks on the planet who might take an interest but, earlier this year I was reminded by a very good friend that my talking about mental health has made it a little easier for other people dealing with struggles in their own lives or their families beyond anything particular to me. And that’s a second great reason to share.

I’m not blaming this all on last year, though last year was stressful for many ambient reasons. There were also family issues not directly related to the global situation (and some were) on top of the same challenges I struggled with in 2019… and 2018…. and 2017… and 2016… and you get the picture. I’m a little more positive now because I have the experience of taking a leave from Microsoft for 2 months in the spring of 2017. I know what to expect and what to avoid or embrace more fully.

One thing I thought I was prepared for but clearly am not, is fighting with insurance companies. I thought I was ready for them this time but nope. Actually, this whole last two years has been very educational about the horrors and intricacies of the health provider-insurance complex. It might be fun for me to engage as a software development if I weren’t an often barely functional patient just seeking help. It turns out that someone with a dangerously pessimistic world view and a constant sense of impending doom, failure, rejection, opposition, judgement, and punishment isn’t the person to take phone calls from an angry bureaucrat and they should probably appoint someone to advocate for disabled persons like myself in these situations. But I digress.

I guess my midyear update is this: I’ve taken some body-blows but I’m in treatment, baby-stepping back to the things in life I love. Whoever and wherever you, if you or someone you know is or has been on the ropes lately (and I think that describes a lot of us) I hope you/they have/can find the resources needed to get back to what you love. We all need to get back to more love.

On that note, my next post will be on enthusiasm.

Warmest regards,

-ADG

TRIGGER WARNING: This is a post that includes discussion of mental health struggles, including thoughts of self-harm. I’m fine now but there’s no need to read this post if it might upset you.

I’d planned to post this much earlier in the month, but I guess it’s become a tradition to give an update on myself and my plans on or about the 25^th of January. I’m trying to get accustomed to talking about myself on this blog (in addition to VB). After all, I am the eponymous topic of the domain name, but I’ve usually avoided in favor of posting one-offs in gists and stuff. There are reasons for that I’ll explain one day but I’ve rethought it and decided to open up a little bit more. While I know most people follow me to read about VB (and I still have oodles to say on that topic), I think it helps to have an outlet for my personal thoughts as well.

I’m always thinking and so of course I’ve been thinking a lot since my last post, though not as much as you might think, and certainly not as much as saying so might imply giving how long it’s been. I could have written this much sooner but against the backdrop of a world in chaos in so many dimensions it never felt like the right thing to be talking about. Economic freefall. Mass quarantine. Tens of thousands sick and worse. Brutality, protest, civil unrest, hope, and uncomfortable conversations. I could share some sensational imagery of smoke plumes over my own home community here on the South Side of Chicago (we’re ok, btw) but you get the idea. Maybe another day.

Today (before the Murder Hornets return), I want to talk about, ironically, a more lighthearted topic dear to my heart: VB. Believe it or not my last words on this subject were actually toned down about 10% emotionally than in the first drafts but in hindsight they were still maybe 10-15% more emotional than I would have liked, in hindsight. Maybe I’ll edit them a little one day. But I stand by my words. That we, the VB community, are in a situation that is unnecessary, inappropriate, poorly handled, disloyal, wasteful, and in contrary to the stated values I would like to believe in, expect, and see. And having said them, they’re said, and I’m not going to say them again really. I’m going to shift to what I think will/should/can happen next.

In 2014 Microsoft open-sourced Visual Basic .NET as part of the “Roslyn” project. For its entire life before that VB (both Classic and .NET) had been a closed-source proprietary language. And in a timeframe where standardized languages and open source languages were establishing themselves as the new normal, VB caught a lot of flack for that. But regardless, it was a product. The owned product of one company: Microsoft. Some people buy it, some people don’t. It sucks if they stop making Twinkies but Twinkies are a product produced by Hostess.

But, when Microsoft “hit the button” on pushing that code to CodePlex (later moved to GitHub) with an Apache license they fundamentally changed the nature of what Visual Basic .NET was. It is now an open source programming language. Not a product in a portfolio.

And every community of an open source programming language, by definition, has a fundamental right to self-determination. That’s the whole point. It’s implicit in the right to fork that the community has an interest in shared ownership with the project leaders (not owners). It’s got a whole “consent of the governed” vibe to it. It’s why they’re called benevolent dictators. It’s why Don Syme styles himself nobly as a contributor, not a puppet-master. If there isn’t a right to self-determination what does it even mean to be open?

I’d originally planned to write on this particular topic in response to increasing outreach to me personally, through my blog and other places, unsolicited, and independently from multiple community members expressing concerns about the health of VB.NET but also their passionate and heartfelt desire and commitment to contributing to its success. I too had been thinking about this, spurred on by comments on the vblang repo, social communities like forums, Facebook and Twitter, but also my own experiences and limitations. Due to recent announcements I’ve had to edit this post somewhat but fundamentally it still makes the point I always wanted to make; what’s changed is the context. It’s not a hastily written result of a last-minute brainstorming exercise or an emotional outburst but the culmination of my thoughts and observations over the last 10 years, 8 of which were spent working on VB.NET at Microsoft. It’s not at all my complete take on the current state of affairs but it is critical for the entire VB.NET community and everyone else watching to be armed with this context when discussing or socializing about anything else, so, I’ll try to provide that first and roll out any further points separately.

Time and time again I see the discussion of Microsoft’s level of investment in VB.NET framed around the same faulty assumption: it’s just too darned expensive and impractical for Microsoft to support two .NET languages (ignoring the fact that they actually make three); it would take an army of developers and content writers at great expense nearly duplicating all effort across the ecosystem at worst or perhaps 10-30% of the (Developer Tools) division resources at best. Today I want to put that misconception to rest.

At last, the final video in this series on pattern-based XML literals. That culmination of all my machinations! Last time I showed you all some example web controls—classes that know how to render their behavior using the standard web primitives of HTML, CSS, and JavaScript. The next logical conclusion is knowing how to render VB.NET itself to JavaScript. Check out this video as I run through three examples.

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.

This is my third post in this series about pattern-based XML literals. In my last post I showed how you could apply the concept to the Xamarin.Forms library via extension methods to build a cross-platform mobile app in VB using what are essentially “XAML literals” to describe your UI. In this post I’m revisiting the web and showing how someone could use the exact same pattern to not only make a dynamic ASP.NET Core MVC app but how to do so while reducing code by 50-80% using one classic idea!:

Yep, web controls. I know. But these aren’t like the ASP.NET WebForms web controls. There’s no view state or post-backs here; it’s still all MVC. These controls just know how to render themselves and that counts for a lot!. And, as I said earlier, this is the same XML-pattern at the language level that I used in my Xamarin video, the only thing that’s changed is the types that are being constructed (and they were built with the pattern in mind so no need for extension methods). Also, I temporarily merged in my top-level code prototype to get back that sweet full-file top-level XML expression experience! I didn’t change the pattern any, which is a good sign.

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.

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.