3 ms·

Underappreciated aspects of the C# compilation model: 1: file agnostic. While files provide a scope for imports, in general the compiler can’t tell the differe

Underappreciated aspects of the C# compilation model: 1: file agnostic. While files provide a scope for imports, in general the compiler can’t tell the difference between the same set of classes split across multiple files or crammed into the same file. 2: unordered - files don’t import one another, or get processed in particular sequence. The compiler takes a set of files and turns that into a set of type definitions. 2: partial types, which lets you even split a class definition between multiple files 3: regions, to let you bracket of sections within a file and organize things how you want. No ‘one class per file’ rules. No ‘references at the top of the file to every other file you need’. You can reorganize code freely, adding or combining files at will.

bbkane 3y ago
I think, by using a directory as "the module unit", Go gets similar benefits while being simpler.
- pipe01 3y ago
  If only cyclical references were possible
aragonite 3y ago
That sounds like something I really wish were available for JS development. Used to have a setup where, during development, I write all my .js files as "script files" rather than modules, all placed inside a folder, and the "build-step" is simply concatenating all .js files in that folder. All the functions in each script file are globally visible from all the other script files and there's no need to import/export anything. No one should publish code in that form, but during development it was incredibly freeing and helps me concentrate on the actual programming tasks at hand rather than getting sidetracked by trying to figure out the right way to organize the code into modules, something that (imo) I'm in a much better position to do when the programming tasks have largely been solved. It's like writing a book. The natural process is to first create substantive content in fragments and then gradually for a chapter or section structure to naturally emerge from these fragmentary bits of content. Focusing too much on 'modules' during early development is imo akin to being preoccupied with spending time deciding what chapters and sections you want your book to have before even having a substantial base of content. Unfortunately the current tooling for JS doesn't really support this workflow as well as I'd like.
jcparkyn 3y ago
C# is also much better than most languages about being able to split code into separately compilable projects with references between them, and multiple applications referencing the same shared library. Trying to do the same in TS or python (without extra tooling) is an order of magnitude harder.
- Too 3y ago
  Are you saying that editing .sln and .csproj files can be done without tooling? It’s only convenient as long as you stay in visual studio. Not that I would write C# any other way, but the comparison isn’t exactly fair. It’s very easy to create reusable libs in both TS and Python.
  - ygra 3y ago
    .csproj files are trivial to edit without tooling (the newer SDK-style projects at least; the others are merely easy). It helps to understand how MSBuild works, though. .sln files are mostly needed for Visual Studio and they are not required. Fun fact: solution files can be built by MSBuild and are converted into a normal temporary MSBuild project first for that.
  - neonsunset 3y ago
    csproj is fairly similar to cargo.toml except xml, it is easily edited by hand or CLI tooling. For sln, you just use dotnet new sln, dotnet sln add and remove commands.
  - jcparkyn 3y ago
    I really meant "without third-party monorepo tooling", but SDK-style csproj files can absolutely be edited by hand (I never use the GUI for them, even in VS). Solution files, while an abomination, are mostly optional if you're not using VS. > It’s very easy to create reusable libs in both TS and Python. I've obviously been doing something wrong then, because I've spent many cumulative hours trying to make these work and there's always compromises. Ever tried making an app with create-react-app that uses a shared lib, with reasonable support for HMR (or even just a working live reload), type hints, breakpoints, de-duplicated dependencies, and linting? As for python, is it even possible to do with a standard python install? I can't remember all the issues I ran into, but the conclusion I came to is that doing it without something like poetry (at the very least) is so much effort that it's not worth it (and let's not even think about making it cross-platform). It doesn't help that every single source on the internet seems to recommend a different approach. Compare this to C#, where there's exactly one way to add a reference to a shared library, it takes one line in a csproj file, and it works with just about every type of application out of the box. Edit: To be clear, I'm talking about locally reusable libs, not published and versioned packages.

bbkane 3y ago

I think, by using a directory as "the module unit", Go gets similar benefits while being simpler.

pipe01 3y ago
If only cyclical references were possible

aragonite 3y ago

That sounds like something I really wish were available for JS development. Used to have a setup where, during development, I write all my .js files as "script files" rather than modules, all placed inside a folder, and the "build-step" is simply concatenating all .js files in that folder. All the functions in each script file are globally visible from all the other script files and there's no need to import/export anything. No one should publish code in that form, but during development it was incredibly freeing and helps me concentrate on the actual programming tasks at hand rather than getting sidetracked by trying to figure out the right way to organize the code into modules, something that (imo) I'm in a much better position to do when the programming tasks have largely been solved. It's like writing a book. The natural process is to first create substantive content in fragments and then gradually for a chapter or section structure to naturally emerge from these fragmentary bits of content. Focusing too much on 'modules' during early development is imo akin to being preoccupied with spending time deciding what chapters and sections you want your book to have before even having a substantial base of content. Unfortunately the current tooling for JS doesn't really support this workflow as well as I'd like.

jcparkyn 3y ago

C# is also much better than most languages about being able to split code into separately compilable projects with references between them, and multiple applications referencing the same shared library. Trying to do the same in TS or python (without extra tooling) is an order of magnitude harder.

Too 3y ago
Are you saying that editing .sln and .csproj files can be done without tooling? It’s only convenient as long as you stay in visual studio. Not that I would write C# any other way, but the comparison isn’t exactly fair. It’s very easy to create reusable libs in both TS and Python.
- ygra 3y ago
  .csproj files are trivial to edit without tooling (the newer SDK-style projects at least; the others are merely easy). It helps to understand how MSBuild works, though. .sln files are mostly needed for Visual Studio and they are not required. Fun fact: solution files can be built by MSBuild and are converted into a normal temporary MSBuild project first for that.
- neonsunset 3y ago
  csproj is fairly similar to cargo.toml except xml, it is easily edited by hand or CLI tooling. For sln, you just use dotnet new sln, dotnet sln add and remove commands.
- jcparkyn 3y ago
  I really meant "without third-party monorepo tooling", but SDK-style csproj files can absolutely be edited by hand (I never use the GUI for them, even in VS). Solution files, while an abomination, are mostly optional if you're not using VS. > It’s very easy to create reusable libs in both TS and Python. I've obviously been doing something wrong then, because I've spent many cumulative hours trying to make these work and there's always compromises. Ever tried making an app with create-react-app that uses a shared lib, with reasonable support for HMR (or even just a working live reload), type hints, breakpoints, de-duplicated dependencies, and linting? As for python, is it even possible to do with a standard python install? I can't remember all the issues I ran into, but the conclusion I came to is that doing it without something like poetry (at the very least) is so much effort that it's not worth it (and let's not even think about making it cross-platform). It doesn't help that every single source on the internet seems to recommend a different approach. Compare this to C#, where there's exactly one way to add a reference to a shared library, it takes one line in a csproj file, and it works with just about every type of application out of the box. Edit: To be clear, I'm talking about locally reusable libs, not published and versioned packages.