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.

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”:

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.

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:

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.

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!