Live data from Hacker News

John Carmack on Functional Programming (2013) [video]

youtube.com

31–40 of 90 posts

Re: John Carmack on Functional Programming (2013) [video]

#31
post #10

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…

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.

Re: John Carmack on Functional Programming (2013) [video]

#32

Earlier quoted context omitted.

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 exec…

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 thing…

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.

Re: John Carmack on Functional Programming (2013) [video]

#33

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).

Re: John Carmack on Functional Programming (2013) [video]

#34
post #30
post #5

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.

that's nice, but generally speaking the mindset is still very much imperative.

Re: John Carmack on Functional Programming (2013) [video]

#35

Earlier quoted context omitted.

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 thing…

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.

Re: John Carmack on Functional Programming (2013) [video]

#36

Earlier quoted context omitted.

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 exec…

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 thing…

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.

Re: John Carmack on Functional Programming (2013) [video]

#37

Earlier quoted context omitted.

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 thing…

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…

> 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/

Re: John Carmack on Functional Programming (2013) [video]

#38
post #7

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 r…

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 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.

Re: John Carmack on Functional Programming (2013) [video]

#39
post #34
post #30

Earlier quoted context omitted.

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.

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.

Re: John Carmack on Functional Programming (2013) [video]

#40
post #26
post #10

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…

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 fir…

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.

Post reply on HN