5 ms·

> In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computat

> In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. from https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming I totally agree that neither iterators nor 2/3s of closures are "functional programming". That's fine, though, because I really enjoy the sane way that it all was done. If you check out https://doc.rust-lang.org/std/iter/trait.Iterator.html https://doc.rust-lang.org/std/iter/trait.Iterator.html and search for `FnMut`, you see that most of the iterator methods are side-effectful. That is cool and fun and very useful, but it isn't functional programming. Edit. The term you are probably looking for (guessing) is "higher-order programming": https://en.wikipedia.org/wiki/Higher-order_programming https://en.wikipedia.org/wiki/Higher-order_programming

steveklabnik 10y ago
Yeah that is one way of doing it, but I'm not sure how practically useful it actually is; many functional languages do allow for mutation and/or side effects too. Often in a controlled way, of course, but then again, so does Rust. That said, I wouldn't argue that Rust is a functional language exactly, mostly that I find essentialist FP definitions to be lacking, like most essentialist definitions. That said, you're right that "higher order" is a better description of these features, but my counter would be that most people perceive higher order programming as an aspect of functional programming, bringing it full circle again :)
- frankmcsherry 10y ago
  Most people perceive structs and fields as an aspect of object-oriented programming, but you probably wouldn't write about them under the heading of "Object-oriented programming". Maybe change the title to "Functional Language Idioms"?
  - steveklabnik 10y ago
    The "oh no OOP" chapter is later :) That's a good suggestion, I'll think about it, thanks :)
ben0x539 10y ago
`FnMut` just means that the iterator methods don't artificially restrict the user-supplied closures. `map` itself doesn't become impure just because you can map `|x| { counter += x; x+1 }` over your list if you really want to. I think it's fair to say that iterator methods are typically used as combinators to build computations out of pure functions to avoid having to manage mutable state.

steveklabnik 10y ago

Yeah that is one way of doing it, but I'm not sure how practically useful it actually is; many functional languages do allow for mutation and/or side effects too. Often in a controlled way, of course, but then again, so does Rust. That said, I wouldn't argue that Rust is a functional language exactly, mostly that I find essentialist FP definitions to be lacking, like most essentialist definitions. That said, you're right that "higher order" is a better description of these features, but my counter would be that most people perceive higher order programming as an aspect of functional programming, bringing it full circle again :)

frankmcsherry 10y ago
Most people perceive structs and fields as an aspect of object-oriented programming, but you probably wouldn't write about them under the heading of "Object-oriented programming". Maybe change the title to "Functional Language Idioms"?
- steveklabnik 10y ago
  The "oh no OOP" chapter is later :) That's a good suggestion, I'll think about it, thanks :)

ben0x539 10y ago

`FnMut` just means that the iterator methods don't artificially restrict the user-supplied closures. `map` itself doesn't become impure just because you can map `|x| { counter += x; x+1 }` over your list if you really want to. I think it's fair to say that iterator methods are typically used as combinators to build computations out of pure functions to avoid having to manage mutable state.