7 ms·

Functional Programming in C++

246 points by rcfox 15y ago

cobrausn 15y ago
One of his comments kind of stuck out when I read it. ... but many object[s] are large enough to constitute a sort of global state all their own, blunting some of the clarity benefits of pure functions. I think we've all run into (and probably coded) our fair share of objects that were basically this - there is only one of them, and it has a lot of state associated with it. I never thought of it before as basically just encapsulating global state into an object. It almost seems... unavoidable, or at least really hard to avoid. Also this was hilarious. As an extreme example, you can write a pure DrawTriangle() function that takes a framebuffer as a parameter and returns a completely new framebuffer with the triangle drawn into it as a result. Don’t do that.
vilya 15y ago
I really liked this point: "Most developers are not very good at predicting the future time integrated suffering their changes will result in." So given a graph with time on the x axis and maintenance effort on the y axis, the area under the curve is the amount of suffering caused. That's a pretty good take-away.
- InclinedPlane 15y ago
  This is true at all levels. Acute damage gains much more attention than diffuse damage. Thus you have a common problem of developers taking "shortcuts" and accruing huge amounts of long-term technical debt in exchange for temporary short-term advantages, and you have the equally common problem of internal tooling that just barely gets the job done but also introduces massive amounts of waste of time and effort across the entire institution.
- im3w1l 15y ago
  I would argue for a discounting rate similar to the one economists use.
kibwen 15y ago
I was afraid this would be some sort of contorted framework to let you use C++ to write Lisp. Glad I was wrong. Carmack is spot-on here: "My pragmatic summary: 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. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible." Too often I've seen functional proponents, when asked why we ought to use functional languages, rely on facile arguments such as "it makes your code more concise, therefore easier to hold in your head" or "it makes your code more mathematical, and therefore easier to reason about". Like Rich Hickey, Carmack gets it right.
- bithive123 15y ago
  To me, "easier to hold in your head" is "easier to reason about". I can also imagine someone describing functional style (the thing Carmack says makes state presented to your code explicit) as "more mathematical".
  - kibwen 15y ago
    I wasn't saying that the example arguments I gave were necessarily invalid, only that they are remarkably uncompelling. Is functional style the only way to achieve concise code? Is "mathematical" code really the standard to which we ought to aspire? These questions, among others, are left unanswered. Essentially, a bad argument for functional programming says, "here is what functional programming does well; here is why that helps you". A good argument for functional programming says, "here is a very real problem that you have encountered; here is the remarkably effective way in which functional programming addresses it". Note the inversion, especially the focus on solving problems rather than on justifying paradigms.
- dons 15y ago
  "hold in your head" == minimizing complexity by minimizing the state space. "Mathematical" == stateless, pure functions. If the states are fewer, the code is simpler. I can only hold simple things in my head :) I think everyone's basically saying the same thing.
