Functional programming in Python • Hacker News Board

Re: Functional programming in Python

#41

Post by SiVal » Sat, May 12, 2012, 1:39 AM UTC

dustingetz wrote: post #21

as has been pointed out, python isn't particularly great at doing hardcore functional programming due to lack of native persistant datastructures. however i've found it great for learning functional programming without having to get used to the syntax of real functional languages. here are some different ways to implement functional sequence operations without native python syntax like `yield`: https://github.com/dus…

I was at a Python user group meeting with Guido a few years back, and I asked him about his plans for functional programming support in Python. He responded that he thought functional programming was a lot less useful than all the hype would suggest, and that, far from planning more support for functional programming, he regretted having put in as much support as he already had. Ideally, he said, he would remove things like lambda instead of making them stronger.

Even things like tail call elimination, he said, would just encourage people to use more recursion, when iteration was easier to read, and in places where TCE would work, the programmer could obviously convert it to iteration himself and should do so for code clarity.

I like Python, and I like a lot of things about functional programming, so it wasn't the answer I was hoping for. Unless Guido has had a change of heart since then, I wouldn't pin my hopes on Python ever becoming a first-rate functional programming language. It's first rate at the things Guido values.

Re: Functional programming in Python

#42

Post by lihaoyi » Sat, May 12, 2012, 2:39 AM UTC

nknight wrote: post #34

swannodette wrote: post #33

Earlier quoted context omitted.

Performance? Unless I'm mistaken you can't update tuples efficiently.

How do you intend to "update" an immutable list? Isn't it... immutable?

Immutable lists can be preppended/popped in O(1)time, without affecting previous versions.

Immutable dicts can have stuff added and removed in O(log n) time, without affecting previous versions.

Scala's immutable vectors can have appending/prepending/concatenation/splitting/insertion/deletion in O(log n) time, without affecting previous versions. it's log base 32, so for any arrays using integer indexes, it'll never go above ~7, so it's basically constant.

Basically, you get (almost) the performance of mutable data structures, except you don't mess up the old versions of the thing every time you change something. It's really pretty incredible, the performance characteristics people manage to get with structural sharing: http://www.scala-lang.org/docu/files/collections-api/collect...

Re: Functional programming in Python

#43

Post by craigyk » Sat, May 12, 2012, 3:17 AM UTC

dustingetz wrote: post #21

as has been pointed out, python isn't particularly great at doing hardcore functional programming due to lack of native persistant datastructures. however i've found it great for learning functional programming without having to get used to the syntax of real functional languages. here are some different ways to implement functional sequence operations without native python syntax like `yield`: https://github.com/dus…

I don't remember where I read it, but "watching someone try to do functional programming in python can be painful". I have to agree quite a bit with that. The distinction between lambdas and functions, expressions, etc.

I started doing a lot of programming in CoffeeScript a few months ago, and between the JS underpinnings and the CS syntax you can do things that would just be painful in Python.

Re: Functional programming in Python

#44

Post by gbog » Sat, May 12, 2012, 4:11 AM UTC

SiVal wrote: post #41

dustingetz wrote: post #21

as has been pointed out, python isn't particularly great at doing hardcore functional programming due to lack of native persistant datastructures. however i've found it great for learning functional programming without having to get used to the syntax of real functional languages. here are some different ways to implement functional sequence operations without native python syntax like `yield`: https://github.com/dus…

I was at a Python user group meeting with Guido a few years back, and I asked him about his plans for functional programming support in Python. He responded that he thought functional programming was a lot less useful than all the hype would suggest, and that, far from planning more support for functional programming, he regretted having put in as much support as he already had. Ideally, he said, he would remove thin…

I don't know. It seems to me, from reading SICP, that functional programming doesn't mean lambdas or map reduce, it means pure functions as the main programming unit, instead of object or instruction or declaration. Then it is possible to write functional code in python without lambdas, map, using streams (iterators) as the state keeping data structure.

Re: Functional programming in Python

#45

Post by gbog » Sat, May 12, 2012, 4:18 AM UTC

rbonvall wrote: post #29

chimeracoder wrote: post #9

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

