I really like John's perspective on things, he can take a listener or reader from the most abstract concepts to the nitty-gritty without losing focus. He's a tremendous asset to the programming world.
I agree with the second part of your sentence. I have watched every single one of his talks, and while I find them entertaining, I don't think his brain-dump style of communication is appropriate for teaching/instruction (to clarify: I use his talks as a springboard for my own discovery, not as a terminal point to aggregate knowledge).
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.
I wonder about the present state of the functional projects he talks about and is currently working on. A bit old, but good video talking about FP and static typing from a veteran perspective.
Would like to see a conversation between Sid Meier and Carmack, the modern Civ engines seem to have made some strides in stability methinks.
Interesting that he ran into friction exactly where you would expect him to.
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.
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: Everyone does this. I just think it's interesting.
No, I was commenting on statement, "everyone does this". What I was trying to say is that with effort, you can begin to identify times when you are biased toward a certain thing (in this case, different programming styles), and consciously choose to leave your emotions out of the equation.
Okay. Sorry, I'm used to reddit were everything is a veiled accusation.
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.
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.
He says it's a problem that can be tackled, it just hasn't been yet. Like you look at a square block, and you need to get it in a square hole, you just haven't gotten to it.
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.
Yes, and I'm curious how it turned out. Are there any followup talks on this that anybody knows about? It's certainly a solvable problem, but how many of the advantages remain once the data dependency problem is solved?
I think the crux of his point is really between constantly having to update state in a mutable way (with a decent probability of starvation and possibly deadlock) vs. pure functions, immutability and the async FP architecture he talked about. The advantage of the later is it brings maintainable code, and this stays true throughout the life of the code.
Off course, you'll have to hire or train FPers as he mentions.
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 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.
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 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.
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 immutable state like they do in non-FP languages.
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.
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.
It can only never happen if you use a lock correctly. In separate threads, this can absolutely happen in imperative programming. As a reader-writer or dining philosopher problem will show, two actors can try to do the same thing at the same time unless you EXPLICITLY stop them by using locks.
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.
I don't think the latter point is true. FP requires a lot of thinking up front, which is not how most engineers like to work.
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).
Which part? I think even John Carmack in the video talked about the upfront thinking required for FP. If every CS student learned category and type theory like they learn complexity theory; and FP compilers could optimize type classes and all the object creation, FP would definitely be more widely used. But, yes, there is definitely a cost to picking up FP today in almost any domain, but it's getting lower.
FP is not gonna wall you off from doing stuff like this. For example, and this is just off the top of my head, you could:
* 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.
I'm not arguing about which paradigm is better. I'm not saying theres no way around it. I'm just describing a single pitfall in the functional paradigm. That's all.
Being able to write asynchronous (multi-threaded or not) code so easily using FP is most definitely not a pitfall.
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.
>Being able to write asynchronous (multi-threaded or not) code so easily using FP is most definitely not a pitfall.
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.
Correct. But when things arrive at the same time and the same place "in game" the imperative programming style resolves this automatically by giving precedence to the object that was computed first, thus this problem is handled automagically in the imperative world. In fact you probably don't even have to really think about this issue when using the imperative style, unlike the functional style where this issue must be explicitly dealt with.
FYI I'm not saying either paradigm is worse or better, it is what it is.
I come back to this quote over and over when talking about desktop and mobile apps/games, especially since they tend to be highly state driven view collections and devs are always trying to come up with DRY patterns to bury important features in subclasses or helper utils.
> 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.
This is also simultaneously a strong argument for unit tests (which encode knowledge of that state into a proof of sorts).
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.
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 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.
Like most technical work, it saves money when done well and costs money when done poorly. Most people find themselves somewhere in the middle most of the time so it turns out the discussion is a little more nuanced than that.
Exactly! But it's so much easier to be an unyielding zealot than to think and understand why and if something is working.
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)
Engineers have to do work.. I would unit test core libs... I would also hire manual tester because they were very useful. I'd likely not chase down 100% automated coverage. The goal is to ship a game not have 100% coverage. And I work 100% pure tdd in my day job and side projects so take that for what it's worth.
It's an even stronger argument for Dijkstra's method of Design by Contract, esp with spec-based generation of tests. You not only document the intended behavior: you'll know exactly where it went wrong if any kind of testing violates one of the specs.
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 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.
Personally, I watched it with rapt attention throughout and I'm eagerly anticipating having time later to do so for the other 6 parts of the keynote. Can't remember the last presentation that captured me so. I think he is a very good public speaker and the talk did not meander and was not hard to follow in any way.
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" :)
imho this isn't specific to HN, Reddit is plagued by "downvote to disagree."
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.
You need to observe that the asymmetry is built into Hacker News itself, thereby contradicting the hypothesis that these are supposed to be symmetric actions. There is, now, no longer a downvote button against your comment here, for example; there is still an upvote button, though.
> You state your criticism like it's an objective fact, when in reality I'm sure most would disagree with you.
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 am not a native speaker. I watched the linked part while I was having my dinner (or whatever you'd call a couple of McBurgers at 10pm). I think it needs attention, but that is needed for anything that's not fluff.
> 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.
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.
TL;DR Famous game developer take an hour here and there and "makes himself" do "some stuff" in Haskell, looks back through some old code on another project that was written in a functional style and forgotten about; forgetting all the other working code that was forgotten about because FP is being discussed so why not and declares that FP is really good.
Haskell disciples on HN dig out this video which mentions FP among other unrelated topics and post it on HN as the definitive reason why all other programming methods should be abandoned in favor of FP, _because Carmack_.
Community cynic gets meta in sarcastic tone, not realizing it's undermining discourse, not contributing to. Outcome generally being that community cynic can carry around "I'm so smart" feeling all day.
While he says a lot of interesting things, it is too bad he is really just sitting and talking. No slides, gestures or any other facilities. Those would have brought more structure into the talk, making it easier to follow - especially for non-native speakers.
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 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.
While this may be true, please don't let it cause you to shy away from "full ramble mode" when the opportunity presents itself! I know I speak for many when I say that I have learned much from hearing these sorts of talks of yours over the years. Your willingness to share your wealth of experience is inspirational, regardless of the format.
Agreed, full ramble isn't something many people do well and it's fun too watch. Random but useful information will fall out of peoples brain and it's great!
Just to say, from my perspective I love your talks, zero distractions, just a long cogent train of thought to follow. Please don't feel the need to make too many changes.
Along the lines of 'functional' programming, Jonathan Blow reposted an old email of yours which I thought was a nice format for getting across some points about reliability, consistency, and minimizing side effects:
Actually I really like the format of your presentations: just yesterday I watched your live coding session with vrscript (https://www.youtube.com/watch?v=ydyztGZnbNs) and it was fantastic because, first, you were showing to your audience how to work with Racket (and some of the features in DrRacket), and second, you build from zero a demo in a very casual, easy going way. I honestly don't think that a standard slide-based presentation would have been better in any way...
Ha, it's funny because for me the format is just perfect. There are numerous presentations on the internet focused on one specific topic but your free form style is just like I'd talk with a friend. The interdisciplinary nature and hands on examples are nice added bonus.
Please don't change this unique approach too much.
For me, at least, it's not a problem that it doesn't optimally communicate targeted information. I watch talks like this for entertainment and maybe to pick up some information by osmosis and the undirected style is good for that. This was a very good talk by the way, and reinforced my positive feelings towards functional programming, thanks for doing it.
Actually I prefer it a lot more to something scripted. It's normally hard to stay focused watching a guy talking for 1 hour on a youtube video. But with your presentations, I find myself looking for more at the end of the hour!
Really interested in hearing if the ideas on how to transform game programming into a more productive form panned out. Did you end up using the ideas in a later product?
89 comments
[ 3.7 ms ] story [ 150 ms ] threadI 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.
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.
Would like to see a conversation between Sid Meier and Carmack, the modern Civ engines seem to have made some strides in stability methinks.
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.
> 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.
http://approvaltests.com/
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.
Haskell disciples on HN dig out this video which mentions FP among other unrelated topics and post it on HN as the definitive reason why all other programming methods should be abandoned in favor of FP, _because Carmack_.
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
[1] https://youtu.be/re96UgMk6GQ?t=31m22s