It is very nice to exchange thoughts with mathematicians. If classes, instances, types, inheritance, polymorphism and many other things in OOP were derived from concepts in mathematics then there should be no contradiction between scientific computing and OOP. It is just matter of correct interpretation to relate mathematical model to programming model.
On Thursday, October 22, 2015 at 1:00:36 PM UTC-7, vav...@uwaterloo.ca wrote: > > 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. >>> >>>> >>>>
