3 ms·

>Basically as I understand it functional languages must internally "cheat" all the time, because they must run on top of non-functional hardware abstractions.

>Basically as I understand it functional languages must internally "cheat" all the time, because they must run on top of non-functional hardware abstractions. By cheating I mean functions must eventually execute a side effect and that side effect is usually mutating state. The IO monad is a cheat depending on your perspective. The very pixels on your screen are entities with states: RGB which even a "pure" program like haskell will be modifying. What haskell does is call these pixels IO and it segregates the actual mutation from the rest of the program. This is just my opinion but the main benefits of functional programming lie not in performance but in organization of code or what most programmers refer to as "design." If you're looking for extreme performance FP is not the the way to go. Assembly language is the way to go, but even before that I would pick a procedural language like C long before I use an FP language.

whateveracct 7y ago
Choosing a language for performance first when developing your game is silly. Many games (even AAA) have a lot of logic in some interpreted language. Haskell or Idris can be the equivalent of these (and they're way more performant) and you can easily writing custom asm or C or Rust or whatever via their (very good!) FFIs. But saying "oh computers are inherently mutable" is a pretty worthless and shallow statement. Nothing about that precludes FP, and FP works fine in those settings (Haskell can definitely approach C level performance if you know what you're doing) But you're right that nothing about FP is for performance. I don't think anyone would assume Haskell is inherently faster than C. It makes no sense. The closest you could say is some immutable data structures enable performance without much effort in certain use-cases.
- crimsonalucard 7y ago
  >Choosing a language for performance first when developing your game is silly. It is absolutely not. Components of the game can be done with an interpreted language but if performance is key, which it is for triple A games, then the core language is important. Scripting languages in games tend to deal with IO a lot. If your program contains too much IO it negates almost all the benefits of FP. Procedural programming is better for modeling temporal phenomena which is the core subject of what most of these "scripts" are attempting to model. >But saying "oh computers are inherently mutable" is a pretty worthless and shallow statement. I beg to differ. Saying otherwise is the worthless and shallow statement. >Nothing about that precludes FP, and FP works fine in those settings (Haskell can definitely approach C level performance if you know what you're doing) There are many things that hinder it but not preclude it. By common sense in general, it is harder for FP to get more performance out of the system. The logic is simple, the functor from functional programs to assembly language programs cannot be written in a way where it is bijective meaning that functional primitives have to map to another category where the objects are ordered tuples of multiple assembly language commands. In C you can very much write a program that is in spirit bijective with assembly. By that logic FP in general will be harder to control because every FP primitive means an almost unpredictable amount of assembly instructions. Performance improvements will tend to appear as leaky abstractions or hacks in FP. Especially with the call by need model in Haskell optimization is even harder.

whateveracct 7y ago

Choosing a language for performance first when developing your game is silly. Many games (even AAA) have a lot of logic in some interpreted language. Haskell or Idris can be the equivalent of these (and they're way more performant) and you can easily writing custom asm or C or Rust or whatever via their (very good!) FFIs. But saying "oh computers are inherently mutable" is a pretty worthless and shallow statement. Nothing about that precludes FP, and FP works fine in those settings (Haskell can definitely approach C level performance if you know what you're doing) But you're right that nothing about FP is for performance. I don't think anyone would assume Haskell is inherently faster than C. It makes no sense. The closest you could say is some immutable data structures enable performance without much effort in certain use-cases.

crimsonalucard 7y ago
>Choosing a language for performance first when developing your game is silly. It is absolutely not. Components of the game can be done with an interpreted language but if performance is key, which it is for triple A games, then the core language is important. Scripting languages in games tend to deal with IO a lot. If your program contains too much IO it negates almost all the benefits of FP. Procedural programming is better for modeling temporal phenomena which is the core subject of what most of these "scripts" are attempting to model. >But saying "oh computers are inherently mutable" is a pretty worthless and shallow statement. I beg to differ. Saying otherwise is the worthless and shallow statement. >Nothing about that precludes FP, and FP works fine in those settings (Haskell can definitely approach C level performance if you know what you're doing) There are many things that hinder it but not preclude it. By common sense in general, it is harder for FP to get more performance out of the system. The logic is simple, the functor from functional programs to assembly language programs cannot be written in a way where it is bijective meaning that functional primitives have to map to another category where the objects are ordered tuples of multiple assembly language commands. In C you can very much write a program that is in spirit bijective with assembly. By that logic FP in general will be harder to control because every FP primitive means an almost unpredictable amount of assembly instructions. Performance improvements will tend to appear as leaky abstractions or hacks in FP. Especially with the call by need model in Haskell optimization is even harder.