All --
Apropos some of this, today I found myself going back and forth
between the FRIAM discussion and this review/analysis of what's new in
Mac OSX Snow Leopard . . .
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/8
tom
On Sep 7, 2009, at 7:14 PM, Birchard Hayes wrote:
Doug,
True, but now we have boatloads of RAM to fill - he he he.
Garbage collection remains a real problem whenever it is included in
a language implementation. I've been working in C#/.NET lately and
I would venture to say that there is as much "bookkeeping" involved
as there was with pointers and explicit destructors; only now, one
must learn an entirely new set of rule and MS generated foibles.
I wonder if what Russ really wants is an architecture of abstract
classes that use a wide variety of interfaces and concrete classes
to provide the palette of functions, i.e. an aggregate of
abstractions, to provide enough variability in behavior at runtime.
That could be done in C++ (STL) with Policy Based Templates and a
few other patterns; lot's of heavy lifting though.
-Birch
--
"When I am working on a problem,
I never think about beauty but when I have finished,
if the solution is not beautiful, I know it is wrong."
- Buckminster
Fuller
**** Use of advanced messaging technology does not imply ****
***** an endorsement of western industrial civilization *****
On Sep 7, 2009, at 6:41 PM, Douglas Roberts wrote:
Birch,
Written like a true computer scientist. I lived in a LISP world
for a happy period between, say '85 - '90.
But then the real-world encroached, and C++ began to become the
only realistic way to implement large ABMS of complex systems.
LISP was nice, but the virtual machine and garbage collection made
it a non-player in the modern HPC computing arena.
--Doug
On Mon, Sep 7, 2009 at 6:33 PM, Birchard Hayes <[email protected]>
wrote:
Okay Russ,
There are several options to chose from, depending on just how
adaptive you'd like the functionality to be.
LISP (Scheme, et alia): Allows for partial instantiation or
"currying." This mechanism allows your program to build functions
out of little pieces of text and then call _eval()_ on them when
completed. LISP uses a list for a generic structure but does not
infer type until you use something. Thus you could have a
collection of objects that were all completely different with
functionality created on the fly.
Javascript: Which, it turns out is a functional language; makes
functions first class objects and allows appending objects or
replacing their methods at run-time. I believe there is a native
"Collection" structure but one could be written if there is not.
Javascript also has an _eval()_ function, so partial instantiation
is possible.
Java (and, to an extent, C++): Allow for Collections of
heterogeneous objects, although the language is strongly typed and
will try to dissuade the programmer from being too abstract. The
smoothest way to apply different behavior is through interfaces,
keeping in mind that each class can implement the interface however
it chooses. The drawback here is that the interfaces must be
concrete at compile time and I don't know of an easy way to modify
them at runtime (I'm sure that it can be done but requires more
work than the other two options.) The STL has _functors_,
generally for comparison but could be extended, which can be called
on arbitrary classes iffi those classes provide the requisite
methods the functor needs. One would iterate over a Collection and
apply the functor to each object, or each pair. However, even with
cool stuff like Policy Based Templates (LOKI Libraries,
Alexandrescu et al.) I think that compile time type checking will
make things less flexible than you desire.) I haven't looked for
functors in Java, but I imagine they are there or could be
created. Additionally, Java has lent itself to the "new" paradigm
of _Aspect Oriented Programming_ which I have not played with very
much, but I understand that functionality can be cross-cut across
classes and assembled at runtime but I would think that it would
still be pretty strongly typed.
IMHO, LISP and its bretheren fit what you seek although Javascript
potentially offers fertile ground and may be easier to integrate
with Java.
As for a single term to describe this, I still like Data Structure
but that's probably being purist and I could get behind active
structure.
-Birch
--
"Humanity is acquiring all the right technology for all the wrong
reasons."
~R. Buckminster Fuller
**** Use of advanced messaging technology does not imply ****
***** an endorsement of western industrial civilization *****
On Sep 7, 2009, at 5:48 PM, Russ Abbott wrote:
Let me bring this back to where I started with this. You may
recall that a while ago I was talking about what I wanted in an
ideal agent-based modeling system. I have been thinking about as a
starting point. One of the things I like about Drools is that it
is a forward chaining system that supports a workspace that can
contain arbitrary Java objects along with rules that operate on
those objects. I find that very attractive because it allows new
primitives to be added at any time while at the same time
providing a reasonable framework for logical operations.
I wanted a term that would describe this sort of openness.
As I've been attempting to describe it, the closest comparison
seems to be to a general Genetic Algorithm system in which the
population, genetic operators, and fitness function are all left
open. The analogy is that the GA population plays a role similar
to the Drools workspace and the GA genetic operators and fitness
function plays a role similar to the Drools rules.
I was looking for a term that would capture the sort of
operational framework within which the lowest level objects and
operations were left open while the framework implemented some
higher level functionality in terms of those objects and operations.
-- Russ
On Mon, Sep 7, 2009 at 4:27 PM, Steve Smith <[email protected]>
wrote:
Birch -
I thought Container as well (although Bag leapt to mind too) but
Russ decided against so all that was left was the more abstract
descriptor. Besides, LISP has a data structure or two and
underlying types, loosely defined but they are there - IMHO "Data
Structure" is neither procedural, declarative, nor functional.
Of course.
I merely have my face being rubbed in this right now cuz I'm the
old-school C programmer working with some new-school C++ kids who
don't really even know what a Struct is... They will create a
Class when a Struct is what they really need.
Since I grew up in the early days of Knuth's Art of Computer
Programming (when you were still in a Brooklyn grammar school
beating up honor-roll students for their lunch money)... I tend to
the Procedural view of things... I learned all the Applicative
and Object Oriented and Concatenative ( In my NeWS days) languages
offered up to me in the g(l)ory days. I have loved my Snobol and
APL and Prolog and PostScript (*as a programming language!*) and
Objective C and Java and loved to hate LISP and Haskell and
Simula, and made peace with C++, but at heart, I love the half-
step of abstraction from hardware that good ole C provides. It's
a goddamn bit processing machine, gimme some register variables
and an easy way to do bit-shifts and I'll build the rest from raw
stock!
Of course due to my current work situation I am drawn to "bring me
a rock" like a moth to the flame.
Does this mean you are avoiding deadlines? Or just so morbidly
fascinated with all things work-related that answering
enelucidable riddles is like mother's milk?
I have a bottle of Irish Whiskey to replenish yours and Bourbon is
always good (rot gut or not) but you know that I can't condone
burning books for any reason!
Yes, I believe we did do some damage to a bottle of Jamesons last
time you were over. And I don't need you to condone the burning
of books, but that doesn't mean you can't warm your hands by the
woodstove while *I* do. The real sin would be to use good
whiskey as an accellerant (for the combustion, not the attitude).
-Birch
============================================================
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
--
Doug Roberts
[email protected]
[email protected]
505-455-7333 - Office
505-670-8195 - Cell
============================================================
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
