Re: [Swarm-Modelling] Announce: metaABM 1.0.0

[Marcus G. Daniels]

Miles T. Parker wrote:
> The economic drivers were  all about who could take the basic 
> representation and stretch it as far as it could go. That in turn 
> meant that companies began to do all kinds of crazy things..
But it's not actually possible to write general purpose programs in 
SQL.   It's a language that addresses query.
Worse, the interface to languages that _are_ general purpose is not 
standard -- client libraries vary from vendor to vendor.  For that 
matter SQL _itself_ varies a lot across vendors.  Most of the time if 
you just take one non-trivial SQL-based application and plug in another 
RDBMS, the application will not work, unless there is an intermediate 
library (e.g. JDBC) is known to support both.  In practice, a lot of 
typeless strings get passed around and SQL syntax goes unchecked, even 
though the programs embedding those strings may be otherwise correct.  
Further, SQL fails to specify (or infer) expected access patterns.  The 
same SQL could have terrible performance on a row-oriented database 
system and fantastic performance on a column-oriented database intended 
for data mining.    RDBMs don't go far to morph representations to fit 
queries, they fit queries to representations.   [And, analogously, have 
we found the right representations for agent models?]

Anyway, this is not to argue that inventing or evolving declarative 
languages isn't a useful goal.  I just think that "..a common broker 
that opens up all sorts of possibilities for collaboration on either 
end" does not by itself mean that scientific progress will occur.   With 
SQL, what it meant was that Oracle occurred.   After using db4o 
(http://www.db4o.com) for a while, or LINQ, I kind wish SQL wasn't the 
popular way to do query! 

Marcus