I agree. OO is a better modeling tool for ABMs. OO gives us something that structured programming (SP) does notmore constraints!
SP gives us something that machine language (ML) does notmore constraints! With ML, we can jump around all over the place, ignoring stack, types, and other rules. Its spaghetti city! SP constrains jumps to WHILE, FOR, and IF statements. But SP allows lots of global variables and functions that are disconnected from their types. OO constrains scope far more, and insists that functions (i.e. methods) are connected to their types. In fact, OO compilers force the subject (the main object of interest) to be the first parameter in a calling convention, and then hides that fact from the programmer. The code becomes far more readable and easier for a reader to get the authors idea. The more good constraints (or boundaries) we adopt and practice in our lives, which require wisdom and self discipline, the easier it becomes to formally analyze our inventions and communicate them to others for peer review. Robert Howard Phoenix, Arizona _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas Roberts Sent: Monday, June 04, 2007 8:59 AM To: The Friday Morning Applied Complexity Coffee Group Subject: Re: [FRIAM] Fwd: ABM Why use OO methodologies to implement an application that is inherently object-based? For the same reason you don't use assembly language to write business applications: it would be bad computer science. You could write an ABM in any language, including assembly, but why in the world would you want to do that? This is not confusing the agent based design with its implementation. Rather, it is recognizing the characteristics of the design and picking an implementation environment that makes sense. Also note that I never suggested which OO languages should be used -- that choice depends on the implementation requirements for the project. As a side note, it is interesting to observe the growth in usage of higher-level languages for implementing ABMs in the HPC environment. We are currently investigating with The MathWorks the use of MATLAB's OO capabilities and their Distributed Computing Toolkit (DCT) to implement distributed ABMs on one of our Linux clusters... --Doug -- Doug Roberts, RTI International [EMAIL PROTECTED] [EMAIL PROTECTED] 505-455-7333 - Office 505-670-8195 - Cell On 6/4/07, Robert Holmes <[EMAIL PROTECTED]> wrote: On 6/2/07, Douglas Roberts <[EMAIL PROTECTED] > wrote: <snip> [*Footnote from the (or should be) above: I know people who have written applications with no object-oriented technologies at all, using FORTRAN or C, (or worse, purely procedural Java) and who claim to have developed an ABM. I contend, that while they may have developed a really neato simulation, it isn't an ABM. Where are the agents? Rows of an array? Elements of a struct? An array of structs? I really don't think so. Why? Logically that position doesn't make sense - it seems to confuse the model with the implementation of the model. For example, Epstein & Axtell's Sugarscape model is an ABM. If I code it up, does it only remain an ABM if I code in C++? Does the Sugarscape model suddenly stop being an ABM if I code it in FORTRAN? It might be easier to code in one type of language rather than the other, but that's not the point. ABM-ness is a property of the model, not the code. Robert ============================================================ 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
============================================================ 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
