Learning Haskell makes you a better programmer?

[deadalnix]

On Friday, 28 December 2012 at 13:03:11 UTC, Russel Winder wrote:
> On Fri, 2012-12-28 at 10:53 +0100, deadalnix wrote:
> […]
>> It depends what you mean by functional. It seems to me that 
>> you'll find 2 major things that are usually understood as 
>> functionnal :
>>   - abstraction based on first class function. javascript is 
>> the perfect example here, and is functional.
>>   - purity and immutability.
>
> In the most recent "Open Source Journal", Uncle Bob has stated 
> that all
> you need to say is "no assignment" and you end up having to 
> invent
> functional programming.
>

That is true. But is also quite reductive. If functional 
programming can solve that problem, it is also very suited for 
many other things, for instance event programming (where concept 
like immutability and purity are not that useful).

>> If you have no tools to enforce immutability, you need to 
>> completely break abstraction to get the benefit. This is bug 
>> prone and will not scale (without abstraction nothing big is 
>> achievable).
>
> I am not sure what you mean by "break abstraction" here. Nor 
> how you get
> to "will not scale". Can you elaborate?  Thanks.

Sure. To make that clear I have to reintroduce the context : I 
was answering to a post that stated that even if the language 
don't support immutability, you can have immutability simply by 
not mutate data.

To benefit from immutability, you have to be 100% sure that no 
piece of code will mutate the data ever. If you have no support 
for that, you break abstraction, because you have to know the 
internal of every piece of code you use, in order to know if the 
data are modified or not. If you have to know the internal of 
each piece of code you use, then abstraction is broken.

If abstraction is broken, then the ability to code will be 
reduced as the codebase grow, to a point where nothing is 
maintainable anymore. When I say that it will not not scale, I'm 
talking about scaling the technique to a bigger codebase, not 
actually scaling the resulting program to bigger workload.

The subject is quite big, and I have proposed a talk about it in 
DConf 2013 (I'm waiting for Walter to accept or reject).