[Python-ideas] Concurrent safety?

[Mike Meyer]

On Mon, Oct 31, 2011 at 11:25 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 31 Oct 2011 10:59:56 -0700
> Mike Meyer <mwm at mired.org> wrote:
>> On Sun, Oct 30, 2011 at 8:21 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> > On Mon, Oct 31, 2011 at 1:11 PM, Mike Meyer <mwm at mired.org> wrote:
>> >> The one glaring exception is in concurrent programs. While the tools
>> >> python has for dealing with such are ok, there isn't anything to warn
>> >> you when you fail to use those tools and should be.
>> >
>> > This will basically run into the same problem that
>> > free-threading-in-CPython concepts do - the fine grained checks you
>> > need to implement it will kill your single-threaded performance.
>>
>> These argument seems familiar. Oh, right, it's the "lack of
>> performance will kill you." That was given as the reason that all of
>> the following were unacceptable:
>
> Agreed, but killing performance by double digits in a new release is
> generally considered quite ugly by users.

That may be why languages rarely adopt such features. The users won't
put up with the cost hit for the development versions.  Except for
LISP, of course, whose users know the value of everything but the cost
of nothing :-).

> Also, I'm not convinced that such approaches really bring anything. My
> opinion is that good multi-threaded programming is achieved through
> careful abstraction and separation of concerns, rather than advanced
> language idioms.

Doesn't that cover all kinds of good programming? But advanced
language features are there because they are supposed to help with
either abstraction or separation of concerns. Look at the list I
presented again:

- High level languages.
- Byte-compiled languages.
- Structured programming.
- Automatic memory management.
- Dynamic typing.
- Object Oriented languages.

All help with either abstraction or separation of concerns in some way
(ok, byte-compilation the concerns are external, in that it's code
portability). So do the features I'd like tosee. In particular, they
let you separate code that in which concurrency is a concern from code
where it isn't.

Another aspect of this issue (and yet another possible reason that
these features show up in new languages rather than being added to old
ones) is that such changes usually require changing the way you think
about programming. It takes a different mindset to program with while
loops than with if & goto, or OO than procedural, or .... Similarly,
it takes a different mindset to program in a language where changing
an object requires special consideration. This may be to much of a
straight-jacket for a multi-paradigm language like Python (though Oz
manages it), but making the warnings ignorable defeats the purpose.

        <mike