From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA12436; Thu, 29 Jan 2004 17:14:21 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA12325 for ; Thu, 29 Jan 2004 17:14:20 +0100 (MET) Received: from mail.dcs.qmul.ac.uk (vicar.dcs.qmul.ac.uk [138.37.88.163]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id i0TGEKv11190 for ; Thu, 29 Jan 2004 17:14:20 +0100 (MET) Received: from new8-pc.dcs.qmul.ac.uk ([138.37.88.113] helo=dcs.qmul.ac.uk ident=martinb) by mail.dcs.qmul.ac.uk with asmtp (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.30) id 1AmEo7-0003lf-GL; Thu, 29 Jan 2004 16:14:19 +0000 Message-ID: <401930C6.8060907@dcs.qmul.ac.uk> Date: Thu, 29 Jan 2004 16:11:50 +0000 From: Martin Berger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vitaly Lugovsky , Caml Mailing List Subject: Re: [Caml-list] ocaml and concurrency References: <20040127063230.GA12482@inv_machine> <200401282326.i0SNQntl004612@bismarck-chet.watson.ibm.com> <97908806-5238-11D8-8975-000393B8133A@wetware.com> <4018E282.2040404@dcs.qmul.ac.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Auth-User: martinb X-clamav-result: clean (1AmEo7-0003lf-GL) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 lacking:01 expressivity:01 side-effect:01 side-effect:01 passing:01 passing:01 precautions:99 stupid:01 expressive:01 book-keeping:01 ocaml:01 ocaml:01 trivial:01 enforce:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Nothing? Did you forget about the possibility to code without > side effects? you have this possibility in java too, albeit less conveniently due to lacking type expressivity. more importantly, however, ocaml does not enforce side-effect freeness. but in a big project with multiple and changing developers, what guarantees that no other developer cuts a corner and introduces some inappropriate side effects (this can be done in many and subtle ways)? only SW-engineering discipline. But that is applicable to other languages, too. even more importantly, side-effect freeness only prevents (certain) race conditions. but race conditions are never really a problem for any experienced programmer (and others should not try and write concurrent or distributed programs). there is a very simple rule: every access to a shared variable must be guarded by a lock. it is trivial. if you do not know what your shared variables are at any time in your development, you are in the wrong job. the real problems with concurrent programming are deadlocks, livelock and things like that. lack of side effects does not help you here at all. > Right. But it's much easier to implement a quite stable > environment for message passing, which will remain stable until > you're following some quite simple rules. i don't see why message passing is easier to implement and use in ocaml than in, say, C++. and livelock or starvation in your message queues can happen in either language, too, unless you take precautions. having said all that, i much prefer writing concurrent or distributed code in ocaml. i think that's because it is more high level, prevents lots of stupid mistakes by typing, is more expressive and requires me to do much less bureaucratic book-keeping. that frees up mind and screen space for the difficult issues. martin ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners