3 ms·
I would much rather write the logic the author describes in Haskell than C. The C code will have to be carefully managed during development and maintenance to m
by chowells 6y ago
I would much rather write the logic the author describes in Haskell than C. The C code will have to be carefully managed during development and maintenance to make sure the side effects are happening in the expected order and that no changes ever introduce unexpected interleaving of mutation. The Haskell version will prevent that trivially. You can't even express doing it the wrong way, because you can't mutate anything.
Accidentally interleaved mutation is not a theoretical or academic problem. It's probably the number three source of production bugs in my dayjob's various products, behind misunderstood requirements and web browsers constantly changing the rules. It turns out that everyone, even people like me who know better and have been burned several times, will sometimes take the convenient shortcut. It's so tempting to get something done immediately by quietly mixing some mutation in an unexpected place, and it usually doesn't bite you. Then it gets ossified that way, and a year later starts biting you. This really does happen in code maintained by multiple developers over multiple years.
To be fair to the original post, though, Haskell has come a long way in making that kind of coding easy since 2007. The lens library didn't exist back then, and it's a big part of why data transformation programs are so much more pleasant in Haskell than most languages. It lets you express data access at the right level of abstraction. You get laws to enable algebraic reasoning and a broad range of utilities for composing small pieces together to solve complex problems.
- kkdaemas 6y agoOrder of execution bugs rarely come up in game programming to be honest.
- chowells 6y agoIf that's true, why is it an issue John Carmack discusses as affecting difficulty of writing games that work correctly in modern environments? > When you start thinking about running, say, all the characters in a game world in parallel, it starts sinking in that the object-oriented approach of updating objects has some deep difficulties in parallel environments. Maybe if all of the object just referenced a read only version of the world state, and we copied over the updated version at the end of the frame… Hey, wait a minute… https://gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php https://gamasutra.com/view/news/169296/Indepth_Functional_pr...
- yoyonamite 6y agoGames usually don't run the characters in parallel for the reasons Carmack stated. I believe he's arguing a hypothetical: if we want to maximize parallelization, what else can be parallelized? What patterns would or would not work in that case? There was a talk by Carmack where he brings up another challenge with parallelizing characters where two characters want to move to the same location.
- chowells 6y agoSo... Most games ignore modern hardware capabilities in order to support a fragile programming model? That doesn't sound like an argument against my point. My point was that mutation makes it harder to get code correct. If the only way you can do it is by refusing to use more than one thread of execution for calculating game state updates, that's not evidence that there's no problem with that approach. Of course, this does vary heavily by game. There certainly are games that run their world simulation across multiple threads. https://twitter.com/axelgneiting/status/1241487918046347264 https://twitter.com/axelgneiting/status/1241487918046347264 is a pretty awesome note about that in the Doom Eternal engine, for instance. But I'm certain getting that to work required very carefully controlling when and how mutation happens.