4 ms·

Basically he says you can't really do that in c++, because of performance (which is crucial otherwise why u use c++; last part is my addition)

nielsbot 6y ago
Is that what he says? I thought he said “As functional as makes sense, but not more.” I haven’t read this post in a while, but it’s definitely a worthwhile read.
- Jtsummers 6y ago
  Your interpretation is correct. He describes things that you shouldn't try to imitate in C++ (like appending an element to a vector by creating a copy and then appending to that). But also describes other situations where having a pure (or near-pure) functional version can be greatly beneficial. Like a method on vectors (math sense) that return a normalized version, or adding string methods which return a copy rather than mutate in place (think: upcased versus upcase).
- andi999 6y ago
  Yes, that's what he also says, but this works best for very simple parameters. If things get interesting and you have bigger data structures there is (too much) performance penalty. I am a bit cherry picking here, but let me just cite "Actual functional languages are implemented in ways that make this not as disastrous as it sounds, but if you do this with typical C++ containers you will die."
  - Jtsummers 6y ago
    He's specifically referring to one thing that shouldn't be done in a functional style in C++, not saying "you can't really do that" as you originally post. The rest of the article is advocating a move towards pure-r functions in C++ (at least in addition to impure, mutating functions).
    - andi999 6y ago
      Maybe I come from a different direction, lots of data. If you do any functional programming on these you are creating new lists/vectors (the type) left and right. To me this is the gist of functional programming. So when I started the article, I was wondering how would you do that in c++, well his answer is you shouldn't. So when you are saying it is just one thing for me it is like a car without an engine (also only missing one thing). (the other thing about functional programming is the widespread use of recursion, but this is not even mentioned in the article)
  - neuromanser 6y ago
    I can't tell if your reading comprehension is completely shot, or if you're willfully misrepresenting the drift of the article.

nielsbot 6y ago

Is that what he says? I thought he said “As functional as makes sense, but not more.” I haven’t read this post in a while, but it’s definitely a worthwhile read.

Jtsummers 6y ago
Your interpretation is correct. He describes things that you shouldn't try to imitate in C++ (like appending an element to a vector by creating a copy and then appending to that). But also describes other situations where having a pure (or near-pure) functional version can be greatly beneficial. Like a method on vectors (math sense) that return a normalized version, or adding string methods which return a copy rather than mutate in place (think: upcased versus upcase).
andi999 6y ago
Yes, that's what he also says, but this works best for very simple parameters. If things get interesting and you have bigger data structures there is (too much) performance penalty. I am a bit cherry picking here, but let me just cite "Actual functional languages are implemented in ways that make this not as disastrous as it sounds, but if you do this with typical C++ containers you will die."
- Jtsummers 6y ago
  He's specifically referring to one thing that shouldn't be done in a functional style in C++, not saying "you can't really do that" as you originally post. The rest of the article is advocating a move towards pure-r functions in C++ (at least in addition to impure, mutating functions).
  - andi999 6y ago
    Maybe I come from a different direction, lots of data. If you do any functional programming on these you are creating new lists/vectors (the type) left and right. To me this is the gist of functional programming. So when I started the article, I was wondering how would you do that in c++, well his answer is you shouldn't. So when you are saying it is just one thing for me it is like a car without an engine (also only missing one thing). (the other thing about functional programming is the widespread use of recursion, but this is not even mentioned in the article)
- neuromanser 6y ago
  I can't tell if your reading comprehension is completely shot, or if you're willfully misrepresenting the drift of the article.