There's always http://en.wikipedia.org/wiki/Actor_model
and http://www.dalnefre.com/wp/humus/ ...which seem to make concurrency less of a PITA. Like most languages that crystalize a particular style, though, there's some learning involved for folks (like me!) who hadn't really thought about the actor model in a deep way. On Sun, Feb 12, 2012 at 9:15 AM, Steve Wart <[email protected]> wrote: > Simplicity, like productivity, is an engineering metric that can only be > measured in the context of a particular application. Most successful > programming languages aren't "mathematically pure" but some make it easier > than others to use functional idioms (by which I mean some mechanism to > emulate the types of operations you describe below). However many problems > are simpler to solve without such abstractions. That's why "practical > languages" like Smalltalk-80 and Lisp and their mainstream derivatives have > succeeded over their more pure counterparts. > > I think I responded to this message because I was sick in bed yesterday > reading the intro paragraphs of The Algorithmic Beauty of Plants yesterday ( > http://algorithmicbotany.org/papers/#abop), and shared the introduction > of DOL-systems with my son. We both enjoyed it, but I'm not sure how this > translates into reasoning about distributed systems. > > Can the distributed computation model you describe be formalized as a set > of rewrite rules, or is the "black box" model really about a protocol for > message dispatch? Attempts to build distributed messaging systems haven't > been particularly simple. In fact I consider both CORBA and Web Services to > be failures for that reason. > > It's very difficult to use OO in this way without imposing excessive > knowledge about the internal representation of objects if you need to > serialize parameters or response objects. > > HTTP seems to have avoided this by using MIME types, but this is more > about agreed upon engineering standards rather than computational > abstractions. > > Cheers, > Steve > > > On Sun, Feb 12, 2012 at 4:02 AM, Jakob Praher <[email protected]> wrote: > >> We would have to define what you mean by the term computation. >> Computation is a way to transform a language "syntactically" by defined >> rules. >> The lambda calculus is a fundamental way of performing such >> transformation via reduction rules (the alpha, beta, gamma rules). >> >> In the end the beta-reduction is term substitution. But abstraction and >> substitution in a generic purpose von Neumann-style computer has to be >> modelled accordingly: A variable in the computer is a memory location/a >> register that can be updated (but it is not a 1:1 correspondence). E.g. A >> function in a computer is jump to a certain code location having to write >> to certain locations in memory/registers to get the arguments passed. >> >> IMHO the computational model of objects and method dispatch is more of a >> black box / communcation-oriented model. One does not know much about the >> destination and dispatchs a message interpreting the result. In functional >> languages the model is more white boxed. One can always decompose a term >> into subterms and interpret it. Therefore functional languages do not grow >> easily to distributed programming, where the knowledge over the terms is >> limited. >> >> Best, >> Jakob >> >> > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
