With functions it's worse. In a flat namespace you will inevitably run into a problem of two people coming up with the same name.
With functions it's worse. In a flat namespace you will inevitably run into a problem of two people coming up with the same name.
IMO python and python3 is a very welcome feature not a negative side effect of no namespaces. At call time it's super explicit so you know exactly what version you're using.
But in most module driven programming languages you might import the foo function at the top of your file and then use foo in 5 different places within that file. However, you spend 99% of your time working with the code in the file not glancing at imports, so now you're left wondering not only where foo is coming from, but who provided foo. Is it from the standard library, your own code base or a third party author? Suddenly you need to keep all of this in your head and it sucks.
Phoenix (a web framework for Elixir) has been taking steps to remove a lot of loose function imports so you know what module they are coming from at call time, but that's because Elixir as a language has modules. But even still, explicitness where you're using it is so much better in the long run for maintenance, even if it involves typing a few more characters.
As always with dynamic things and editing code for them, this will be more difficult to get right when imports are dynamic.
That's a versioning issue, that would happen with namespaces too. You'll have to disambiguate somehow and if a version number is the natural way, then that's the natural way regardless of if a single name or namespaced.
Keeping the next incompatible version as a separate thing (eg python vs python3, instead of continuing python but with semvers saying that 3.0 breaks 2.x compatibility) is actually a good idea. It leads to fragmentation, sure, but it makes dealing with the different versions easier IMHO and incompatible versions may as well be totally different things anyway.
> With functions it's worse. In a flat namespace you will inevitably run into a problem of two people coming up with the same name.
Yes, completely agree!
Microsoft COM would like a word. {20D04FE0-3AEA-1069-A2D8-08002B30309D}
I'm not even sure that reinventing COM would be a bad idea - you can definitely do some great things with it, and the specific implementation details of COM are crufty. But doing so deliberately rather than accidentally would be better, with a review of benefits and problems of COM approaches.
As for the community, maybe not on SV, but there are plenty of Microsoft communities and meeting groups.
https://developer.apple.com/documentation/corefoundation/cfp...