In that case, you will positively *hate* Charm++:
Charm++, is a fairly sophisticated parallel programming language and runtime
system that facilitates load balancing, latency hiding, and fault tolerance
through processor virtualization. Applications built upon Charm++ create
parallel objects
I'm currently at the TeraGrid '07 conference in Madison, WI (
http://www.union.wisc.edu/teragrid07/), and I took an opportunity at one of
the social gatherings last night to share some of the high points of this
thread with a few of the other conference attendees, mostly as a sanity
check for my
Douglas Roberts wrote:
It addresses fault tolerance and dynamic load balancing requirements
which become incredibly important when computing on this scale.
I'd much rather have checkpointing and load balancing done at the
operating system level, like by Linux kernel features (e.g.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It sounds like you misrepresented the thread, to me. The point is to
build software according to requirements. Sometimes those requirements
require OO and sometimes they don't.
Those few who believe OO is an impediment are actually saying that OO
Douglas Roberts wrote:
When I mentioned that there were a few people on this list who felt
that OO methodologies were an impediment to ABM development rather
than a benefit, the general response was disbelief.
OO methodologies, and esp. common OOP tools, can be both a benefit and
an
Some of you may be interested in the specific interventions suggested by the
United Nations Development Programme (my former employer) to adapt to
climate change: ABMs might be useful for some of these strategies.
_http://www.undp.org/gef/adaptation/climate_change/02d.htm_
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
On 6/5/07, Glen E. P. Ropella [EMAIL PROTECTED] wrote:
snip
Saying some thing _can_ be an impediment is very different from saying
that it is _always_ an impediment.
Well there's your problem Glen - you're trying to introduce conditionals and
realistic shades of grey when this group is more
So, I guess the question then would be this: Does a post that generates a
thread that is 54 messages long and counting always qualify as as a flame,
or only under certain conditions (i.e. Roberts started/contributed to the
thread).
Black. White! Black. No, White!
Wrong. Am not! Are too!
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
Guess who sounds like a cranky old fart now?
I'm positively jovial in comparison. (My preferred methodology,
coincidently).
;-}
Oh, and btw: the world is generally comprised of objects, which has the
interesting effect of influencing most modern sw developers to prefer OO
environments (and
Douglas Roberts wrote:
On 6/5/07, *Glen E. P. Ropella* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
For those of you who use phrases like OO methodologies, it's OO
method. The word methodology indicates the study of method.
Either one looks to be just fine.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Douglas Roberts wrote:
Oh, and btw: the world is generally comprised of objects, which has the
interesting effect of influencing most modern sw developers to prefer OO
environments (and methodologies, tee hee) over the older procedural ones.
No,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Howard wrote:
Some quotes from the same person:
So, what's your point?
- --
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
Do I contradict myself? Very well, then, I contradict myself; (I am
large -- I contain multitudes.) --
14 matches
Mail list logo
