关于脚本语言的问题
37 views
Skip to first unread message
清风雨
May 20, 2008, 11:44:36 PM5/20/08
to TopLanguage
是这样的，我一直对脚本语言持怀疑态度；而在网上看到的理由，又感觉比较概念抽象，不够细化；可能是我没有实际体会，所以感触不深。最近的项目用到了脚
本，但我感觉到的好处更多的是它做为配置性参数上的，它便于快速试验；而在调试、查错上到不如C++借助IDE了；对于简单的逻辑、流程控制，对于脚本
使用而言，都需要导出大量的接口函数；对于复杂的控制，脚本显然更是力所难及了（举个相对复杂的：如UI的效果制作，似乎脚本也起不了太大作用，只有对
于位置等简单的参数性控制是很有优势。要么导出大量的接口，实际上如果这么做，还不如直接用C/C++实现更省力）；因为接口的导出，那么也就意外着想
用脚本应付项目未来的变化，是行不通的，因为没有应用层的接口，他做不了太多的事。
以前用过两个脚本，一个是kele8的fcc，它已经上升成为项目的制作言语，而非辅助地位；一个是Torque的cs脚本，说真的，简直就像用c实现
c++的原理，还有调试器，整体感觉还不如直接用C或C++，现在回想起来，他的好处只有极大的缩短了编译连接时间这点了。
所以，想请教大家，脚本的好处有哪些，适合用在哪些情况？最好能举些实际的例子和情况。
现在项目中使用的是LUA，因为轻量级，而且集成lua的项目很多，据说“魔兽世界”就用了lua。我知道还有一个脚本语言叫angelscript
(http://www.angelcode.com/angelscript/ )，也是轻量级的，而且从集成角度，比lua更容易，语法上类C/C
++/Java。
显然，我比较倾向后者，但由于对于脚本这块比较缺乏经验，想看看各位的看法和评估。
张鹏程
May 20, 2008, 11:56:59 PM5/20/08
to pon...@googlegroups.com
我的体会也不多，不过最近感觉脚本真的不错！
1、基于文本。这一点初看起来没有什么好处，不过，就个性方便来说，是编译型语言所不能比的。
2、编写容易。一行管道代码相当于10000行C代码。
3、方便维护。这基说第一点的。
在处理复杂问题时，脚本语言当然没有什么优势。但脚本语言多说都是DSL，在这些方面，无论是编写还是阅读，都非常有优势。
把语言用的它应该用的地方，才能发挥它的优势。在不怎么要求性能，需要经常修改，特别是在交付后需要修改的地方，用一下脚本，我觉得还是挺合适的。
在08-5-21，清风雨 <zhang...@gmail.com> 写道：
清风雨
May 21, 2008, 12:05:11 AM5/21/08
to TopLanguage
On 5月21日, 上午11时56分, "张鹏程" <holmesco...@gmail.com> wrote:
编写容易，怎么讲？因为我没有这个体会，能举几个具体例子嘛？
基于文本的说法，这个应该是一个优势。
张鹏程
May 21, 2008, 1:08:18 AM5/21/08
to pon...@googlegroups.com
因为这些语言都为专有领域提供一些特殊的语法和语言功能，所以写起来容易一点。
简单的例子有字符串的连接和在字符串内的变量扩展。
在08-5-21，清风雨 <zhang...@gmail.com> 写道：
katkat lim
May 21, 2008, 4:13:22 AM5/21/08
to pon...@googlegroups.com
我觉得脚本语言是表达思想的一种很强有力的方法。
在描述思路上，要比C++或者别的编译型语言方便多了。
王宁
May 21, 2008, 5:11:07 AM5/21/08
to pon...@googlegroups.com
2008/5/21 清风雨 <zhang...@gmail.com>:
是这样的，我一直对脚本语言持怀疑态度；而在网上看到的理由，又感觉比较概念抽象，不够细化；可能是我没有实际体会，所以感触不深。最近的项目用到了脚
本，但我感觉到的好处更多的是它做为配置性参数上的，它便于快速试验；而在调试、查错上到不如C++借助IDE了；对于简单的逻辑、流程控制，对于脚本
错误少了几个量级，不易调试又何妨？ 当然，前提是正确设计和单元测试。
使用而言，都需要导出大量的接口函数；对于复杂的控制，脚本显然更是力所难及了（举个相对复杂的：如UI的效果制作，似乎脚本也起不了太大作用，只有对
描述UI是脚本的强项：Tcl, Js/Ajax, XAML... 但肯定受到底层系统的限制。 比如你想给Firefox写一个删除本地系统文件的插件，或者当用户输错密码时从LCD伸出一只手扇他（她）一个耳光，等等。关键问题不在于脚本是否能够包打天下，而在于它是否适合实现你的需求。
于位置等简单的参数性控制是很有优势。要么导出大量的接口，实际上如果这么做，还不如直接用C/C++实现更省力）；因为接口的导出，那么也就意外着想
用脚本应付项目未来的变化，是行不通的，因为没有应用层的接口，他做不了太多的事。
对软件项目来说，未来绝对不是无限的，变化也不是无穷无尽的。
以前用过两个脚本，一个是kele8的fcc，它已经上升成为项目的制作言语，而非辅助地位；一个是Torque的cs脚本，说真的，简直就像用c实现
c++的原理，还有调试器，整体感觉还不如直接用C或C++，现在回想起来，他的好处只有极大的缩短了编译连接时间这点了。
所以，想请教大家，脚本的好处有哪些，适合用在哪些情况？最好能举些实际的例子和情况。
除了效率不行，哪儿都好，呵呵。
清风雨
May 21, 2008, 5:20:13 AM5/21/08
to TopLanguage
继续追问几个问题：
1. 在服务器应用这个场合上，选用哪个脚本会比较适合，用在哪部分，用于做什么。—— 听说“大话西游”用了Python，后来换了lua，而且还用
来做压缩（就这点我似乎更倾向用非脚本方式、插件方式dll或so）。
如果是做配置型，差别可能不大。如果想用脚本参与部分逻辑、流程、甚至网络底层、消息处理的话，差别就会比较大了。除了性能，还有易用
性。对于lua而言，我暂时没有感觉到它在这方面的优势。
2. 如果做界面和表现，又选用哪个比较合适。
对应界面布局，因为脚本修改的便捷，是存在很多优势。如果想用脚本做一些效果的控制呢？或者我还不只是想做效果控制，让他做更多的事，可以
做到怎样。
3. 把这两者放在一起，那么又选哪个呢。
如果分开考虑，可能会得到不同的结果，将两者结合起来考虑，又是怎样的结果。
4. 有没有谁帮忙能比较一下lua和angelscript。
我考到后者对比基于栈的lua集成起来更方便，语法更便于拥有C/C++/Java基础的广大群体。但，了解毕竟不深，而且不具备经验，也只
考虑到了这两个方面。
因为，我是做游戏的，这几个问题和游戏技术结合的比较紧密一点。我在想可能我实际遇到的麻烦是：该不该选，选谁，选了做什么，怎么做，做到怎样。
1. 在服务器应用这个场合上，选用哪个脚本会比较适合，用在哪部分，用于做什么。—— 听说“大话西游”用了Python，后来换了lua，而且还用
来做压缩（就这点我似乎更倾向用非脚本方式、插件方式dll或so）。
如果是做配置型，差别可能不大。如果想用脚本参与部分逻辑、流程、甚至网络底层、消息处理的话，差别就会比较大了。除了性能，还有易用
性。对于lua而言，我暂时没有感觉到它在这方面的优势。
2. 如果做界面和表现，又选用哪个比较合适。
对应界面布局，因为脚本修改的便捷，是存在很多优势。如果想用脚本做一些效果的控制呢？或者我还不只是想做效果控制，让他做更多的事，可以
做到怎样。
3. 把这两者放在一起，那么又选哪个呢。
如果分开考虑，可能会得到不同的结果，将两者结合起来考虑，又是怎样的结果。
4. 有没有谁帮忙能比较一下lua和angelscript。
我考到后者对比基于栈的lua集成起来更方便，语法更便于拥有C/C++/Java基础的广大群体。但，了解毕竟不深，而且不具备经验，也只
考虑到了这两个方面。
因为，我是做游戏的，这几个问题和游戏技术结合的比较紧密一点。我在想可能我实际遇到的麻烦是：该不该选，选谁，选了做什么，怎么做，做到怎样。
Googol Lee
May 21, 2008, 5:53:37 AM5/21/08
to pon...@googlegroups.com
不是所有的程序都能跑在ide里做调试的，这时候如果有个支持脚本调用的shell跑在目标环境上，对调试还是有很大帮助的。比如很多嵌入环境。
游戏里，引擎是最重要的，提供各种表现能力。但游戏内容本身需要快速变化（比如场景修改，任务更新），这个快速变化的东西使用脚本就很方便了。
前几天看了一个分类：宿主语言和系统语言。大概就是说某种语言目的是轻巧，自身不提供很多功能，而是由脚本运行的宿主来提供功能，比如lua，javascrip（浏览器宿主提供DOM，BOM）；而系统语言则致力于提供大而全的内建库，并与操作系统紧密结合，比如C，Python。如果是游戏，显然前者更合适。
基础语言提供功能，比如粒子渲染，智能寻路；用脚本语言调用并展示，这个是比较理想的搭配方式吧。
当然，接下来的问题就是，如何区分功能和展示？我也不知道，自己摸索吧。一般是先用脚本实现原型，然后优化时用c或者其他的底层语言做成库。
至于说游戏里为啥要脚本这个问题……打开wow，Interface\addons，大把的例子阿……
2008/5/21 清风雨 <zhang...@gmail.com>:
> 继续追问几个问题：
> 1. 在服务器应用这个场合上，选用哪个脚本会比较适合，用在哪部分，用于做什么。---- 听说"大话西游"用了Python，后来换了lua，而且还用
--
新的理论从少数人的主张到一统天下，并不是因为这个理论说服了别人抛弃旧观点，而是因为一代人的逝去。
My blog: http://googollee.blog.163.com
nothanks
May 21, 2008, 6:21:22 AM5/21/08
to TopLanguage
总之，脚本实在是太重要了啊。
On 5月21日, 下午5时53分, "Googol Lee" <googol...@gmail.com> wrote:
> 不是所有的程序都能跑在ide里做调试的，这时候如果有个支持脚本调用的shell跑在目标环境上，对调试还是有很大帮助的。比如很多嵌入环境。
>
> 游戏里，引擎是最重要的，提供各种表现能力。但游戏内容本身需要快速变化（比如场景修改，任务更新），这个快速变化的东西使用脚本就很方便了。
>
> 前几天看了一个分类：宿主语言和系统语言。大概就是说某种语言目的是轻巧，自身不提供很多功能，而是由脚本运行的宿主来提供功能，比如lua，javascrip（浏览器宿主提供DOM，BOM）；而系统语言则致力于提供大而全的内建库，并与操作系统紧密结合，比如C，Python。如果是游戏，显然前者更合适。
>
> 基础语言提供功能，比如粒子渲染，智能寻路；用脚本语言调用并展示，这个是比较理想的搭配方式吧。
>
> 当然，接下来的问题就是，如何区分功能和展示？我也不知道，自己摸索吧。一般是先用脚本实现原型，然后优化时用c或者其他的底层语言做成库。
>
> 至于说游戏里为啥要脚本这个问题……打开wow，Interface\addons，大把的例子阿……
>
> 2008/5/21 清风雨 <zhangJW...@gmail.com>:
On 5月21日, 下午5时53分, "Googol Lee" <googol...@gmail.com> wrote:
> 不是所有的程序都能跑在ide里做调试的，这时候如果有个支持脚本调用的shell跑在目标环境上，对调试还是有很大帮助的。比如很多嵌入环境。
>
> 游戏里，引擎是最重要的，提供各种表现能力。但游戏内容本身需要快速变化（比如场景修改，任务更新），这个快速变化的东西使用脚本就很方便了。
>
> 前几天看了一个分类：宿主语言和系统语言。大概就是说某种语言目的是轻巧，自身不提供很多功能，而是由脚本运行的宿主来提供功能，比如lua，javascrip（浏览器宿主提供DOM，BOM）；而系统语言则致力于提供大而全的内建库，并与操作系统紧密结合，比如C，Python。如果是游戏，显然前者更合适。
>
> 基础语言提供功能，比如粒子渲染，智能寻路；用脚本语言调用并展示，这个是比较理想的搭配方式吧。
>
> 当然，接下来的问题就是，如何区分功能和展示？我也不知道，自己摸索吧。一般是先用脚本实现原型，然后优化时用c或者其他的底层语言做成库。
>
> 至于说游戏里为啥要脚本这个问题……打开wow，Interface\addons，大把的例子阿……
>
red...@gmail.com
May 21, 2008, 7:28:54 AM5/21/08
to pon...@googlegroups.com
王宁 wrote:
>
> 错误少了几个量级，不易调试又何妨？ 当然，前提是正确设计和单元测试。
我同意.
我近年来的开发环境就没有好的调试器可用, 迫使我从以前只是重视 log 信息加
强到注重单元测试, 过了一段时间之后, 效率其实完全没有降低, 从稍长的时间段
来看, 应该还提高了.
IDE 调试是费时费事的, 调试过程的辛苦以后无法重用. 单元测试好得多.
>
> 错误少了几个量级，不易调试又何妨？ 当然，前提是正确设计和单元测试。
我同意.
我近年来的开发环境就没有好的调试器可用, 迫使我从以前只是重视 log 信息加
强到注重单元测试, 过了一段时间之后, 效率其实完全没有降低, 从稍长的时间段
来看, 应该还提高了.
IDE 调试是费时费事的, 调试过程的辛苦以后无法重用. 单元测试好得多.
至于复杂性, 我的项目起码不会比大多数的人简单, 都是一些 24*7 的程序, 从
linux 内核模块, 到 user space 高并发服务器, 到数据库, 展示层之类的东西.
张教主
May 21, 2008, 7:34:50 AM5/21/08
to pon...@googlegroups.com
>面向 GUI 客户程序, 可以不用关心手工释放对象, 这样在包括
> callback 的复杂的message 路径中, 就不必通过
> 自己实现的方法, 才能释放对象.
> callback 的复杂的message 路径中, 就不必通过
> 自己实现的方法, 才能释放对象.
这不就是Adobe AIR吗 :)
Lycan. Mao..
May 21, 2008, 8:29:31 AM5/21/08
to TopLanguage
超级赞同关于宿主语言和系统语言的提法。有的语言就是用了做embeded的，比如Lua和Javascript，就是用它们来配置难以配置的主程序逻
辑。Perl，Python和Ruby视图做下一代的全能者（像C++）一样，我猜测其理念来自于原来Unix平台下管理工具。Larry Wall是
在厌倦了"Do one thing, and do it well"哲学之后才发明的Perl，而且Python和Ruby都是90s初期产生的，
估计思想上都差不多。Lua这些后来者，从开始就定位于embeded，自然用途就不同了。
再说多线程环境下传统的IDE调试时不可行的，反正不容易就是了。
编译语言的缺陷，除了C++的超长待机时间（人等着）外，还有就是二次开发中的不便。我们组做基于Autodesk Map 3D的开发，用.NET。
每次都要先编译好DLL之后，启动Autodesk Map 3D，载入图,载入DLL，再开始工作。期间，因为多线程的问题在Visual
Studio里面看不到一些变量的值，只能用输出Log的方法。如果有问题得中止Autodesk Map 3D，重新修改生成DLL后，再重启
Autodesk Map 3D，继续上述步骤。很痛苦的。这时候就羡慕AutoLisp和VBA，可以实时看结果。
On May 21, 5:53 pm, "Googol Lee" <googol...@gmail.com> wrote:
> 不是所有的程序都能跑在ide里做调试的，这时候如果有个支持脚本调用的shell跑在目标环境上，对调试还是有很大帮助的。比如很多嵌入环境。
>
> 游戏里，引擎是最重要的，提供各种表现能力。但游戏内容本身需要快速变化（比如场景修改，任务更新），这个快速变化的东西使用脚本就很方便了。
>
> 前几天看了一个分类：宿主语言和系统语言。大概就是说某种语言目的是轻巧，自身不提供很多功能，而是由脚本运行的宿主来提供功能，比如lua，javascrip（浏览器宿主提供DOM，BOM）；而系统语言则致力于提供大而全的内建库，并与操作系统紧密结合，比如C，Python。如果是游戏，显然前者更合适。
>
> 基础语言提供功能，比如粒子渲染，智能寻路；用脚本语言调用并展示，这个是比较理想的搭配方式吧。
>
> 当然，接下来的问题就是，如何区分功能和展示？我也不知道，自己摸索吧。一般是先用脚本实现原型，然后优化时用c或者其他的底层语言做成库。
>
> 至于说游戏里为啥要脚本这个问题......打开wow，Interface\addons，大把的例子阿......
>
> 2008/5/21 清风雨 <zhangJW...@gmail.com>:
辑。Perl，Python和Ruby视图做下一代的全能者（像C++）一样，我猜测其理念来自于原来Unix平台下管理工具。Larry Wall是
在厌倦了"Do one thing, and do it well"哲学之后才发明的Perl，而且Python和Ruby都是90s初期产生的，
估计思想上都差不多。Lua这些后来者，从开始就定位于embeded，自然用途就不同了。
再说多线程环境下传统的IDE调试时不可行的，反正不容易就是了。
编译语言的缺陷，除了C++的超长待机时间（人等着）外，还有就是二次开发中的不便。我们组做基于Autodesk Map 3D的开发，用.NET。
每次都要先编译好DLL之后，启动Autodesk Map 3D，载入图,载入DLL，再开始工作。期间，因为多线程的问题在Visual
Studio里面看不到一些变量的值，只能用输出Log的方法。如果有问题得中止Autodesk Map 3D，重新修改生成DLL后，再重启
Autodesk Map 3D，继续上述步骤。很痛苦的。这时候就羡慕AutoLisp和VBA，可以实时看结果。
On May 21, 5:53 pm, "Googol Lee" <googol...@gmail.com> wrote:
> 不是所有的程序都能跑在ide里做调试的，这时候如果有个支持脚本调用的shell跑在目标环境上，对调试还是有很大帮助的。比如很多嵌入环境。
>
> 游戏里，引擎是最重要的，提供各种表现能力。但游戏内容本身需要快速变化（比如场景修改，任务更新），这个快速变化的东西使用脚本就很方便了。
>
> 前几天看了一个分类：宿主语言和系统语言。大概就是说某种语言目的是轻巧，自身不提供很多功能，而是由脚本运行的宿主来提供功能，比如lua，javascrip（浏览器宿主提供DOM，BOM）；而系统语言则致力于提供大而全的内建库，并与操作系统紧密结合，比如C，Python。如果是游戏，显然前者更合适。
>
> 基础语言提供功能，比如粒子渲染，智能寻路；用脚本语言调用并展示，这个是比较理想的搭配方式吧。
>
> 当然，接下来的问题就是，如何区分功能和展示？我也不知道，自己摸索吧。一般是先用脚本实现原型，然后优化时用c或者其他的底层语言做成库。
>
>
> 2008/5/21 清风雨 <zhangJW...@gmail.com>:
dennis
May 21, 2008, 9:48:40 AM5/21/08
to TopLanguage
1、lua号称是最快的脚本语言，整个打包也就150K左右，我们公司一牛人就是用lua用在了服务器端，做配置性，并且参与部分逻辑，因为逻辑改变比
较多，而脚本的简便性就体现出来了。lua5.0以上版本都是基于寄存器的，而非传统的基于栈的虚拟机。
2、界面修改，javafx算不算？
3、Ruby跟perl的哲学是比较接近的，不限制你做啥，more way to do it。而python是中规中矩，only one
way to do it。在脚本语言开发中，已经有人强调的，就是单元测试的重要性，单元测试不仅仅是因为脚本调试能力的薄弱，也是实施代码重构的保
证。
较多，而脚本的简便性就体现出来了。lua5.0以上版本都是基于寄存器的，而非传统的基于栈的虚拟机。
2、界面修改，javafx算不算？
3、Ruby跟perl的哲学是比较接近的，不限制你做啥，more way to do it。而python是中规中矩，only one
way to do it。在脚本语言开发中，已经有人强调的，就是单元测试的重要性，单元测试不仅仅是因为脚本调试能力的薄弱，也是实施代码重构的保
证。
coolspeed
Jun 8, 2008, 4:28:29 PM6/8/08
to TopLanguage
1。脚本性能差（也不需要强）
2。无native代码，脚本就不是“程序”而只能沦为“人类文本”
3。基于人类文本，也就人机关系层次中更接近人这一侧。人工智能必须发生在这里，文本是必需的。这也是数据从二进制到文本化（XML）的一种对称
4。不冲突各司其职嘛。openGL，显卡渲染管线调用当然用C，没人拿脚本做吧？openGL渲染脚本语言得用文本吧？没人用native代码吧？再
自然不过的事了。原想把翅膀长在背上，现在改长在肚子上了，用文本才灵活嘛，而渲染每个翅膀的方式没变，也就是native渲染代码照用。
5。脚本通用。这有些情况下是必须的。
2。无native代码，脚本就不是“程序”而只能沦为“人类文本”
3。基于人类文本，也就人机关系层次中更接近人这一侧。人工智能必须发生在这里，文本是必需的。这也是数据从二进制到文本化（XML）的一种对称
4。不冲突各司其职嘛。openGL，显卡渲染管线调用当然用C，没人拿脚本做吧？openGL渲染脚本语言得用文本吧？没人用native代码吧？再
自然不过的事了。原想把翅膀长在背上，现在改长在肚子上了，用文本才灵活嘛，而渲染每个翅膀的方式没变，也就是native渲染代码照用。
5。脚本通用。这有些情况下是必须的。
> 我的体会也不多，不过最近感觉脚本真的不错！
> 1、基于文本。这一点初看起来没有什么好处，不过，就个性方便来说，是编译型语言所不能比的。
> 2、编写容易。一行管道代码相当于10000行C代码。
> 3、方便维护。这基说第一点的。
>
> 在处理复杂问题时，脚本语言当然没有什么优势。但脚本语言多说都是DSL，在这些方面，无论是编写还是阅读，都非常有优势。
> 把语言用的它应该用的地方，才能发挥它的优势。在不怎么要求性能，需要经常修改，特别是在交付后需要修改的地方，用一下脚本，我觉得还是挺合适的。
>
> 在08-5-21，清风雨 <zhangJW...@gmail.com> 写道：
> 1、基于文本。这一点初看起来没有什么好处，不过，就个性方便来说，是编译型语言所不能比的。
> 2、编写容易。一行管道代码相当于10000行C代码。
> 3、方便维护。这基说第一点的。
>
> 在处理复杂问题时，脚本语言当然没有什么优势。但脚本语言多说都是DSL，在这些方面，无论是编写还是阅读，都非常有优势。
> 把语言用的它应该用的地方，才能发挥它的优势。在不怎么要求性能，需要经常修改，特别是在交付后需要修改的地方，用一下脚本，我觉得还是挺合适的。
>
>
>
>
> > 是这样的，我一直对脚本语言持怀疑态度；而在网上看到的理由，又感觉比较概念抽象，不够细化；可能是我没有实际体会，所以感触不深。最近的项目用到了脚
> > 本，但我感觉到的好处更多的是它做为配置性参数上的，它便于快速试验；而在调试、查错上到不如C++借助IDE了；对于简单的逻辑、流程控制，对于脚本
> > 使用而言，都需要导出大量的接口函数；对于复杂的控制，脚本显然更是力所难及了（举个相对复杂的：如UI的效果制作，似乎脚本也起不了太大作用，只有对
> > 于位置等简单的参数性控制是很有优势。要么导出大量的接口，实际上如果这么做，还不如直接用C/C++实现更省力）；因为接口的导出，那么也就意外着想
> > 用脚本应付项目未来的变化，是行不通的，因为没有应用层的接口，他做不了太多的事。
> > 以前用过两个脚本，一个是kele8的fcc，它已经上升成为项目的制作言语，而非辅助地位；一个是Torque的cs脚本，说真的，简直就像用c实现
> > c++的原理，还有调试器，整体感觉还不如直接用C或C++，现在回想起来，他的好处只有极大的缩短了编译连接时间这点了。
>
> > 所以，想请教大家，脚本的好处有哪些，适合用在哪些情况？最好能举些实际的例子和情况。
>
> > 现在项目中使用的是LUA，因为轻量级，而且集成lua的项目很多，据说"魔兽世界"就用了lua。我知道还有一个脚本语言叫angelscript
> > (http://www.angelcode.com/angelscript/)，也是轻量级的，而且从集成角度，比lua更容易，语法上类C/C
>
>
> > 是这样的，我一直对脚本语言持怀疑态度；而在网上看到的理由，又感觉比较概念抽象，不够细化；可能是我没有实际体会，所以感触不深。最近的项目用到了脚
> > 本，但我感觉到的好处更多的是它做为配置性参数上的，它便于快速试验；而在调试、查错上到不如C++借助IDE了；对于简单的逻辑、流程控制，对于脚本
> > 使用而言，都需要导出大量的接口函数；对于复杂的控制，脚本显然更是力所难及了（举个相对复杂的：如UI的效果制作，似乎脚本也起不了太大作用，只有对
> > 于位置等简单的参数性控制是很有优势。要么导出大量的接口，实际上如果这么做，还不如直接用C/C++实现更省力）；因为接口的导出，那么也就意外着想
> > 用脚本应付项目未来的变化，是行不通的，因为没有应用层的接口，他做不了太多的事。
> > 以前用过两个脚本，一个是kele8的fcc，它已经上升成为项目的制作言语，而非辅助地位；一个是Torque的cs脚本，说真的，简直就像用c实现
> > c++的原理，还有调试器，整体感觉还不如直接用C或C++，现在回想起来，他的好处只有极大的缩短了编译连接时间这点了。
>
> > 所以，想请教大家，脚本的好处有哪些，适合用在哪些情况？最好能举些实际的例子和情况。
>
> > 现在项目中使用的是LUA，因为轻量级，而且集成lua的项目很多，据说"魔兽世界"就用了lua。我知道还有一个脚本语言叫angelscript
Reply all
Reply to author
Forward
0 new messages