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. > > 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. > > 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. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