agumonkey 15y ago
Funny he doesn't quote Tim Sweeney :) http://lambda-the-ultimate.org/node/1277 http://lambda-the-ultimate.org/node/1277
lolcraft 15y ago
This is probably the best summary of functional programming, written by the best "pragmatical" programmer of the world. I wonder how much Haskell code Carmack must have written to reach this kind of knowledge... and whether it is open source. It would be a good read for the weekends. BTW, I think the pure keyword in C++ would be great. I wrote some C++ in school, and even I can tell that const, as applied to functions, could use some retirement. It's nonsense to keep this unmodified, stateless so to speak, but allow global variable assignation, and so on.
- evincarofautumn 15y ago
  Not entirely nonsense—immutability is helpful even in the absence of referential transparency—but still, a “pure” keyword would be great. Now, what I’d really like is for the type system to be flipped on its head with respect to immutability: make “const” the default and explicitly qualify mutable types with “mutable”. A guy can dream…
  - kibwen 15y ago
    Perhaps you should take a look at Rust.[1] It's a pretty compelling union of functional and procedural paradigms, plus: immutability by default, the ability to annotate functions as pure, pattern matching, option types, good C compatibility, strong support for concurrency, high-level memory management that guarantees memory safety and that doesn't require tedious memory micromanagement (while retaining the option to just GC everything and forget about it), and a lot more. Still alpha software at the moment, though. [1] http://www.rust-lang.org/ http://www.rust-lang.org/
    - evincarofautumn 15y ago
      I’ve looked into it. Seems like a promising language, and it does quite a few things right. Still, I feel a bit uncomfortable endorsing it wholesale while I work on my own linguistic magnum opus. ;)
    - zem 15y ago
      yeah, i'm excited about rust. i'm currently diving into d, and while it is a lot nicer than c++ (and i've barely started discovering all its features), i really miss pattern matching, option types and everything-is-an-expression, which i've gotten used to from other languages. it looks like rust supports all three of those features, which already puts it closer to my sweet spot.
Tossrock 15y ago
This headline isn't very descriptive; more useful might be "John Carmack discusses the practical benefits (and limitations) of a functional programming style."
fulafel 15y ago
For anyone wondering about adapting real world problems to FP style, here's an article about someone reimplementing pacman in FP: http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html
pestaa 15y ago
Great article, I love the way Carmack communicates. Can someone please explain how much of these performance worries is mitigated by C++11 move semantics? To me it seems like the functional style is becoming a possibility when one doesn't have to worry about the penalty of copy operations.
- sausagefeet 15y ago
  Not that much unless you're very disciplined in how you writ your code. Anything with more than one reference to it won't be usefully moveable.
- grout 15y ago
  A lot. Ignore comments to the contrary.
  - pestaa 14y ago
    I'd like to hear more, please?
rvkennedy 15y ago
I like this a lot because it summarizes the direction my own C++ has taken since I first learned about FP. I've found that making a member method functional (i.e. changing usage of member variables into passed parameters where reasonable - I never use globals) makes it more reusable from an OO point of view. The biggest gains by far have been in multithreaded programming.
tomrod 15y ago
I love the comment on here: "I do believe that there is real value in pursuing functional programming, but it would be irresponsible to exhort everyone to abandon their C++ compilers and start coding in Lisp, Haskell, or, to be blunt, any other fringe language. To the eternal chagrin of language designers, there are plenty of externalities that can overwhelm the benefits of a language, and game development has more than most fields."
- bitcracker 15y ago
  I disagree. Of course not _everybody_ can abandon C++ but some really can. I have developed C and C++ software for many years but with Racket Scheme (a functional language) I am MUCH more productive now. This works because I think and code functionally which is a totally different approach to the way how coding in C++ is done. I doubt that functional programming in C++ will be as elegant and effective as in a real functional language where everything is functional. The approach of C++ seems to be and to support "everything". But will that support more maintainable code? I don't think so. Quo vadis, C++? Btw Implementations like LuaJIT demonstrate that virtual machines have become amazingly fast. So, even for performance you don't need to be stuck to C++.

246 points by rcfox 15y ago

One of his comments kind of stuck out when I read it. ... but many object[s] are large enough to constitute a sort of global state all their own, blunting some of the clarity benefits of pure functions. I think we've all run into (and probably coded) our fair share of objects that were basically this - there is only one of them, and it has a lot of state associated with it. I never thought of it before as basically just encapsulating global state into an object. It almost seems... unavoidable, or at least really hard to avoid. Also this was hilarious. As an extreme example, you can write a pure DrawTriangle() function that takes a framebuffer as a parameter and returns a completely new framebuffer with the triangle drawn into it as a result. Don’t do that.

vilya 15y ago

I really liked this point: "Most developers are not very good at predicting the future time integrated suffering their changes will result in." So given a graph with time on the x axis and maintenance effort on the y axis, the area under the curve is the amount of suffering caused. That's a pretty good take-away.

InclinedPlane 15y ago
This is true at all levels. Acute damage gains much more attention than diffuse damage. Thus you have a common problem of developers taking "shortcuts" and accruing huge amounts of long-term technical debt in exchange for temporary short-term advantages, and you have the equally common problem of internal tooling that just barely gets the job done but also introduces massive amounts of waste of time and effort across the entire institution.
im3w1l 15y ago
I would argue for a discounting rate similar to the one economists use.

kibwen 15y ago

I was afraid this would be some sort of contorted framework to let you use C++ to write Lisp. Glad I was wrong. Carmack is spot-on here: "My pragmatic summary: 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. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible." Too often I've seen functional proponents, when asked why we ought to use functional languages, rely on facile arguments such as "it makes your code more concise, therefore easier to hold in your head" or "it makes your code more mathematical, and therefore easier to reason about". Like Rich Hickey, Carmack gets it right.

bithive123 15y ago
To me, "easier to hold in your head" is "easier to reason about". I can also imagine someone describing functional style (the thing Carmack says makes state presented to your code explicit) as "more mathematical".
- kibwen 15y ago
  I wasn't saying that the example arguments I gave were necessarily invalid, only that they are remarkably uncompelling. Is functional style the only way to achieve concise code? Is "mathematical" code really the standard to which we ought to aspire? These questions, among others, are left unanswered. Essentially, a bad argument for functional programming says, "here is what functional programming does well; here is why that helps you". A good argument for functional programming says, "here is a very real problem that you have encountered; here is the remarkably effective way in which functional programming addresses it". Note the inversion, especially the focus on solving problems rather than on justifying paradigms.
dons 15y ago
"hold in your head" == minimizing complexity by minimizing the state space. "Mathematical" == stateless, pure functions. If the states are fewer, the code is simpler. I can only hold simple things in my head :) I think everyone's basically saying the same thing.

