[Haskell-cafe] Re: Python's big challenges, Haskell's big advantages?

[Aaron Denney]

On 2008-09-17, Arnar Birgisson <arnarbi at gmail.com> wrote:
> Hi Aaron,
>
> On Wed, Sep 17, 2008 at 23:20, Aaron Denney <wnoise at ofb.net> wrote:
>> I entered the discussion as which model is a workaround for the other
>> -- someone said processes were a workaround for the lack of good
>> threading in e.g. standard CPython.  I replied that most languages
>> thread support can be seen as a workaround for the poor performance
>> of communicating processes. (creation in particular is usually
>> cited, but that cost can often be reduced by process pools, context
>> switching costs, alas, is harder.)
>
> That someone was probably me, but this is not what I meant. I meant
> that the "processing" [1] Python module is a workaround for CPython's
> performance problems with threads.

Ah, on rereading that's much clearer.  Thank you for the clarification.

> The processes vs. threads depends on definitions. There seem to be two
> sets floating around here. One is that processes and threads are
> essentially the same, the only difference being that processes don't
> share memory but threads do. With this view it doesn't really matter
> if "processes" are implemented as proper OS processes or OS threads.
> Discussion based on this definition can be interesting and one model
> fits some problems better than the other and vice versa.
>
> The other one is the systems view of OS processes vs. OS threads.
> Discussion about the difference between these two is only mildly
> interesting imo, as I think most people agree on things here and they
> are well covered in textbooks that are old as dirt.

I think from the OS point of view, these two distinctions are nearly
equivalent.  There is only a difference when you start talking about
non-OS threads, such as those provided by various language runtimes.

>> There, the implementation detail of thread, rather than process
>> allows and even encourages shortcuts that violate the process model.
>
> Well, this is a viewpoint I don't totally agree with. Correct me if
> I'm not understanding you, but you seem to be making the point that
> OS processes are often preferred because with threads, you *can* get
> yourself in trouble by using shared memory.

That's exactly it.  Or rather, you can get in exactly as much trouble
with processes, but because accessing a variable in another memory space
is more cumbersome, you have to actually think when you do so.  Looking
at all uses of "a = b" to see what invariants might be broken is unfeasible.
Looking at all requests for updating a remote variable might be
manageable.

-- 
Aaron Denney
-><-