John Carmack on Functional Programming (2013) [video](youtube.com)
youtube.com
John Carmack on Functional Programming (2013) [video]
https://www.youtube.com/watch?v=1PhArSujR_A
89 コメント
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.
Please don't change this unique approach too much.
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...
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!
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:
http://number-none.com/blow/blog/programming/2014/09/26/carm...
http://number-none.com/blow/blog/programming/2014/09/26/carm...
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.
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.
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?
Your contributions to computing over the years more than outweigh any lack of preparation for a presentation.
I actually prefer your data dump continuous talking style. I find myself having a hard time paying attention in talks with lots of pauses or segues.
I really appreciate your insights because I'm dabbling in functional programming after 25 years of c/c++/objc
I really appreciate your insights because I'm dabbling in functional programming after 25 years of c/c++/objc
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!
Might not be the easiest if you intend to get a certain thought or point across but I really enjoy the format. Reminds me of long-form radio shows.
When exploring lisp, did you have a chance to play with Clojure?
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).
https://youtu.be/lHLpKzUxjGk
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 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.
He wrote a very good piece here: http://www.gamasutra.com/view/news/169296/Indepth_Functional... on the same topic (is it in fact the same?)
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.
> 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.
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.
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.
> there are all sorts of bits of code that don't really have strong "success criteria"
The approval testing model is really useful for this sort of stuff.
http://approvaltests.com/
The approval testing model is really useful for this sort of stuff.
http://approvaltests.com/
Why would unit testing cost extra? It saves money.
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)
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.
[deleted]
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.
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.
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.
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.
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.
> There is no concept of time in pure functions.
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.
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.
FYI I'm not saying either paradigm is worse or better, it is what it is.
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.
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.
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.
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.
* 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.
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?
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?
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.
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).
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.
Man. You are arguing with me as if I disagree. When did I bring up threads and locks? I'm just elucidating the problem Carmack brought up. Jesus.
[deleted]
He talked about a whole FP-powered architecture to solve this.
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.
Off course, you'll have to hire or train FPers as he mentions.
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.
To be clear: Everyone does this. I just think it's interesting.
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.
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.
You can train yourself to recognize this pattern in your own behavior.
Mhm. I try to. Why?
Are you implying I prefer functional programming? I don't. I don't have a horse in this race.
Are you implying I prefer functional programming? I don't. I don't have a horse in this race.
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.
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 actually starts here: https://youtu.be/1PhArSujR_A?t=2m7s
Should add (2013) and [video] to the title
[deleted]
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.
Would like to see a conversation between Sid Meier and Carmack, the modern Civ engines seem to have made some strides in stability methinks.
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.
Or more distracting and annoying.
The thing that's interesting about Haskell is that lazyness had a payoff of leading to the discovery of monad-based IO [1].
[1] https://youtu.be/re96UgMk6GQ?t=31m22s
[1] https://youtu.be/re96UgMk6GQ?t=31m22s
Has there been any progress on garbage collection since then?
He discusses GC in games starting here: https://youtu.be/1PhArSujR_A?t=1443
this is a best video to explain to your C++ friend why functional programming is worth it even in gamedev world.
C++ has been getting functional programming goodies since C++11.
Nowadays with C++17, functional programming in C++ is a common talk subject at C++ conferences.
Nowadays with C++17, functional programming in C++ is a common talk subject at C++ conferences.
that's nice, but generally speaking the mindset is still very much imperative.
Well, it is still a huge fight to get many devs to stop writing "C with C++ compiler" style anyway.
The C++ community that cares about C++Now, CppCon, ACCU kind of material, does care about applying functional programming ideas to their daily coding.
The C++ community that cares about C++Now, CppCon, ACCU kind of material, does care about applying functional programming ideas to their daily coding.
is it bad that I prefer C to all the shit in C++?
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++.
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++.
What is so simple about more than 200 documented cases of UB and all the ways one can write unsafe code without even knowing about it?
C++ has stronger type safety, offers the libraries and language features to only go down to C like unsafe coding as last resort.
C++ has stronger type safety, offers the libraries and language features to only go down to C like unsafe coding as last resort.
C + classes does the job for me. I hate decoding code - that's the compilers job!
scierama(1)
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.
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 downvoted you because:
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.
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.
> 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.
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.
HN's downvote mechanism is a funny one.
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" :)
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.
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.
Do you think upvoting something you agree with is a valid action? If yes, does it not follow that downvote to disagree is also valid?
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.
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).
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).
This was a keynote at a Quakecon, a conference for game players, not a technical presentation for software developers.
> 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.
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.
Perhaps native speakers enjoy this kind of talk a lot. I can't speak for others but I certainly did.
I don't feel that listening attentively for a couple of hours is that much of an imposition.
I don't feel that listening attentively for a couple of hours is that much of an imposition.
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.
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.