John Carmack on Functional Programming (2013) [video]
youtube.com
youtube.com
So far, I haven't been able to justify to myself the time required to do a really professional job, so I just show up and talk for a few hours. I like to think there is some value in the spontaneity and unscripted nature, but I don't kid myself about it being the most effective way to communicate important information.
I'm taking some baby steps -- I at least made a rough outline to guide my talking at last year's Oculus Connect instead of being in full ramble mode.
http://number-none.com/blow/blog/programming/2014/09/26/carm...
Please don't change this unique approach too much.
I really appreciate your insights because I'm dabbling in functional programming after 25 years of c/c++/objc
I disagree. See the above link for a lecture where he describes the difficulties in VR in a manner that anybody with minimal programming experience can understand.
> 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.
The limit of a programmer is his/her brain's ability to contain all these possible states. Bugs always come from missing some mental modeling of state or having a flawed conception of it, either at the point of design, the version 1, or the rewrite.
OO just buries that state "elsewhere", so things seem easier superficially to contain mentally (but the state is still there, ready to get corrupted and pounce on you). FP makes the state explicit, so you're forced to deal with it at all times (this perhaps not uncoincidentally also makes FP easier to unit-test AND reason about). If managing that state upfront becomes unwieldy, then that becomes a good code smell/indicator that your design is suboptimal.
The upshot of all this is that I think that using FP in conjunction with unit-testing reduces bug production by some statistically-significant amount, especially as a codebase grows. We definitely need more empirical data about this, though. But that's what my intuition says.
However I think there's also a huge swath of code in games that can be unit tested. Scorekeeping systems, ai evaluation trees, etc. The industry as a whole has much more of an integration or manual testing bent focus than a unit testing one.
I will say that coming from a no tester all dev unit / integration test world to no automated test, 30-120 high skill manual tester world (30 gameplay testers, every other employee using new builds 2x daily), there is definitely something to having lots of really good manual testers with very short feedback loops. People noticed bugs that were hard to test for within 10-15 minutes of checkin on a regular basis.
Really if I did a studio I'd have both but then I'd likely be spending too much money and go out of business.
As I said above I'm a big advocate of tdd... Do it all the time. So when I say I wouldn't do it for parts of games maybe I have a reason (to gp not you)
The approval testing model is really useful for this sort of stuff.
He was talking about having the AI scripts running in different purely functional threads. Later (around 21 minutes in) he mentions what happens when two AIs decide to move to the same place at the same time, and has not figured out the solution.
Of course parallel programming is easy if you ignore the data dependencies, but eventually you run into unavoidable dependencies and your clean elegant system has to pick up some smell.
To be clear: Everyone does this. I just think it's interesting.
Are you implying I prefer functional programming? I don't. I don't have a horse in this race.
Yeah, you can train yourself, but everyone does it nonetheless. Everyone does it by default, and I don't think it's reasonable to claim that anyone has completely or effectively rid themselves of motivated reasoning.
I try to do this as much as possible, though. It usually ends up with me just having no opinions, rather than an "unbiased" one.
Though I'm not sure how effective training yourself in this way is. There have been studies that show it's difficult to induce this in people, but that statistical, of course. Some people likely take to it much better than others - some people may even take to it very well. I like to think I've had some success, but, you know, that might be motivated, so I don't really have a strong opinion.
It's not the language of someone that isn't confident that there isn't a perfectly fine solution. I mean, it's likely that other people have already figured this out, just not him.
Off course, you'll have to hire or train FPers as he mentions.
Of course there's a level of conflict resolution needed at some point, which wasn't something he had not figured out, but something that was out of line with the elegance and simplicity of how the basic game mechanics were implemented so far.
As I understood if, it's wasn't so much about easy parallel programming as it was his discovery of clean models and elegant solutions as encouraged by functional programming.
There is no concept of time in pure functions.
In imperative programming when two actors approach the same spot, whether the application is parallel or not, one actor ALWAYS arrives first and the other will arrive subsequently. Therefore the Second actor can read the state of the first and act accordingly...
This is not the case for functional programming. Per frame the state of each actor changes (or in other words: new actors with updated states are created) at the same time and thus you can have two actors approach the same spot at the same time. You will then need an extra step for conflict resolution. Of course there's a bunch of ways to deal with this. Carmack briefly mentioned something about using some other attribute of the actor as a priority number... it's not like this is some crazy issue that's impossible to solve.
Timing is harder to get right when everything is async, but if your game design is good, you just need to better implement it to get it right frame by frame. He also talks about having monads to handle things like this.
In functional programming this can happen... in imperative programming it NEVER happens, because the actors move imperatively, aka step by step or one at a time. This is the problem he is talking about.
In FP, you will have an immutable variable for state instead of a mutable variable wrapped in a lock. You will be passing a whole new immutable state variable to a pure side effect free function every time, and won't have to worry about getting a lock and releasing it explicitly (these would be side effects). As long as the state is immutable and synced across threads, actors in any thread can just plot their next actions using that state.
In imperative programming, like I said, you'll have to explicitly get and release locks to make sure two actors don't occupy the same spot.
So, if you use atomic immutable variables with pure functions, and the logic in your actors can be conflict free, you can have horizontal scalability across as many cores as you want pretty easily. If your actors cannot be conflict free, you will need to wrap a lock of your choice in a monad and use that, but you will still have gained better debugging, testing and maintainability by using FP.
Now if only every zero-cost OO abstraction had a straight forward FP alternative that was also zero-cost, we'd all be doing FP as of yesterday.
That's not to say that FP is at odds with iterative programming, but it means that you have to work out a "specification" of your code pretty completely from the beginning.
Although, even then it's not so bad because the excellent type systems and compilers mean you can develop the specification interactively (see Idris' typed holes).
* provide an explicit sequencing of when actors take their turns, passing updated resources to each in turn. This is your "step by step" imperative approach, and you're basically writing a main game loop. * don't sequence the actors, but implement a lock on the resource using a TVar. This is the simplest async approach. * many more approaches I haven't thought of
The point of FP is to be provide as much information about the logic of the program as possible. If two actors can move to the same point at the same time, then you need to write down logic to handle that case, whether actors move in sequence or independently.
Not writing down that logic because "I have an imperative language" is how you get bugs, especially race conditions.
Even in the most simple multi-threaded imperative programs, no compiler or hardware will give you almost any sort ordering guarantees by default. You have to use atomics or volatile or something else to get specific ordering guarantees. It's the same in FP compilers too.
Your point? You're saying this as if I disagreed with you. What are you trying to argue here? That FP is the better than imperative? Did I ever dispute that claim? Where are you going with this?
Very true, but there is a fundamental concept of time, almost by definition, in game-worlds.
Whereas in imperative programming it's true that one actor always arrives first in computation, he might not have arrived first "in the game": conflict resolution is still a necessity.
As such I don't think this is a problem that only occurs in functional programming.
It's my impression that it's the events up to any conflict are much cleaner to express functionally.
FYI I'm not saying either paradigm is worse or better, it is what it is.
Would like to see a conversation between Sid Meier and Carmack, the modern Civ engines seem to have made some strides in stability methinks.
Nowadays with C++17, functional programming in C++ is a common talk subject at C++ conferences.
The C++ community that cares about C++Now, CppCon, ACCU kind of material, does care about applying functional programming ideas to their daily coding.
Now I don't even write C/C++ regularly, so my opinion is probably shit. But I really like the simplicity of C over all the features of C++.
C++ has stronger type safety, offers the libraries and language features to only go down to C like unsafe coding as last resort.
While John has a lot of interesting things to say, the presentation is awful, almost an imposition to the audience.
There's not a single slide, or any repetition to clarify structure, or any notable gestures to make up for that. A simple overview, just a damn simple list of keywords, would already go a long way. That would add a lot of structure and would make the talk so much easier to follow, especially for non-native speakers.
Just because one is so much respected by the audience that they will tolerate everything, one should not act like the audience will tolerate everything.
I did crank the playback speed up a lot though, which helps considerably (I'm not sure I would enjoy it half as much if it were live, where of course I have to hear it at 1x speed).
As far as I know there's no clear meaning to what a downvote means and it seems like everyone has their own definition.
For some, downvoting is a way of "flagging" out of place comments, aggressive ones, etc. However for others it's just a way of disagreeing.
The guidelines don't seem to establish any particular definition to it, so it's kind of a community-driven thing.
At first I was certain that downvoting was a way for the crowd to silence unwanted comments, but "unwanted" has many values depending on the person. Personally, I prefer to downvote when there are clearly aggressive or out-of-place comments, and if I disagree I rather respond with my disagreement. That's the way to have a civil discussion in my opinion.
However, like I said, other people give downvoting a different meaning, so it's not so much that you can't criticize famous celebrities, but that the community seems to disagree with you. I don't see anything "flaggable" about your post so that's why I assume it's the reason.
But again, downvoting is an "undefined" behavior in HN. Guidelines don't mention what shoul or should not be downvoted so it's kind of up for debate.
Don't worry too much about it, as long as you are not clearly being uncivil, downvotes are probably just a lazy way of saying "I don't agree with you" :)
Downvoting should be for, as you said, flagging aggressive, off-topic comments.
I've really lost interest in commenting on reddit, because if you say anything that disagrees with or goes against a certain sub-reddits current group think on a subject, you're just going to get downvoted into oblivion. It really just intensifies the echo-chamber effect.
1. You state your criticism like it's an objective fact. I think it was a brilliant talk.
2. Your edit. It violates the HN guidelines and you insinuate people only downvote you because they are Carmack fans.
He stated his opinion, it's how people discuss things. Ironically, by saying "in reality, I'm sure most would disagree with you", you do the same thing (express your opinion as if it is fact), AND use the weasel words of "in reality" to add gravitas to your opinion. I didn't like the talk either FWIW.
I don't feel that listening attentively for a couple of hours is that much of an imposition.
He gives these talks because there's a demand for them (from previous audiences). He's not on stage talking because he wants to force people to consume the information.
I suspect it's a trade-off between a talk of this format or no talk at all. Preparing slides etc. takes a time investment, and if it takes too much time, maybe he just wouldn't be able to do the talks.