functional

[Andrei Alexandrescu]

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."

Andrei