[HN Gopher] Functional programming in C++ (2012)
___________________________________________________________________
Functional programming in C++ (2012)
Author : tosh
Score : 74 points
Date : 2020-12-28 20:22 UTC (2 hours ago)
(HTM) web link (gamasutra.com)
(TXT) w3m dump (gamasutra.com)
| andi999 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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."
| neuromanser wrote:
| I can't tell if your reading comprehension is completely
| shot, or if you're willfully misrepresenting the drift of
| the article.
| Jtsummers wrote:
| 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).
| keyle wrote:
| That post is on multiple websites and I think it's one of the
| best written one by Carmack because it hits home directly (it
| applies to software as well as games). I think it gets posted
| once a year on HN. No regret though I don't mind an echo chamber
| of good thoughts.
| seanalltogether wrote:
| > A large fraction of the flaws in software development are due
| to programmers not fully understanding all the possible states
| their code may execute in.
|
| I think about this quote often in my day to day programming.
| Object oriented programming is so full of stateful objects and
| it's easy for programmers to add listeners to all sorts of
| events. Even on the cloud side now you have all these micro
| services and trigger functions and small changes can have
| cascading consequences.
| jimbob45 wrote:
| "The lack of any language support in C++ for maintaining purity
| is not ideal."
|
| I get that C++ is already bloated and bolted on to C as is but I
| would have preferred to see changes like these instead of sugary
| bloat like "auto". Adding a "pure" keyword allows testability not
| otherwise attainable without modifying the compiler. Adding
| "auto" is just a me-too to the "var" of C# and Java.
|
| Basically, I'm trying to say that C++ needs to have its standards
| committee fired.
| thechao wrote:
| The stds committee is similar to a regulatory capture
| situation: all the people who really cared gave the fuck up.
| flatline wrote:
| I can say this is not true for the general case. C++ has -
| against the odds, in my opinion - been dragged kicking and
| screaming into the 21st century. It is not exactly design by
| committee, because there are a lot of (semi)independent
| developers driving the design choices. The choice of features
| for a given release is by committee, however, and reflects a
| wide variety of opinions and interests. Not the least of
| which are the people actually providing compiler support.
| Functional programming in C++ is still not always facilitated
| by the standard library, but it's miles beyond where it was a
| decade ago: moving in the right direction.
| voldacar wrote:
| D has a "pure" keyword and it works quite nicely. Agreed about
| the standards committee lol
| moonchild wrote:
| D's pure doesn't work very well at all.
|
| Because there's no ecosystem of pure functions, a single
| impure function in the transitive closure of your
| dependencies can ruin your day. (Unless you depend on no code
| written by other people.)
|
| Compare with haskell, where effects are enumerated and purity
| is the default: most functions are pure.
| posharma wrote:
| I wonder if there's a modern c++ version of this somewhere.
___________________________________________________________________
(page generated 2020-12-28 23:00 UTC)