61–70 of 90 posts
I am aware that my presentations aren't optimal for communicating targeted information, and it does weigh on me more and more as the years go by. 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 effec…
Earlier quoted context omitted.
But one actor can always read the state of the other actor, and modify their actions accordingly. The state of each actor is immutable, so each action taken based on the state is sure to be conflict free. As opposed to imperative programming, were each actors position might not get updated correctly or in time until too late. Deadlock and starvation don't happen when you have pure functions with no side effects and i…
If two actors moved to one spot at the same time which actor occupies that spot? How can an actor act accordingly if they moved at the same time? 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.
Earlier quoted context omitted.
As I heard it, he talked about independent agents which traverse a world by taking it as an input and reporting their own state as an output, and how easy to code such a model was in functional languages because the world was immutable. You don't have to mess around with the world data to keep the actions in sync. Of course there's a level of conflict resolution needed at some point, which wasn't something he had not…
It's not about either. He is illustrating a problem that only occurs in 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 th…
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.
EDIT: Why all those downvotes? Are famous developers not supposed to criticized on HN? 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 lo…
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.
Earlier quoted context omitted.
Motivated reasoning. He prefers imperative programming (or something other than functional programming), so he hears the "criticism" without hearing the solution. I mean, of course he physically hears both, but one is prominent in his consciousness. It doesn't matter that there is a solution, he heard what he needed to hear to get the evidence he needs to maintain his bias, and shuts off his frontal lobe. To be clear…
You can train yourself to recognize this pattern in your own behavior.
Are you implying I prefer functional programming? I don't. I don't have a horse in this race.
Earlier quoted context omitted.
Motivated reasoning. He prefers imperative programming (or something other than functional programming), so he hears the "criticism" without hearing the solution. I mean, of course he physically hears both, but one is prominent in his consciousness. It doesn't matter that there is a solution, he heard what he needed to hear to get the evidence he needs to maintain his bias, and shuts off his frontal lobe. To be clear…
I think you misunderstand Carmack's position. As of this talk, he had not yet solved this problem, but he is optimistic that it can be solved, and ece mentioned the solutions he outlines. He goes on to say such a system would be beneficial to all game developers.
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.
Earlier quoted context omitted.
But one actor can always read the state of the other actor, and modify their actions accordingly. The state of each actor is immutable, so each action taken based on the state is sure to be conflict free. As opposed to imperative programming, were each actors position might not get updated correctly or in time until too late. Deadlock and starvation don't happen when you have pure functions with no side effects and i…
If two actors moved to one spot at the same time which actor occupies that spot? How can an actor act accordingly if they moved at the same time? 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.
Earlier quoted context omitted.
one of the hard things about game dev and testing is that there are all sorts of bits of code that don't really have strong "success criteria". A lot of it comes down to "did that feel good" or "does that look better" which is very hard to quantify in unit tests. 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…
Why would unit testing cost extra? It saves money.
Earlier quoted context omitted.
one of the hard things about game dev and testing is that there are all sorts of bits of code that don't really have strong "success criteria". A lot of it comes down to "did that feel good" or "does that look better" which is very hard to quantify in unit tests. 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…
Why would unit testing cost extra? It saves money.