On Sat, Jun 26, 2010 at 7:53 AM, dalnefre <dale.schumac...@gmail.com> wrote: >> a practitioner's reason for developing and using a design pattern is that >> the host language was inadequate or was missing features. > > Failings of the language are not necessarily failings of the model. > > I think we are actually in agreement WRT the purpose of a pattern in > the context of a programming _language_. Sometimes you observed a > pattern after-the-fact, and then abstract it out for general > application. [...] If a language doesn't provide appropriate > abstraction mechanisms, then you end up with a lot of > duplication with minor variations, as you described. > I agree, this is a bad thing.
My statement regarded efficacy and adequacy of a model for expression, not performance and productivity. The effectiveness and adequacy of a model do not change when you 's/model/_language_'. And mechanisms for abstraction are not somehow a responsibility unique to 'languages'; indeed, such mechanisms are the fundamental basis of many models of computation, whether you're discussing term rewriting, lambda substitution, grammars, or even actors model (whose original formulation uses actors even for lambdas and '+'). A specific programming language can be understood as providing both an executable model of computation and a user interface. Thus, there are powerful incentives in programming language design for performance and productivity. Often, a language's model will become an amalgam of other models in pursuit of these properties (though whether these component models complement vs. compromise one another isn't always well understood by the language's designer). It would be reasonable to study the resulting model in a holistic manner in addition to its constituent models - i.e. Humus's model chooses to replace Hewitt's rather awkward formulation of lambdas-as-actors with a dedicated term language and first-class functions, and Humus is (likely) richer for it. OTOH, Humus also adds an exception-handling model - a decision whose value is far more questionable. On Sat, Jun 26, 2010 at 7:53 AM, dalnefre <dale.schumac...@gmail.com> wrote: > However, libraries and frameworks _are_ abstraction mechanisms. A framework instance captures a 'when', separating it from a 'what', allowing developers to separate conditions of operation from the behavior to execute. However, with regards to 'patterns', "is this an abstraction mechanism" is the wrong question. The right questions are: "Can I abstract the framework concept? Can I instantiate new framework instances on-the-fly? Can I compose abstract frameworks into larger abstract frameworks? Can I compose concrete framework instances into larger concrete frameworks? Do I maintain local reasoning about holistic properties of the resulting composite frameworks (as opposed to thinking through the whole composite each time)?" For a great many programming languages / computation models, the answers to these questions are "no, no, no, usually no, and no". Many issues interfere or require extra handiwork and consideration on a per-composition or per-instantiation basis. To name a few: setup, tear-down, manifest typing, authority and interference, concurrency control, resource accounting, and reasoning about such things as: disruption tolerance, graceful degradation, partial-failure, resilience, safety (deadlock, priority inversion, timing), and performance (utilization, efficiency, latency). Of course, there are a great many different framework or framework-like patterns (abstract factory, dependency injection, visitor pattern, publish-subscribe models, prevalence layers), and I believe one would be richer for studying abstraction and composition of these patterns individually and pairwise rather than making broad observations about 'frameworks' as a whole. But, on-the-whole, reactive programming approaches seem well suited to abstracting frameworks and composable support for concurrency and concurrency-control are likely to go a very long way towards simplifying abstraction and composition of frameworks. I suspect Actors model, for example, would come out well ahead of procedural/OOP after such a survey. As to 'libraries' - unless you mean 'modules' with some sort of implementation hiding (abstract data type), I do not believe you can consider libraries as we usually use the term to be an abstraction 'mechanism'. But ADT is not relevant to abstracting patterns: to produce a new concrete instance of an abstract pattern will always require providing some extra concrete detail, and thus requires some form of parametric abstraction. I do not see how libraries are ever relevant wrgt. the efficacy and adequacy of a computation model (even if they are very, very important to developer productivity). On Sat, Jun 26, 2010 at 7:53 AM, dalnefre <dale.schumac...@gmail.com> wrote: > It would be useful to create a language with more powerful abstractions > mechanisms that would be suitable for the creation of domain-specific > languages. I believe such a language could be described in Humus, > and thus retain the fundamental properties of actors. Since Humus is Turing-complete, the notion that you could describe another language in Humus is certainly true. But the latter half of your statement - that you would 'thus retain the fundamental properties of actors' - is far more questionable. I suppose it depends on what you mean by 'retains' and 'fundamental properties of actors'. But I think it would be true only in one trivial sense, and one relevant sense. Trivially, an embedded DSL has access to an Access to communications via its Actors model framework. Relevantly, the DSL would usually be developed in this framework, and thus would leverage the Actors model effectively (similarly to how Lua leverages a single-threaded stack-model effectively). In the broader sense of DSLs and embedded languages, the assertion isn't meaningfully true. An Actors model implementation of Lua or HTML or YAWFL or Maude or cellular automaton won't be retaining any relevant properties of actors - no more than Humus itself is retaining properties of its underlying shared-memory layer. On Sat, Jun 26, 2010 at 7:53 AM, dalnefre <dale.schumac...@gmail.com> wrote: > In addition, I _would_ argue that there are powerful interaction patterns > that are > much easier to express with actors. Words like 'easier' need an indirect object. :-) * Easier than INTERCAL. Certainly. It takes creative effort to be more difficult than INTERCAL. * Easier than procedural + stack-based OOP. Agreed. I originally chose ActorsModel for this same reason. * Easier than Petri Nets? Hewitt makes a decent case here. * Easier than cellular automaton? Well, certainly easier than those based strictly on neighboring cells in a 1D or 2D grid... * Easier than Pi Calculus? Join Calculus? CSP? * Easier than YAWFL? BPEL? Orc? * Easier than Dataflow programming? Declarative Concurrency? * Easier than Functional Reactive Programming? * Easier than Timed Concurrent Constraint Programming (tcc)? or Temporal Logic Programming (such as Dedalus: Datalog in Time and Space)? * Easier than Term-graph Rewrite Systems (such as Maude and OBJ3)? Hmmm... seems I ran out of easy answers after the first three. I know I can't think of any patterns that are easier to express in actors than in the recently invented RDP, but I've never attempted to prove it in general. One might informally measure how 'powerful' a system (for interaction patterns) based upon how directly it expresses, abstracts, and composes each of the models I just mentioned. On Sat, Jun 26, 2010 at 7:53 AM, dalnefre <dale.schumac...@gmail.com> wrote: > And the resulting composition _does_ maintain safety, scalability and > performance (actually responsiveness) properties that are desirable. That was not my experience. I found compositions, but I could not maintain the nice properties without making them first-class. But perhaps you'll fare better, and I wish you good luck! On Sat, Jun 26, 2010 at 7:53 AM, dalnefre <dale.schumac...@gmail.com> wrote: >> So here's the real challenge: solve the challenges without using any >> insecure or pervasive or non-composable patterns. > > This is the challenge that I am trying to meet. By building actor- > based solutions and exploring their strengths and limitations, I hope > to share the patterns for success and warn of the pitfalls. I > understand that you've been down this road and are sharing your > concerns about the pitfalls you've encountered. I appreciate that, > and will keep my eyes open to those dangers. Perhaps I can find > acceptable ways to mitigate the danger. At worst, I'll simply confirm > your observations. I wish you luck, then - which, in this context, means the environmental circumstances for insight, and opportunity to recognize a Eureka moment and grapple it before it escapes. After that, it's all up to your own tenacity. :-) Warm Regards, David _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
