Robert Howard wrote: > The impediments (the constraints and rules) of a programming language are > there deliberately by design. They are the benefits. Among many other > things, OO deliberately impedes a programmer from looking into the scope of > objects unless specifically declared. This may be seen as an impediment to > the programmer, who might just love to be able to bang anything out on the > keyboard, but it is marketed as a long-term benefit to other programmers who > later have to read the code. > Sorry, I thought it was clear from context that I was talking about `as applied to modeling', and this notion of search instead of how to engineer something with an given goal. It's not implied that the code will be shared with anyone. Often a paper describing the crucial aspects of the simulation would be published and the code would be discarded or collect bitrot.
It's an impediment if the language or framework or methodology being used forces a modeler commit to things they do not know, especially if those commitments are not obvious and not benign assumptions. I realize that starting from a blank slate with a general purpose (let's say OO) language also doesn't ensure such commitments will not be made, because are some basic mechanics needed to do simulations at all, and there are good ways to implement them and more bad ways. Starting from scratch, the bias is toward whatever is easy, not to facilities that are best suited to understand the problem. Starting from a framework, the bias is toward whatever templates happen to do, and whatever the conventional wisdom suggests. Tradeoffs. ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
