From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 44E90BB9B for ; Wed, 5 Oct 2005 17:28:58 +0200 (CEST) Received: from ash25e.internode.on.net (ash25e.internode.on.net [203.16.214.182]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j95FSuxo013985 for ; Wed, 5 Oct 2005 17:28:57 +0200 Received: from rosella (ppp2-148.lns1.syd7.internode.on.net [59.167.2.148]) by ash25e.internode.on.net (8.12.9/8.12.6) with ESMTP id j95FSjd0070220; Thu, 6 Oct 2005 00:58:46 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: FP/IP and performance (in general) and Patterns... (Re: [Caml-list] Avoiding shared data) From: skaller To: Oliver Bandel Cc: caml-list@yquem.inria.fr In-Reply-To: <20051005121028.GA757@first.in-berlin.de> References: <20051003200337.14092.qmail@web26809.mail.ukl.yahoo.com> <1128394430.23813.20.camel@rosella> <20051004164700.GA494@first.in-berlin.de> <8008871f0510041539r1d2b242fifcd09cf32ba394fa@mail.gmail.com> <20051005121028.GA757@first.in-berlin.de> Content-Type: text/plain Date: Thu, 06 Oct 2005 01:28:44 +1000 Message-Id: <1128526124.7513.9.camel@rosella> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4343F138.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 avoiding:01 oliver:01 bandel:01 lacks:01 widget:01 stack:01 partitioned:01 inverts:01 stack:01 widget:01 partitions:01 partitions:01 reasoned:01 ...:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Wed, 2005-10-05 at 14:10 +0200, Oliver Bandel wrote: > For example, I'm not really a fan of OO-programming, but when > programming GUI-software I think it would be the best choice, > and FP-programming lacks flexibility here I contend that concurrent programming is best here. However, I don't know: I have a tool (Felix) to explore this, but haven't got around to actually trying the one-thread/one-widget paradigm. The OO solution is reactive and requires you to maintain the whole widget state without use of the stack, thereby discarding everything that is known about block structured and functional programming, and going back to the bad old days of the early 70s with a flat state space, except that the state space is partitioned into objects. The thread based solution control inverts this paradigm, giving you a stack and control flow for every widget, this is *active* or algorithmic programming. So I content it must be better, because it not only partitions the state space as OO does, it *also* partitions the control space, and allows you to use all the advantages of a functional or block structured style. Actually, in practice, I expect a mix of the solutions will be best. The reason is: we know a LOT about state machines. So subparts of problems which correspond to them can easily be programmed and reasoned about, simply because we have lots of mature theory. -- John Skaller Felix, successor to C++: http://felix.sf.net