Adding a step between online dotnet try and dotnet new

[ChrisKlug]

I had a conversation yesterday with @BillWagner regarding the ability to maybe add a step between the "try dotnet" online and dotnet new.

During some conversations with people regarding the perception of dotnet, there has been a few comments about Node making it so easy to get started, and I kind of agree. With node, you install node, create a js file, write some JavaScript and then run node <filename>. Just as we used to be able to do in early Project K days. I know that dotnet new is pretty much as simple today, and that it doesn't add a lot of things, but if you are new to dotnet, the csproj file can feel a little weird if you don't know what it is doing. In "try dotnet" that is kept from you nicely. But I do believe that people would like to try the same things locally. Either from the start, or once you have tried the online stuff.

To me, it seems like it shouldn't be that hard to add some defaults to dotnet allowing you to do something like dotnet run <filename>. Basically inferring a basic csproj file with standard settings to make it a console app and make it run. It would make it VERY easy to get started after the online stuff. I don't think it needs to support anything like adding packages and stuff. It is just for that VERY early stuff to maybe write some quick code to do console read and write. If you then want to add NuGet packages etc, there could be a command for generating the csproj file for you so that you can take your projects from a simple thing to something more complete.

It's just an idea to make it as easy and simple to get going with dotnet as JavaScript or node.

[BillWagner]

ping @LadyNaggaga What are your thoughts on this idea?

[jonsequitur]

csi and fsi have the ability to do this with .csx and .fsx files respectively, but the differences between the scripting and non-scripting variants of C# and F# make this less than ideal for people learning .NET. Closing this gap (for C#, which is much larger than it is for F#) is the goal of these proposals:

dotnet/csharplang#3117
dotnet/csharplang#2765

More info:

https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/fsharp-interactive/
https://docs.microsoft.com/en-us/archive/msdn-magazine/2016/january/essential-net-csharp-scripting

[ChrisKlug]

Compiling it like that does not really seem like making it easier for a new developer though. The idea was to get A VERY low bat for trying out dotnet, with the ability to grow. CSI and manual compile is available, and works technically, but it doesn't really fit the bill in my opinion

[genlu]

csi and fsi have the ability to do this with .csx and .fsx files respectively

If using a slight different dialect of C# isn't a problem, then existing dotnet-script global tool would be another choice, it makes it easy to run csx via dotnet CLI and also supports things like nuget, which is lacking in csi.

[ChrisKlug]

The problem to me in this case is that it is a slightly different dialect. And it is not the same tools that the new developer will work on going forward

[tmat]

@ChrisKlug What specific differences pose a problem? I agree VS tooling for .csx is lacking. VS Code is decent afaik.

Agree with @genlu. When learning C# one can start with .csx and dotnet-script. They don't need to know about C# proper initially at all. Later on in the learning process the transition to C# with projects (SDK projects that is) is not hard to explain.

[ChrisKlug]

If they are going through Try.NET they are aiming for dotnet. Not a script version. Even if it can do the same things, it is not the same till that they are trying to learn in my opinion. It would be "oh, I have tried this, and learnt c#, but now I have to switch to something new again. I just switched from my browser". Why another step sideways while learning. I think it is confusing for new developers... The goal was to lower the bar when entering the dotnet zone for new developers

[LadyNaggaga]

Hi @ChrisKlug I agree that the gap between online and dotnet new is HUGE and overwhelming.
The closet bridge between Try .NET and dotnet new we have right now is dotnet try global tool here is a look at the project https://github.com/dotnet/try-samples with some samples. In this experience we wanted to keep the user with an experience similar to what they had in the browser but running locally on their machine.

However, this still has some major gaps in the on boarding experience. In an ideal world the user experience for new developers would as follows
Step 1 : Start Online

• User runs through tutorials online
• Once the online portion is complete they click a button that does the following: download compatible SDK , install dotnet try, grab the offline samples (ideally the user would have picked this prior), launch the browser in offline mode

Step 2: Offline with dotnet try global tool

• User continues learning offline but no editor or IDE required. If you are familiar with the dotnet try local experience, you know we use your browser as editor.

Step 3: Transition to VS Code

• Once the user is confident / out grown step 2 then can click on an open in VSCode button that open their code in editor.
  Now, I don't know if this solves everything but is one of the possible "grow-up" stories.

[jonsequitur]

A key point about dotnet try is that it works with ordinary project files and source files. The browser-based editor is a focused view into those files that hides the broader context (whatever that might be, whether .csproj or packages or classes) until you're ready to look at it. But you can always work in that project in Visual Studio, VS Code, etc.

So I wonder if a dotnet-try feature that looks at a file, optionally inlines it into some sort of template, and runs it might be interesting. The template can then define the context but you don't have to learn how the context works immediately.

Air code:

Given a file, myprogram.cs:

static class Program
{
    public static void Main()
    {
          Console.WriteLine("Hello world!");
    }
}

I could run it like this:

> dotnet try run myprogram.cs

Something like this could also work to hide some context:

Console.WriteLine("Hello world!");

> dotnet try run console myprogram.cs

This would inline the contents of the file into a template project and run it, leaving the complete project on disk for further exploration.

Thoughts?

@KathleenDollard

[tmat]

@ChrisKlug I see. Good point about Try.NET. I was thinking about starting from e.g. Jupyter notebooks.

As @jonsequitur points out the following would help converge:
dotnet/csharplang#3117
dotnet/csharplang#2765

[ChrisKlug]

@jonsequitur that is pretty much exactly what I was thinking would be a good experience. It allows you to transition from the web, to a local environment without introducing something new except running the cli tool. And then once you are comfortable with that, you can add a csproj and carry on from that... Just a thought. But as a trainer/teacher, it makes sense to me too let people do it in steps...

[tmat]

I think it depends on what do you want to teach. If you want to teach language basics and algorithms then I think scripting is great to start with. I don't think you need Try.NET scaffolding an app for that. Perhaps Try.NET should also provide scripting environment like Jupyter notebooks do.

If you teach some frameworks (ASP.NET, WPF, etc.) then the Try.NET approach is more appropriate than scripting.

[tmat]

@jonsequitur I don't know if it makes sense to do this on this level. Once we implement top-level statements in C# proper then this won't be necessary. There will be no scaffolding necessary for simple console apps.

[jonsequitur]

@tmat Agreed for simple cases. For documentation and learning, which is Try .NET's focus, typically there's scaffolding needed to hide any code that's not 100% relevant to the explanatory text.

We've also discussed merging this style of code excerpting with the flexible visualizations that Jupyter provides, because for example if you want to teach someone how to use an image manipulation library, you're going to want to display images.

[tmat]

@jonsequitur Definitely agree that docs might need scaffolding and Try.NET is doing great job there.
I'm just saying that those kinds of docs that need such scaffolding are unlikely to be a teaching material for basic C# programming (language + algorithms), or for subjects like ML. Jupyter experience is much better then docs for ML learning, imo.

[jmarolf]

I think the issue is that our "getting started experience" in visual studio asks you too many questions:

• what runtime do you want to target? (Framework / Core)
• which version?
• is this a console app? web app? class library?

All of these questions are asked implicitly in dotnet new as well.

I would argue that a person new to coding has no idea what answers to give for any of these. Even an experienced programmer who is new to .NET will likely be tripped up by them.

The advantage that I see in the .NET try experience is that all of these questions are differed. I would love to build an experience where all of this was a smooth on ramp:

• we just create a script file that you edit
• when you ask to debug we ask if you want to create a console app etc.

[tmat]

when you ask to debug we ask if you want to create a console app etc.

I don't think that's even necessary. You should be able get full debugging experience in .csx file right away.