On 8/19/2011 7:41 PM, David Barbour wrote:
On Fri, Aug 19, 2011 at 5:33 PM, BGB<[email protected]> wrote:
'Messaging' is a problem child of its own. It forces us to write
highly stateful applications, in order to coordinate or orchestrate
multiple devices. Resulting applications are neither resilient nor
robust: a missed, lost, dropped, or delayed message can cause
applications to behave unexpectedly, with no recovery in sight.
it depends some on what exactly one means by "messaging".
No. It does not 'depend'. These problems are fundamental to messaging.
Even in the most ideal messaging case you can imagine - method calls
in a single thread - the problems I named still hold. Development is
still intensely stateful to combine messages over time. Drop and
ordering errors are still possible - e.g. forgetting to release a
resource, transposing two actions, or reentancy issues. The model is
not robust or resilient to those errors.
The 'mess' in 'message' is exacerbated as we add concurrency or
distribution. But that's just because we're scaling up - scaling makes
many warts obvious. Messaging - the fundamental notion of
finite-packet-structured information carrying snapshots of the past -
is problematic even at small, single-threaded scales.
if a message is equivalent to a method call, then it is equivalent to a
method call...
also, for multiple threads, there are worse ways to do things than by
passing messages:
semaphores;
volatile global variables (more so in certain "lock-free" styles);
...
about the only things "more decoupled" than function or
method calls that I know of ...
There is nothing inherently wrong with organizing code in terms of
functions and methods. The problem is the 'messaging' - the finite
structured packets, and the effed up model of time messaging presents
to its participants.
There are certainly many ways we could reduce coupling further. As you
mention, publish/subscribe - and content-centric models in general -
are likely options. But this is orthogonal to the problems of
messaging. Indeed, message-based pub/sub is still quite problematic -
e.g. different observers are likely to see the same update events in
different orders and eventually disagree on system state.
possibly, but this is only really an issue if:
the system is asynchronous or otherwise non-deterministic;
event ordering is necessary for correct operation.
a much more notable problem is that, in the case of many systems, there
ends up being tight coupling between components.
the worse case being when the code is physically dependent on the other
code, for example, two C++ classes which each make direct use of the
other class, or a pair of C or C++ modules which share variables and
data-structures and call between each other, ...
the first major level of decoupling is to split each off into an
independent API, limiting or eliminating direct interaction between them
(typically, front-end code will marshal between them, where the frontend
depends on both).
the second level is when the "frontend" is eliminated, and interop is
through an independent 3rd party (neither component directly knows about
the other, but they communicate by being plugged into a 3rd party which
doesn't directly know of either, but will provide some means of "service
discovery").
a 3rd level is when they no longer assume residing in the same address
space or sharing a certain language or ABI (the "3rd party" may migrate
out of the process, or be a network service, for example).
...
trying to late-bind a macro inherently makes it a different sort
of beast from either an early-bound macro, or from an ordinary
function call
A fexpr. Frankenprogramming Expression. A fexpr will reach into the
guts of a valid program, and tweak it in unnatural ways at the whims
of developers who straddle the lines of genius and madness.
I'm not very fond of fexprs, pattern calculus, and their like -
anything that breaks encapsulation is a security and safety risk. I
do like early binding of user-defined syntax per module. For runtime
evaluation of user-defined languages, I would prefer developers use a
proper library or service. A partial evaluator or trace compiler at
runtime can crunch an interpreter to native performance.
well, at least on the upside, my quote/unquote mechanism is sufficiently
ugly to where one knows "something is going on".
I just did a little test where I composed an expression using a list:
unquote #(#binary #+ 2 3);
and got the expected '5'.
note that this is technically making use of implementation details here...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
