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