In implementations of the Scheme programming language (R6RS standard) I can import a module as follows:(import (abc def xyz))The system will try to look for a file $DIR/abc/def/xyz.sls where $DIR is some directory where you keep your Scheme modules. xyz.sls is the source code for the module and it is compiled on the fly if necessary.The Ruby, Python, and Perl module systems are similar in this respect.C# on the other hand is a little more involved. First, you have dll files that you must reference on a per project basis. You must reference each one explicitly. This is more involved than say, dropping dll files in a directory and having C# pick them up by name. Second, There isn't a one-to-one naming correspondence between the dll filename, and the namespaces offered by the dll. I can appreciate this flexibility, but it can also get out of hand (and has).To make this concrete, it would be nice if, when I say this using abc.def.xyz;, C# would try to find a file abc/def/xyz.dll, in some directory that C# knows to look in (configurable on a per project basis).I find the Ruby, Python, Perl, Scheme way of handling modules more elegant. It seems that emerging languages tend to go with the simpler design.Why does the .NET/C# world does things in this way, with an extra level of indirection?
Why do .NET modules separate module file names from namespaces?
c#;programming languages;language design;modules;scheme
The following annotation in the Framework Design Guidelines Section 3.3. Names of Assemblies and Dlls offers insight into why namespaces and assemblies are separate.BRAD ABRAMS Early in the design of the CLR we decided to seperate the  developer view of the platform (namespaces) from the packaging and  deployment view of the platform (assemblies). This separation allows  each to be optimized independently based on its own criteria. For  example, we are free to factor namespaces to group types that are  functionally related (e.g., all the I/O stuff in System.IO) while the  assemblies can be factored for performance (load time), deployment,  servicing, or versioning reasons.