functional

[grauzone]

Andrei Alexandrescu wrote:
> On 03/10/2010 07:07 PM, grauzone wrote:
>> 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.
> 
> "That does not work."

But it does!

> Andrei