Timeline for How would Functional Programming proponents answer this statement in Code Complete?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 6, 2021 at 15:24 | comment | added | Fl0v0 | I just stumbled across this answer in 2021 and realized that you basicalliy used the redux pattern before it was cool :D | |
| Jan 13, 2012 at 0:25 | comment | added | mikera | @dan - you still have encapsulation, it's just that the encapsulation of behaviour happens in functions rather than in the data objects. So you still have a function like (move player map from-position to-position) which encapsulates all the necessary behaviour. | |
| Jan 12, 2012 at 14:41 | comment | added | dan | @mikera Thanks for the code example. So players (and their points, positions, etc.) are just dumb data structures nested in a big game state data structure? Doesn't that reduce the encapsulation between players and their behavior and other moving parts of the game? | |
| Jan 12, 2012 at 11:24 | comment | added | quant_dev | @mikera "The reason functional languages will ultimately offer superior performance is that we have come to the end of the line for single core performance, and it will all be about concurrency and parallelism in the future" - That's short sighted. We may have reached the end of the line for silicone-based cores. That's all. There's lots of research in different techologies (spintronics, quantum computing, adiabatic computing) which may provide unimaginable breakthroughs in single-core performance. | |
| Jan 12, 2012 at 11:21 | comment | added | mikera | @quant_dev - it's not an excuse, it's a mathematical and architectural fact that you are better having a incurring a constant overhead if you can make up for it by scaling your performance near-linearly with the number of cores. The reason functional languages will ultimately offer superior performance is that we have come to the end of the line for single core performance, and it will all be about concurrency and parallelism in the future. functional approaches (and immutability in particular) are important in making this work. | |
| Jan 12, 2012 at 11:13 | comment | added | deworde | @quant_dev More cores are cheaper than better cores... escapistmagazine.com/news/view/… | |
| Jan 12, 2012 at 11:02 | comment | added | quant_dev | @mikera "Give me a enough cores and I'll beat your single-threaded C++ game engine" -- with such statements one can excuse performance problems of any magnitude. | |
| Jan 12, 2012 at 10:52 | comment | added | Donal Fellows | @JoonasPulakka: It's not just Clojure that uses that trick. It's heavily used in Tcl's implementation too, and has been for about 15 years. | |
| Jan 12, 2012 at 8:41 | history | edited | mikera | CC BY-SA 3.0 |
added 271 characters in body
|
| Jan 12, 2012 at 8:16 | comment | added | Joonas Pulakka | @Mason Wheeler: Actually, it is possible to get virtually equal (as good as with mutation) performance with immutable objects, without much GC at all. The trick in Clojure is using persistent data structures: they're immutable-to-the-programmer, but actually mutable under the hood. Best of both worlds. | |
| Jan 12, 2012 at 6:06 | comment | added | mikera | Of course games are hard with immutability - that's why I chose it to demonstrate that it can still work! However you'd be surprised what persistent data structures can do - most of the game state doesn't need to be rebuilt, only the stuff that changes. And sure there is some overhead, but it's only a small constant factor. Give me a enough cores and I'll beat your single-threaded C++ game engine..... | |
| Jan 12, 2012 at 5:51 | comment | added | Mason Wheeler | I would think a game is one of the worst possible examples to demonstrate the supposed "benefits" of enforced immutability. Things are constantly moving around in a game, which means you've got to be rebuilding your game state all the time. And if everything is immutable, that means that you have to not only rebuild the game state, but everything in the graph that holds a reference to it, or that holds a reference to that, and so on recursively until you're recycling the entire program at 30+ FPS, with tons of GC churn to boot! There's no way you get good performance out of that... | |
| Jan 12, 2012 at 5:33 | history | answered | mikera | CC BY-SA 3.0 |