One thing I love about Lisp is that it's ridiculously easy to write (cons item some-list), or even (cons item1 (cons item2 some-list)). Iterators can help (and in O(1)): >>> from itertools import chain >>> some_list = range(5) >>> item = 99 >>> a = chain([item], some_list) >>> for x in a: ... print x ... 99 0 1 2 3 4

Yes. That's the hole point of the article, and matches very well with my understanding of SICP: functional programming is possible only if you model changing state in streams, which are just called iterators in python. All the fuss about python missing some parts too be really functional seem to have missed the point to me.

Re: Functional programming in Python

#46

Post by pjscott » Sat, May 12, 2012, 4:26 AM UTC

FuManJew wrote: post #27

andylei wrote: post #20

Earlier quoted context omitted.

if you want to append to fronts and backs of lists, you should use deque: http://docs.python.org/library/collections.html#collections....

pronounced "deck"

So it is a doubly linked list, its name is deque, and its name is pronounced "deck". The levels of indirection here sound kind of like something Lewis Carroll might write.

Re: Functional programming in Python

#47

Post by pjscott » Sat, May 12, 2012, 4:35 AM UTC

recursive wrote: post #31

swannodette wrote: post #28

Earlier quoted context omitted.

A good set of persistent data structures would give you all the generality, utility, and performance of Python data structures like lists and dicts and none of the mutability.

I don't know about dicts, but as far as I can tell, tuples give you all the generality, utility, and performance of lists.

A tuple, behind the scenes, is just a type tag, a refcount, a length, and an array of PyObject pointers. A list, instead of having a fixed array of PyObject pointers, has a pointer to a dynamically resizable array of them. Tuples and lists are both iterable, they both have O(1) indexing and fairly efficient internal representations, but the key difference is mutability. A tuple is supposed to be a composite data type; a list is a dynamic array that you store things in.

Aside from mutability, though, tuples can do pretty much anything lists can, and usually a bit more efficiently.

Re: Functional programming in Python

#48

Post by algorias » Sat, May 12, 2012, 7:16 AM UTC

pjscott wrote: post #46

FuManJew wrote: post #27

Earlier quoted context omitted.

pronounced "deck"

So it is a doubly linked list, its name is deque, and its name is pronounced "deck". The levels of indirection here sound kind of like something Lewis Carroll might write.

The name means double-ended queue. That's the reason behind the strange pronunciation.

Re: Functional programming in Python

#49

Post by mappu » Sat, May 12, 2012, 7:29 AM UTC

pjscott wrote: post #46

FuManJew wrote: post #27

Earlier quoted context omitted.

pronounced "deck"

So it is a doubly linked list, its name is deque, and its name is pronounced "deck". The levels of indirection here sound kind of like something Lewis Carroll might write.

'deque' is an irregular abbreviation for double-ended queue, and "deck" is a convenient metaphor for visualising the container - you can put things at either end of a deck of cards. c.f. std::deque

Re: Functional programming in Python

#50

Post by ubernostrum » Sat, May 12, 2012, 8:38 AM UTC

gbog wrote: post #44

SiVal wrote: post #41

Earlier quoted context omitted.

I was at a Python user group meeting with Guido a few years back, and I asked him about his plans for functional programming support in Python. He responded that he thought functional programming was a lot less useful than all the hype would suggest, and that, far from planning more support for functional programming, he regretted having put in as much support as he already had. Ideally, he said, he would remove thin…

I don't know. It seems to me, from reading SICP, that functional programming doesn't mean lambdas or map reduce, it means pure functions as the main programming unit, instead of object or instruction or declaration. Then it is possible to write functional code in python without lambdas, map, using streams (iterators) as the state keeping data structure.

The problem, as always in these discussions, is that no-one wants to define the term "functional programming". Many people will be quite willing, though, to jump on each other for saying things that they believe flow from an incorrect definition of the term.

Anyway, at the very least there's two camps. On the one side, you have the hardcore Scheme folks whose conception of functional programming is "if I can't figure out how to write it with tail recursion it must not be computable". On the other side you have the Haskell folks whose conception of functional programming is "a monad is just a monoid in the category of endofunctors, what's the problem?"

Somewhere in between are people who actually get things done.