agumonkey 15y ago

Funny he doesn't quote Tim Sweeney :) http://lambda-the-ultimate.org/node/1277 http://lambda-the-ultimate.org/node/1277

lolcraft 15y ago

This is probably the best summary of functional programming, written by the best "pragmatical" programmer of the world. I wonder how much Haskell code Carmack must have written to reach this kind of knowledge... and whether it is open source. It would be a good read for the weekends. BTW, I think the pure keyword in C++ would be great. I wrote some C++ in school, and even I can tell that const, as applied to functions, could use some retirement. It's nonsense to keep this unmodified, stateless so to speak, but allow global variable assignation, and so on.

evincarofautumn 15y ago
Not entirely nonsense—immutability is helpful even in the absence of referential transparency—but still, a “pure” keyword would be great. Now, what I’d really like is for the type system to be flipped on its head with respect to immutability: make “const” the default and explicitly qualify mutable types with “mutable”. A guy can dream…
- kibwen 15y ago
  Perhaps you should take a look at Rust.[1] It's a pretty compelling union of functional and procedural paradigms, plus: immutability by default, the ability to annotate functions as pure, pattern matching, option types, good C compatibility, strong support for concurrency, high-level memory management that guarantees memory safety and that doesn't require tedious memory micromanagement (while retaining the option to just GC everything and forget about it), and a lot more. Still alpha software at the moment, though. [1] http://www.rust-lang.org/ http://www.rust-lang.org/
  - evincarofautumn 15y ago
    I’ve looked into it. Seems like a promising language, and it does quite a few things right. Still, I feel a bit uncomfortable endorsing it wholesale while I work on my own linguistic magnum opus. ;)
  - zem 15y ago
    yeah, i'm excited about rust. i'm currently diving into d, and while it is a lot nicer than c++ (and i've barely started discovering all its features), i really miss pattern matching, option types and everything-is-an-expression, which i've gotten used to from other languages. it looks like rust supports all three of those features, which already puts it closer to my sweet spot.

Tossrock 15y ago

This headline isn't very descriptive; more useful might be "John Carmack discusses the practical benefits (and limitations) of a functional programming style."

fulafel 15y ago

For anyone wondering about adapting real world problems to FP style, here's an article about someone reimplementing pacman in FP: http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html

pestaa 15y ago

Great article, I love the way Carmack communicates. Can someone please explain how much of these performance worries is mitigated by C++11 move semantics? To me it seems like the functional style is becoming a possibility when one doesn't have to worry about the penalty of copy operations.

sausagefeet 15y ago
Not that much unless you're very disciplined in how you writ your code. Anything with more than one reference to it won't be usefully moveable.
grout 15y ago
A lot. Ignore comments to the contrary.
- pestaa 14y ago
  I'd like to hear more, please?

rvkennedy 15y ago

I like this a lot because it summarizes the direction my own C++ has taken since I first learned about FP. I've found that making a member method functional (i.e. changing usage of member variables into passed parameters where reasonable - I never use globals) makes it more reusable from an OO point of view. The biggest gains by far have been in multithreaded programming.

tomrod 15y ago

I love the comment on here: "I do believe that there is real value in pursuing functional programming, but it would be irresponsible to exhort everyone to abandon their C++ compilers and start coding in Lisp, Haskell, or, to be blunt, any other fringe language. To the eternal chagrin of language designers, there are plenty of externalities that can overwhelm the benefits of a language, and game development has more than most fields."

bitcracker 15y ago
I disagree. Of course not _everybody_ can abandon C++ but some really can. I have developed C and C++ software for many years but with Racket Scheme (a functional language) I am MUCH more productive now. This works because I think and code functionally which is a totally different approach to the way how coding in C++ is done. I doubt that functional programming in C++ will be as elegant and effective as in a real functional language where everything is functional. The approach of C++ seems to be and to support "everything". But will that support more maintainable code? I don't think so. Quo vadis, C++? Btw Implementations like LuaJIT demonstrate that virtual machines have become amazingly fast. So, even for performance you don't need to be stuck to C++.