Hi! (please bear with the length, I promise this is my last long post) * * *
@Araq, I quite agree with @Jehan's view that eventually, a reasonable developer would try to provide structural guarantees in his code and in that sense, your suggestion (which make sense in general) would seem weird and become synonymous to "oh, if that guy imports types, his code is messy". * * * @Jehan, could you elaborate a little bit on how ML-type module management would help for scientific computing because I am still not sure that I have grasped everything. * * * Now that I have read more about this, it seems that talking about encapsulation itself is not the correct term. I should have talked about implicit **guarantees**... _What are the problems when someone tries to contribute to a large code base (like Firefox, GLib, QuantumESPRESSO or OpenFOAM)?_ * First we need to clearly determine what the problem is and split it into smaller, manageable parts. * Then we need to determine what changes to make. * Then where to make the change. In that list, the first point is completely up to the developer whereas the two last ones are much more language- and structure-dependent. In small programs like most of what we have in Nim today, it is easy to build a reliable mental map of the totality of the program in a short time, this is why Nim works so well! But take any of the programs I cited above, creating such a map is impossible: our brain just can't handle it! The general solution to that is to follow Descartes' principles and split the problem (here the program) into smaller pieces. In Nim, this is currently provided by files and therefore modules. The gist of the problem that I couldn't explain clearly earlier is that modules in Nim provide no intrinsic guarantees about that splitting: in class-based OOP, I don't expect to find Bar-related methods and attributes in the class Foo; likewise, I don't expect any of the "important" Foo-related methods or attributes to be defined outside of the class. This is why I was able to identify and dump that Density class I talked about somewhere else and hack on that without ever worrying about the remaining 95% of the program! But with Nim, I don't have that: sure, if I were to use @Jehan's programs, I would be fine but most of the other scientists don't really code like that... Now, as I said, I don't care about the particular implementation as long as it provides this kind of guarantee. I don't have an extended knowledge of programming languages, so please, really please, if you have any suggestions to provide such guarantees in any form that fits well with Nim, then do.
