4 ms·

A language where every definition is global is the worst starting point imaginable. Of course, solutions to that will remain severely lacking. Prefixed variable

A language where every definition is global is the worst starting point imaginable. Of course, solutions to that will remain severely lacking. Prefixed variables as you propose were abandoned for good reason. Perhaps give Rust or Python, maybe Go a spin, and see how they do namespaces, imports and such. I find that mostly sane and readable, as they retain the full chain of custody (you can always trace where a symbol comes from by its qualification or import statement, unlike in less sane ecosystems such as C/C++/C#/Java, and apparently the insane version PHP uses).

neonsunset 2y ago
You must have not used C# (or even Java in better conditions) in recent years to legitimately suggest picking Go or, worse, Python over them.
- alexanderchr 2y ago
  Modern C# is a lovely language overall but I think OP talked about the module system where the more explicit approach of Python is arguably better. When dealing with C#, if you’re browsing code un anything less than a IDE it can be really hard to find where a symbol comes from. And that is if the author was nice enough to use one folder per namespace, otherwise it becomes a nightmare.
  - neonsunset 2y ago
    In case of external references, most of the time, you do not need to browse the source files - that's something you reach for if inline documentation and type system are insufficient. Arguably much more of an issue in dynamically typed languages, yes. Although even source browsing is now easy - you just press F12, and packages come with sourcelink integrated automatically (previously you had to rely on IDE to resolve symbols or decompile it from IL (readable but not perfect, Rider did and still does it really well)). Navigating the solution itself does not differ significantly from Rust and its crate system. People usually structure the code by projects and folders, sometimes aggregating multiple types in a file (because you don't need a separate file per a couple of 4 line class declarations) sometimes not but I generally find the structure way more browsable than e.g. what a typical TypeScript project looks like. The regular symbol navigation rules apply - F12, Shift+F12 and friends.
  - diarrhea 2y ago
    Exactly. In Rust, Python and Go you can trace every symbol back to its source by just reading source code. `cat file` would suffice. In C#, that’s impossible by design, as you say. C# imports work like wildcard imports in Rust and Python, which are wildly frowned upon for very good reason (except for specific cases like preludes in Rust).

neonsunset 2y ago

You must have not used C# (or even Java in better conditions) in recent years to legitimately suggest picking Go or, worse, Python over them.

alexanderchr 2y ago
Modern C# is a lovely language overall but I think OP talked about the module system where the more explicit approach of Python is arguably better. When dealing with C#, if you’re browsing code un anything less than a IDE it can be really hard to find where a symbol comes from. And that is if the author was nice enough to use one folder per namespace, otherwise it becomes a nightmare.
- neonsunset 2y ago
  In case of external references, most of the time, you do not need to browse the source files - that's something you reach for if inline documentation and type system are insufficient. Arguably much more of an issue in dynamically typed languages, yes. Although even source browsing is now easy - you just press F12, and packages come with sourcelink integrated automatically (previously you had to rely on IDE to resolve symbols or decompile it from IL (readable but not perfect, Rider did and still does it really well)). Navigating the solution itself does not differ significantly from Rust and its crate system. People usually structure the code by projects and folders, sometimes aggregating multiple types in a file (because you don't need a separate file per a couple of 4 line class declarations) sometimes not but I generally find the structure way more browsable than e.g. what a typical TypeScript project looks like. The regular symbol navigation rules apply - F12, Shift+F12 and friends.
- diarrhea 2y ago
  Exactly. In Rust, Python and Go you can trace every symbol back to its source by just reading source code. `cat file` would suffice. In C#, that’s impossible by design, as you say. C# imports work like wildcard imports in Rust and Python, which are wildly frowned upon for very good reason (except for specific cases like preludes in Rust).