Added: LDM Notes for May 12th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-05-12.md

Agenda

1. Experimental attribute
2. Simple C# programs

[cheong00]

Regarding "Simple C# programs", as someone who extensively use csc.exe to compile single file example to demonstrate how to do things in C# (because the company I current working is PHP/Java + Angular, I have to compile WinForm application examples with single .CS file all typed in Notepad++), I would be grateful if library import mechanism can be enhanced say, by introduce something similar to require() in typescript. (directives or even attributes like those for C API import are okay too)

[cartermp]

You can follow along here for more info, that is absolutely under consideration here: dotnet/designs#213

[MgSam]

Today, the contents of C# files are very intentionally independent of their locations on disk: file structure is handled by the project file, and project structure is handled by using directives and namespace declarations. #r to local NuGet packages or #load to add other .cs files would blur the line here.

As someone who uses TypeScript in large Angular projects on a regular basis, I can say having spaghetti-code file paths from one file to another is an absolute nightmare. The IDE tries to make the experience better by automatically filling out file paths for imports, but at the end of the day when the IDE fails (which happens quite often), you're left with writing them by hand and having to remember files' relative locations to one another. Also on refactoring the location or name of a file it's a coin flip as to whether you will be left with broken dependencies everywhere.

I absolutely do not want to see this experience come to any variant C#. Project files are vastly superior in every respect. Such a system is not "simpler". It's just inferior.

I'll also point out that according to TIOBE, the top 5 languages currently (May 2021) are C, Python, Java, C++, and C#, respectively. There is no adoption problem with C#. The continued push to make "beginner" scenarios easier in order to address a non-existent problem seems like an enormous waste of time and unnecessary added complexity to the language.

[CyrusNajmabadi]

The continued push to make "beginner" scenarios easier

This is not about a beginner scenario. The desire to not require so much complexity happens with bog standard developer scenarios across the board :)

[cartermp]

Yes, although a core audience are beginners, having less stuff to manage is something I generally think is a good thing when you're not doing "typical" larger application development. For example, a simple utility program written in Go is a single file, and that's awesome. There's no good reason (in my mind, at least) for that to remain untrue for C# as well.

[huoyaoyuan]

I'm actively using C# for data science. The current desire of simple C# programs are:

There are many standalone tasks. I had either created a project for each task, or wrote multiple Mains and swicth when executing.

There are also shared stuff between them. I don't want to organize like scripting language. Putting them into a regular library project is OK. Then the simple entry points should be able to reference the library project, and of course nuget packages.

It's common to put the code beside data and use relative path to access them. However, the starting directory of normal project is tighted with SDK configurations that I'm explicitly avoiding to depend on. Using startup configuration is possible but too heavy, and it may only work for IDE. The ability to fix pwd with file location is important for me.

[TonyValenti]

Maybe it is just me, but I feel like between VSCode and VSExpress there is no reason someone should not be using VS (or at least some IDE) to write their C# code.... Especially when selecting New > Console Project creates all the necessary "ceremony".

How many man hours are you going to spend getting rid of "int main"?