One way to build a code-base that everyone can share is to specify interfaces to datatypes as in methods in C++ base classes. Another way is for each individual to write his/her own code, and then read everyone else's code, and then meet at coffee shops and talk on the phone to get things to work together. I am claiming that the second way is better for scientific software than the first way because scientific software is more open-ended than, say, systems software. I am claiming that specifying interfaces from the outset can lead to prematurely locking in design decisions, and that I have seen examples of this in the real world. Keep in mind that Julia is being touted as a suitable language for both the initial and the later phases of scientific software development.
In the event that Julia adds new OO or other interface-specifying features, obviously it would be possible for a team to ignore them, at least initially. But I have also seen in previous projects that there is a tendency for people (including me) to jump onto the fanciest possible solution offered by the programming language to solve a software design problem. -- Steve Vavasis On Thursday, October 22, 2015 at 12:02:21 PM UTC-4, ggggg wrote: > > What is the other option here? It seemed like with the OO/Julia way you > are complaining about you at least have working (but slow) code handling > your new polynomial type. In a case where your new type doesn't work with > "obtainCoefficient", it won't > work with any of your other code either. You would just have no working > code with your new polynomial type. How is that better? > > But the next week, someone asks whether you can handle polynomials >> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices. For >> polynomials in this format, "obtainCoefficient" is expensive and would not >> be regarded as a simple "getter" operation. If many people had already >> written functions invoking the 'obtainCoefficient' method, then you would >> be stuck. You would retrospectively realize that the obtainCoefficient >> member function was not a good idea. This example is typical of open-ended >> scientific software projects. >> >>> >>>
