functional

[grauzone]

Andrei Alexandrescu wrote:
> On 03/10/2010 06:47 PM, grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> On 03/10/2010 06:06 PM, grauzone wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> On 03/10/2010 05:01 PM, grauzone wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> There's one final nail in the coffin. In wake of concurrency, de 
>>>>>>> jure
>>>>>>> immutability becomes a necessity, not a useful and desirable de 
>>>>>>> facto
>>>>>>> convention. Adopting the window dressing but not the essence of 
>>>>>>> FP by
>>>>>>> a concurrent language evokes to me a scene in the Marx Brothers: an
>>>>>>> otherwise impeccably-dressed gentleman who forgot to put his pants
>>>>>>> on.
>>>>>>
>>>>>> Language support is not strictly necessary to get the same effects as
>>>>>> immutable types, as far as multithreading is concerned: small data 
>>>>>> can
>>>>>> be copied, and large data can be made read-only by OS syscalls. This
>>>>>> just had to be in the message passing library. (As a bonus, it isn't
>>>>>> possible to subvert these mechanisms just by casting.)
>>>>>
>>>>> That'll never work. The OS granularity is 4KB increments.
>>>>
>>>> Data this small you would simply copy. Because it's so small, copying
>>>> won't have negative performance impact. The OS approach can be used for
>>>> large data (at least in the order of hundreds of KB) and immutable 
>>>> parts
>>>> of the data segment.
>>>
>>> Trust me, that will never work anywhere close to satisfactory. It's
>>> even useless to talk about it.
>>
>> Just saying "it won't work" is a bit empty. Do you happen to have any
>> arguments?
> 
> I'd need to build a fair amount of background, which I don't have time for.

I don't think you'd need large amounts of "background" for a short and 
precise answer. It's not rocket science either. Though you could simply 
say "I don't want to answer now".

> Andrei
>