The future of Python immutability

[Steven D'Aprano]

On Tue, 08 Sep 2009 09:38:51 +0200, Hendrik van Rooyen wrote:

> On Monday 07 September 2009 20:26:02 John Nagle wrote:
> 
>>     Right.  Tracking mutablity and ownership all the way down without
>> making the language either restrictive or slow is tough.
>>
>>     In multi-thread programs, though, somebody has to be clear on who
>>     owns
>> what.  I'm trying to figure out a way for the language, rather than the
>> programmer, to do that job.  It's a major source of trouble in threaded
>> programs.
> 
> I think that trying to make the language instead of the programmer
> responsible for this is a ball-buster.  It is unlikely to be either easy
> or cheap. I would rather have the programmer responsible for the mental
> model, and give her the tools to do the job with.

That was the situation 20 years ago with memory management. I'm sure 
people back then thought that the Right Solution was to give the 
programmer tools to get the job done, and hope they can avoid 
dereferencing nil pointers and memory leaks and all the other cruft of 
hand-managing memory. Today, we have garbage collectors and high-level 
languages like Ruby, Python, Haskell etc that manage that for you, and 
even heavyweight garbage collectors are practical for the majority of 
userspace applications.


> In any case - if you do not actually like juggling with knives, then you
> should not be mucking around with concurrency, and by making the
> language safe, you are taking the fun out.

If by "fun" you mean "screaming horrors", I agree.


-- 
Steven