Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] ocaml killer
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-01-29 (16:14)
From: Martin Berger <martinb@d...>
Subject: Re: [Caml-list] ocaml and concurrency

>  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

>  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.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: