Use default file

[ErikSchierboom]

Some tracks lessen the barrier for users by providing an empty implementation file, which prevents the user from having to create the file themselves. An example of such a track is the Elm track, but the Scala track is also discussing this. How do you all feel about this? I think it would indeed lower the barrier, especially if we will also be providing exercise-specifc .csproj files.

[ckhrysze]

I think it would help, I thought this was how they all worked as I've otherwise done python, elixir, and elm.

I was just coming to report on this, and to volunteer to generally make this easier for linux users such as myself. I completed the hello world exercise using dotnet core, and added nunit to a project file I created such that 'dotnet test' ran the tests. I'd like to investigate having that work for others, but I need to ramp up on both csharp and exercism a bit more first.

[ErikSchierboom]

@ckhrysze I am currently waiting on the .NET Core CLI to be finalized. Once that is released, I will be converting all exercises to run on .NET Core, including a project for each exercise that contains an empty implementation file. Thanks for the feedback!

[robkeim]

@ErikSchierboom when you say that you're waiting for the .NET Core CLI to be "finalized" what do you mean? I thought 1.0 has already been released.

[ErikSchierboom]

@robkeim Well, the .NET Core CLI has been released, but they are still preview releases (not even beta releases thus). Alongside the CLI work is the MSBuild work, which will replace the current .NET Core project.json format. This work is also not done. Once both of these are done, we will be able to do some very cool stuff such as:

• Create very minimal project (.csproj) files for each exercises, which makes it easier for users to get started.
• Have the exercises run on .NET Core, which makes the cross-platform support much better and allows us to have better instructions.
• .NET Core allows us to have people build and test the projects on the command-line.

Adding a default file to those project files (this issue) is already technically possible, but I think this would fit in better with the above rewrite.

[robkeim]

Ok that makes sense, thanks for the explanation!

[robkeim]

This was the post I was looking for (I added this comment to #183) before finding this one.

@ErikSchierboom It looks like the CLI tooling is no longer in preview... finally :)

https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes

Updated .NET Core and ASP.NET Core - No longer a preview workload. Fixed several bugs and improved usability of .NET Core and ASP.NET Core tooling. Project migration from project.json/xproj to csproj is much more reliable. The “Configure Continuous Delivery...

.NET Core tooling is now automatically included in “ASP.NET and web development” workload and an optional component in “.NET desktop development” workload in the installer. It is also available as a workload called “.NET Core cross-platform development” under “Other toolsets” section in the installer. We have fixed several bugs and usability issues for .NET Core and ASP.NET Core tooling. The csproj project format has been simplified and project migration from project.json/xproj to csproj is much more reliable.

[ErikSchierboom]

@robkeim I'm busy porting the C# exercises to Xunit (on a branch of mine). I'll then work next on creating the new .csproj files.

[robkeim]

Sounds good @ErikSchierboom!

[ErikSchierboom]

I'm working on this in the .NET Core branch.

[ErikSchierboom]

While working on this, a question arose. I am creating a minimal skeleton file for each exercise. That means the user can focus on the actual implementation, instead of the boring and repetitive creating of files. For simple exercises, I think this is a huge win. Consider the following default file for the acronym exercise:

using System;

public static class Acronym
{
    public static string Abbreviate(string phrase)
    {
        throw new NotImplementedException("Please implement this function");
    }
}

Looks clean to me, and it will let the user focus on the implementation. However, do we also want to create stubs for any required constructors? I'm leaning towards yes, but what do you feel? @balazsbotond @robkeim @jwood803 @bressain?

Would you like this:

using System;

public class Anagram
{
    public string[] Match (string[] potentialMatches)
    {
        throw new NotImplementedException("You need to implement this function.");
    }
}

or this:

using System;

public class Anagram
{
    public Anagram (string baseWord)
    {
        throw new NotImplementedException("You need to implement this function.");
    }

    public string[] Match (string[] potentialMatches)
    {
        throw new NotImplementedException("You need to implement this function.");
    }
}

Note that the tests require that specific constructor, so we could supply it instead of having users use ReSharper or Visual Studio to generate it for them.

[ErikSchierboom]

Note that for some exercises, it might make sense to do require the user to specify the constructors. An example of this is the dot-dsl exercise, for which I would create the following stub:

public class Node
{
}

public class Edge
{
}

public class Attr
{
}

public class Graph
{
}

[ErikSchierboom]

You can check my progress here: https://github.com/ErikSchierboom/xcsharp/tree/default-file

[bressain]

@ErikSchierboom I'm kind of in the "no stubs" camp. I think it's fine to include a stubbed out file for the first few exercises but after that, I feel there is value in the user creating files from scratch. Yes it's repetitive but repetition is how you learn the language and I wouldn't want to take that away from the user.

That said, I understand that decision may have already been made which is fine since I've been mostly MIA. My opinion however, is if we're going all in on stubs, let's keep it to a minimum so that we're not being too prescriptive.

[ErikSchierboom]

@bressain Thanks for chipping in! We had the same sort of discussion on the F# track. We can leave this issue open, as we can easily remove stubs if more people agree with your sentiment :)

[robkeim]

To @bressain's point, I think that we definitely need stubs for the first few exercises in order to reduce friction and on-boarding to the track.

Given the fact that we're providing the tests we're already being fairly prescriptive in terms of function composition, naming, etc so I don't feel the stubs should take out much of the "meat" of the exercises as opposed to just reducing a few lines of boilerplate code.

(Disclaimer: I'm just getting back from vacation and catching up on everything, so this thinking hasn't taken everything that's happened in the past few weeks into consideration)

[ErikSchierboom]

I understand @bressain's point, but it kinda depends on who you think is your target audience. For people completely new to C#, it might make sense to have them create the files at some point. However, for people already having some C# that want to hone their C# skills, it doesn't really bring anything to their table I feel. Also, when you get to the later exercises, you must already have some C# skills otherwise you wouldn't get there. For those people, which thus are relatively proficient, creating the stubs wouldn't be a problem, but they also wouldn't learn anything from it.

I've also done worked on several other language tracks, with some tracks providing stubs (Haskell), some providing stubs for some exercises (Java) and some not providing any stubs (F#). It is probably no surprise, but I really like the Haskell track where a stub was provided for me. The Java track at some point didn't provide me with a stub, but all I did was to use my IDE to generate the stub for me. That did not teach me anything useful, expect how to use my IDE.

So I do get the point @bressain is making, and it is a good one, only I feel that the previous points give the stubs approach the edge.

[ErikSchierboom]

With #199 merged, this issue can now be closed! 🎉