Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional Python Programming

docs.python.org

Post reply on HN
Print view View original

101–105 of 105 posts

Re: Functional Python Programming

#101

Post by tpoacher »

znafelrif wrote: post #88
raphaelj wrote: post #8

Sadly, Python is a pretty poor functional language. The core of functional programming is about avoiding mutable states , not much about anonymous functions or passing functions as data. To do proper functional programming in Python, there should be IMO: - a way to enforce non-mutable variables/objects; - non-mutable collections; - proper support for recursion and tail-recursion optimization; - a better syntax for an…

> The core of functional programming is about avoiding mutable states, not much about anonymous functions or passing functions as data. I disagree since any paradigm can be done either with or without mutable state. So it is not something that defines functional programming. In any case you can also use immutable data types with python anyway. The main annoyance with python is in my opinion your last point: The lambd…

I use this approach [0]. Works well enough for me and is visually adequate for "piping"-style code.

0. https://sr.ht/~tpapastylianou/chain-ops-python/

Re: Functional Python Programming

#102

Post by chlorion »

kazinator wrote: post #93
chlorion wrote: post #92

Earlier quoted context omitted.

I do not think functional programming is about mutable state at all. It's about functions being first class values, nothing more. Lisp and Scheme are examples of functional languages that do not restrict mutability. The term for what you are talking about is pure functional programming!

I don't think this is correct. Programming languages with support for functional programming are not always pure functional languages. However, functional programming per se is always pure by definition; if you're mutating anything, it's not functional. (You can have "quasi functional" if you mutate only local variables, such that the black box view of your functions appears pure. Nobody knows whether the map functio…

Pure functional programming is always about purity, functional programming is about first class functions. Pure functional programming is a subset of functional programming, not the other way around.

I'm not really sure where you are getting your information from but everything that I have read disagrees with this idea that functional programming is about purity.

https://en.wikipedia.org/wiki/Functional_programming

I think in recent times the term functional programming has been overloaded to mean what you describe, and many people use it that way, but I don't think it should be used that way.

Maybe we should just say "non pure functional" or "pure functional" so it's always clear what we are talking about!

Re: Functional Python Programming

#103

Post by xapata »

Jeff_Brown wrote: post #57
xapata wrote: post #55

Earlier quoted context omitted.

Fundamentally? No, it's all just machine language in the end. Practically? Yes, generators are often more memory-efficient, and thereby often more compute-efficient.

Is it only about efficiency, and not expressivity? If so, can the compiler figure out where to transform my equivalent structures into iterators and generators?

The expressivity gain depends on what you're left with without the feature. It was hard for me to imagine where the previous comment draws the line around iterators and generators.

An optimizing compiler would need to know what actions are pure in order to rewrite code to be lazy. Python allows so much dynamism, I can only see that happening with a very sophisticated tracing JIT.

Re: Functional Python Programming

#104

Post by [deleted] »

chlorion wrote: post #102
kazinator wrote: post #93

Earlier quoted context omitted.

I don't think this is correct. Programming languages with support for functional programming are not always pure functional languages. However, functional programming per se is always pure by definition; if you're mutating anything, it's not functional. (You can have "quasi functional" if you mutate only local variables, such that the black box view of your functions appears pure. Nobody knows whether the map functio…

Pure functional programming is always about purity, functional programming is about first class functions. Pure functional programming is a subset of functional programming, not the other way around. I'm not really sure where you are getting your information from but everything that I have read disagrees with this idea that functional programming is about purity. https://en.wikipedia.org/wiki/Functional_programming I…

[deleted]

Re: Functional Python Programming

#105

Post by kazinator »

chlorion wrote: post #102
kazinator wrote: post #93

Earlier quoted context omitted.

I don't think this is correct. Programming languages with support for functional programming are not always pure functional languages. However, functional programming per se is always pure by definition; if you're mutating anything, it's not functional. (You can have "quasi functional" if you mutate only local variables, such that the black box view of your functions appears pure. Nobody knows whether the map functio…

Pure functional programming is always about purity, functional programming is about first class functions. Pure functional programming is a subset of functional programming, not the other way around. I'm not really sure where you are getting your information from but everything that I have read disagrees with this idea that functional programming is about purity. https://en.wikipedia.org/wiki/Functional_programming I…

Many mainstream programming languages implement procedures and functions with the same syntax, and call procedures functions. Procedures can take arguments and return a value, like functions, but also have side effects. Nobody asked for this terminology mixup; it just happened in the reference manuals of programming languages. Lisp calls procedures functions; so does C.

Programming with procedures isn't functional programming; it is procedural programming. This is true even when the procedures are first-class procedures, and are used in declarative patterns like mapping, reducing and so on. There is no word which refers to programming with first-class procedures in a declarative style. It is different from "Fortran-like procedural", and is rooted in OOP. First class procedures are objects; and in fact in many languages you can take a solution based on first class procedures and replace those procedures with objects. Mutated lexical variables become member variables (or slots) and so on.

The rhetoric in this area conflates two meanings of "pure" and "purely", causing equivocation.

- "pure X" as in "consisting of nothing but X" and "purely X" meaning "solely X"

- "pure" as in having no side effects: a pure expression can be replaced by its value without a change in meaning.

A "not purely functional language" uses "purely" in the former sense. The language emphasizes functional features, but has procedural features also. It doesn't refer to a language which emphasizes declarative programming patterns around first-class procedures, though such a language can fit the description.

A "not purely functional program" likewise: it emphasizes functional programming but has procedural bits in there. It doesn't refer to the program being composed entirely of the declarative use of higher order procedures, like mapping over collections while doing I/O or mutation and such.

If we take the value of a variable and then filter it through functional stages, only to then assign the transformed value into the same variable by assignment, that is an example of "not purely functional". The data transformation is functional; the assignment isn't.

Post reply on HN