Top-Level Code Prototype: Scenario E

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”

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

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

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?

See, the Millennium Falcon in this metaphor is the JSON. Or maybe the JSON is Obi-wan. I guess the data is the droids?

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!

Top-Level Code Prototype: Scenario D

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

Top-Level Code Prototype: Scenario C

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.

Top-Level Code Prototype: Scenario B

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 6th). 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.

Top-Level Code Prototype: Scenario A

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

JSON Aficionados Wanted!

Do you spend a lot of your time either performing CRUD operations with JSON data?

Is your life an endless stream of calls to an infinite and ever growing set of end-points with unstructured amorphous blobs of key-value pairs that you have to hack into your .NET code using various techniques and workarounds?

If so, tell me if this would help:

In the video I show how a hypothetical JSON literal feature in Visual Basic (inspired by our beloved XML literals) would let you copy & paste JSON from docs and other examples, transform and customize it to your needs, and send it off to a REST service in mere minutes.

Inspect JSON easily with the ! operator

Transform JSON with embedded expressions

Accelerate using REST services by tweaking JSON straight from the docs  

VB enthusiasts have asked about this for years, and I’d really like to advance the discussion on this topic from “Wouldn’t it be cool?” to “That would change my life!” and to do that the community needs to hear from developers who are up to their keyboards in JSON all day. That could be:

  • JSON accepting/returning web services
  • JSON files produced/read by other programs
  • JSON data stored or queried from SQL Server or another database system
  • Transmitting between server code and client-side JavaScript to create dynamic web pages
  • Or something else entirely that I haven’t thought of!

If you’re someone who is about that life or even just considering it please sound off below with your thoughts. And if you’re interested in more details check out the proposal on GitHub and leave feedback there as well and as always SHARE, SHARE, SHARE!

Regards,

-ADG

P.S. This is my second language feature prototype and I’m trying to take heart feedback from my first. Feel free to give me more feedback on the format itself and how I can improve it to reach more new and existing VB users. Thanks!

(Maybe) Enhancing `For Each` loops with LINQ

Hey!

Ever been writing a For Each loop and wanted to tack on a Where, Skip, or Order By clause? Well check out this video of a prototype I wrote that lets you do just that:

But don’t just look at the video! Share! Share this post with any VB developer you can reach who might get a kick out of it. Then go to this GitHub issue and tell everybody what you think. And if you’re really excited, download the fork and play with the prototype yourself!

Why socializing prototypes matters!

Because no matter how brilliant any language designer or team of language designers is they are limited by their own experiences and habits. The most meticulously crafted designs can and have fallen apart when picked up by someone a world away with a slightly different imagination. In the best case, that feature is cut. In the worst case, the wrong feature ships. More eyes looking at it and more hands using it in practical contexts (not clinical samples) for awhile is how you go from an idea that’s cool, to a design that works, to a feature that is actually used.

I’d originally wrote about two more pages of personal experiences from my time on Roslyn of near-misses but I’ve decided to spare you all that. Just trust me—this is crazy important! I’m going to keep looking for more ways to make it easier for as many VB coders as possible to give feedback on ideas in the future, but publicly accessible prototypes and the democratizing power of YouTube is a great first step! Look forward to more videos of other prototypes in the very near future.

Regards,

-ADG

P.S. This is my first YouTube video EVER. I know, it sucks, I did everything wrong. That’s OK, I’ll get better. Feel free to leave me feedback about it!