我觉得这是这个问题的特例,我觉得这是特别相关的。
我正在开发适用于Android的游戏,并且正计划在libgdx中使用Scala。我正计划制作一款性能出色的游戏,但不一定是高性能游戏。我看过libgdx关于Garbage Collection的文档,这使我想到:
- 函数式编程意味着许多不可变的对象。
- 因此,使对象变异需要制作一个新对象。
- 因此,许多对象会被垃圾回收,从而降低性能。
这是一个无法解决的问题吗?Android上的功能样式是否还有其他重大问题?
我觉得这是这个问题的特例,我觉得这是特别相关的。
我正在开发适用于Android的游戏,并且正计划在libgdx中使用Scala。我正计划制作一款性能出色的游戏,但不一定是高性能游戏。我看过libgdx关于Garbage Collection的文档,这使我想到:
这是一个无法解决的问题吗?Android上的功能样式是否还有其他重大问题?
Answers:
为了游戏?避免使用功能性语言。他们的整个范例无法与游戏完美融合。程序上的OOP语言更适合游戏对频繁状态更改,显式内存和资源管理,在许多地方有用的数据和模型的抽象,在某些系统中面向数据的设计等的需求。功能元素是一回事,真正的功能语言是另一回事。
与Java或C ++相比,性能最佳的Android功能语言仍会提供较差的开发体验。并不是因为这些语言都是周围更好的语言,而是因为它们对于手头的特定任务是更好的。适用于这项工作的工具。
在移动设备,PC,控制台等上都是如此。没有人在游戏中使用功能语言。顽皮狗使用LISP 编写脚本,但不使用核心游戏代码。他们不能。如果他们尝试,那是行不通的。
人们最接近的着色器是着色器,它在某些方面可以起作用,但是是以高度程序化的语言(例如HLSL或GLSL)编写的。
For gaming? Avoid functional languages. Their entire paradigm fails to mesh well with games.
实际上,我读过一些知名游戏开发人员的文章,这些文章表达了对函数式编程的兴趣。Tim Sweeney 撰写了一篇scribd.com/doc/5687/…,约翰·卡马克(John Carmack)似乎对评估函数式语言很感兴趣,目前正在Haskell进行Wolfenstein 3d移植,tinyurl.com / cnzx57u
Practically all of the run-time code (approximately half a million lines of source code) was written in GOAL (Game Object Assembly Lisp)