I don't seem to be receiving all of the messages on this thread, which makes it a bit difficult to follow who said what. It appears from the below that somebody (Marcus? Surely not!) was grumping about OOP as an ABM implementation framework.
Agents in an ABM are (or should be*) software objects that correlate to their real-world counterparts at a level of resolution that is defined by the requirements of the problem to be solved by the simulation. Once implemented, these software agents interact with other agents in the model at a level of resolution and granularity that is again defined by the model requirements. This is how my colleagues, and in fact most other ABM developers that I know have been developing ABMs for quite a while. We have found that OO methodologies are best suited to ABM implementation, as compared to, say FORTRAN, COBOL, PL-1, Pascal, LISP, assembly language, or whatever your particular favorite procedural programming language happens to be. Whether or not you prefer C++, Java, Charm++, Lisp+Colors, Lisp+CLOS, or whatever your favorite OO development environment is was not the focus of my original claim that OO methodologies embody the essence of ABM design best practices. The point was that in order to implement in software simulation agents that are corollaries of real-world objects at some defined level of granularity, you need an object oriented software development environment. (Duh! ;-o)) Issues such as how an OO environment implements OO features, such as inheritance, method overloading, containment, data members and typing, function members, and all the other tricks of the OO trade that allow the developer to use polymorphism to create a suite of agents that can satisfy the analytical requirements of the completed ABM was intended to be the topic of some other flame war! ;-} --Doug -- Doug Roberts, RTI International [EMAIL PROTECTED] [EMAIL PROTECTED] 505-455-7333 - Office 505-670-8195 - Cell [*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. Sure, you can emulate an OO environment in C with structs and function pointers, and you can even call it an OO implementation. But it's not. And please, let's save the topic of "object-oriented FORTRAN" for its own special flame war!] On 6/1/07, Prof David West <[EMAIL PROTECTED]> wrote:
it is perhaps inappropriate to comment on a discussion before posting an introduction (as I was asked to do when I joined the list) but I cannot resist. (I will post an intro tonight.) As an unmitigated object bigot I would claim that there is nothing in agents (or aspects for that matter) that did not exist in objects as objects were supposed to be. The fact that objects were hijacked and emasculated by C++ (later Java) and data modelers (UML) explains much of the bafflement: perhaps. On Fri, 01 Jun 2007 14:05:44 -0600, "Marcus G. Daniels" <[EMAIL PROTECTED]> said: > Douglas Roberts wrote: > > I still can't help but feeling that in general, *way* too many words > > are being used to describe ABM (and IBM) methodologies. The > > underlying concept of object-oriented software design as the basis for > > ABM simulation architecture is just so straight forward and intuitive > > that I am repeatedly amazed at how people continue to make such a big, > > mysterious deal out of it. > For some reason many ABM enthusiasts feel the need to introduce basic > programming and computer science to their peers in their own peculiar > and impoverished language. > Why OOP gets embraced in particular completely baffles me and much of it > is inappropriate for modeling. (e.g. rigid inheritance) I suspect it > has to do with the need many perceive to learn and use toolkits. > > > ============================================================ > 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
============================================================ 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
