Why is immutable data considered necessary for functional programming style? Can't a a programmer or programmer just do the same thing with mutable data, but not mutate it? That is, couldn't Python be used for functional programming?

On Friday, 28 December 2012 at 08:13:05 UTC, Red wrote:
> Why is immutable data considered necessary for functional programming style? Can't a a programmer or programmer just do the same thing with mutable data, but not mutate it? That is, couldn't Python be used for functional programming?

well one of the points of immutable data is safely sharing across threads(the point there is that data once allocated doesn't changes so no need to sync it), functional languages also claims that they provides easy concurrency(if not "automagically"), but i can't say how it's really "easy" since i mostly do imperative and object programming.

On 12/28/2012 12:13 AM, Red wrote:
> Why is immutable data considered necessary for functional programming style?
> Can't a a programmer or programmer just do the same thing with mutable data, but
> not mutate it?

People who say that C++ supports functional programming make exactly that argument.

The problem, though, is this:

   T func(U u); // this is a pure function

What does that tell you about func? It takes a U as one of its inputs, and returns an instance of T. The comment, of course, means nothing. func may read or write mutable global state, it may mutate whatever u references. How would you know?

If you wrote all the code yourself, and you didn't make any mistakes, perhaps you would know. But if you are handed this code, or you work on a team, you would have no idea. There is no tool to check it, so you'd be reduced to manually going through every line of it and every line of every function that func() calls, etc.

Then when a member of your team checks in code, you're back to square one, and have to start over with the manual verification, and hope you didn't make a mistake with that.

Of course, nobody does something that tedious, and defaults back to trusting the comment, which is what I'd call "faith-based programming".

I don't believe that faith-based programming scales well at all. Programs are getting bigger and bigger all the time, and the growth of static analysis tools suggests that we *need* mechanical verification of properties. Faith-based programming is going to wind up on the ash heap of history.

The bottom line is that a language that does not support mechanical verification of functional programming, does not support functional programming.

On Friday, 28 December 2012 at 08:13:05 UTC, Red wrote:
> Why is immutable data considered necessary for functional programming style? Can't a a programmer or programmer just do the same thing with mutable data, but not mutate it? That is, couldn't Python be used for functional programming?

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.

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

On Fri, 2012-12-28 at 09:13 +0100, Red wrote:
> Why is immutable data considered necessary for functional programming style? Can't a a programmer or programmer just do the same thing with mutable data, but not mutate it? That is, couldn't Python be used for functional programming?

Because immutable state is a concept entirely missing from functional languages: functional languages have no tools for handling mutable state. OK Haskell has introduced arrays and indexing but it remains a dark corner for most use cases.

Yes, but… if a language provide features you would be writing in a non-idiomatic way to simply ignore those features. The issue here is that a language will embody a computational model and an idiomatic mode of expression of algorithms. A language should always be used in as idiomatic way as possible. To use an imperative language in a purely functional way will lead to poor code. Conversely all use of mutable shared state is a code smell that should lead to a refactoring.

Python cannot be used for functional programming in the purist sense due to lack of single assignment, presence of for and while loops, and lack of tail recursion optimization. However with higher order functional, list, set and dictionary comprehensions, many of the techniques and idioms of functional programming can, indeed should, be used when programming in Python.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thu, 2012-12-27 at 12:59 +0100, bearophile wrote:
[…]
> In my very limited Clojure experience I've seen that it uses a LOT of memory even for my small programs, sometimes almost ten times more than equivalent Python programs (like 120 MB for a small program that processes small genomic text files). And I've seen to write fast Clojure programs I have to add a ton of annotations to the code. So I have not used it further.

I have yet to find any JVM that doesn't require >120MB to start, then there is the Clojure system and your program, so that figure doesn't surprise me.  In any C/C++/Fortran context Python is the dynamic programming language if choice, but there is also Lua.

Clojure programs are not good for computational efficiency on the JVM, so if that is what you are after Clojure is the wrong tool. Groovy, Scala, Java, Kotlin, Ceylon form the choice set in that context.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Fri, 2012-12-28 at 09:37 +0100, evilrat wrote:
[…]
> well one of the points of immutable data is safely sharing across threads(the point there is that data once allocated doesn't changes so no need to sync it), functional languages also claims that they provides easy concurrency(if not "automagically"), but i can't say how it's really "easy" since i mostly do imperative and object programming.

Functional programming languages providing parallelism "for free" is a
deep issue. Given the computational model of graph reduction, the whole
concept of parallelism is different from that of JVM-based and native
languages. OCaml has a GIL and so cannot handle single process
multi-threaded parallelism. Haskell has real problems with parallelism
because it is lazy: without manually structuring the sparks, you get all
the computation on the master thread no mater what.  Simon Peyton Jones
and Simon Marlow have created "Data Parallel Haskell" which makes data
parallel computations in Haskell very parallel and very fast. Actor,
dataflow, CSP, fork-join style parallelism is difficult in pure
functional languages. Clojure has made best inroads on this by employing
the features of the JVM in a Lisp context.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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.

> 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.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Russel Winder:

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

Near the end of this interview, Erik Meijer shows why removing assignments is not enough if there is multi threading:

http://www.youtube.com/watch?v=z0N1aZ6SnBk#t=60m0s

Bye,
bearophile