| 文章标题：与网友AvayaEngineer的讨论 |
| 文章作者：bluesen |
| 发表时间：2004-11-9 15:40:27 |
| 内容：
-------------- AvayaEngineer: 看过你的“语言”介绍，我觉得目前还不是真正意义上的“语言”，能生成目标文件吗？能编译连接吗？呵呵。。。 看看这里，http://www.ngnc.net/NGNide/NGNide_intro.htm， 这是我的一个朋友凭个人力量独自设计开发的一种类C语言，当然了，它跟IVR流程脚本一点关系都没有。 Bluesen: 误解和偏见 看来你对脚本语言充满了误解和偏见。 和很多脚本语言一样，koodoo语言的编译和链接是在内存中完成，生成的目标代码(对象)也是直接在内存之中，从用户的角度出发更加简单。 Koodoo有完整的语法结构，丰富的系统库和完善的外部接口。蓝星际语音平台只是这个语言的一种实现，类似IDE，有可视化集成编译调试环境。 JavaScript加载到浏览器就可以直接运行，也没有你所期望的“生成目标文件”、“编译连接”等过程，你能说它不是一种语言吗? 看了你朋友的“类C语言”，其实也是脚本语言，和Koodoo一样，当然也是面向特定的应用，因为没有语法手册和库说明，不好评论。 但以同行的眼光看来，其IDE和调试器无疑太复杂了，Keep it simple，这应该是脚本语言的设计目标。 对于语法的取舍，不妨多说几句。 我自己是C/C++的狂热爱好者，实际上koodoo语言也是用C/C++来实现的。 但是如果一种面向特定领域的脚本语言完全照搬C/C++的语法，那太复杂了，我不认为是个明智的想法，尤其C/C++复杂的类型系统和指针。 毕竟C/C++是个通用的程序设计语言，它试图解决的问题要广泛的多。而且面向特定领域的脚本语言本来就是要简化问题，否则还不如直接 用给用户提供一套C++的CTI类库框架呢。 C++之父B Stroustrup在被问到对于当前脚本语言的兴旺态势怎么看时，他回答道: “有些语言很不错。比如Python，我很喜欢。但是我认为你从不同的语言中学到的OO技术是不完全相同的。当然，每一个职业程序员都要通晓几门语言，并且应该意识到，在不同的语言之中，编程和设计技术有着显著不同。 在我看来，用脚本语言建造的系统与用C++那样的通用语言建造的系统大不相同。从两类语言中学到的技术区别明显。不存在“可以满足绝大多数高效系统构建所需”的公共OO技术子集。” -------------- AvayaEngineer: 现在很多人动不动就把某种标识符号或类脚本就说成语言，呵呵。。。 Bluesen: 你觉得脚本语言就不是“语言”吗？ 也许在你看来，Python就是一种“标识符号”，哪里入得了你的法眼呢。 -------------- AvayaEngineer: 个人观点： 看过您的koodoo“语言”，是很不错，我很佩服你钻研技术的精神。也可以想像，您在设计这个“语言”的时侯，肯定花了不少功夫， 值得敬佩。不过，我以为，如果单纯是为了解决语音平台的问题，完全没有这个必要来设计一种“语言”来解决。如果非要用“语言” 来解决，为什么不直接借用Javascript或VBscript来做呢？而且很多公司的产品都是这么做的。另外开辟一种“语言”来做，你不认为 这是花架子吗？我也以为，用Javascript或VBscript来做，也是完全没有这个必要，有吗？独辟一门语言专门来解决语音平台的问题， 这似乎也不太符合您的Keep It simple这个理念。 为什么不能做的更 Simple 呢？ 要生成一套流程，还要让用户熟悉一种“语言”？然后用这种语言来生成流程，这 Simple吗？用一个简单的规则不就完全OK了吗？而 这个自己设定的简单规则，并不意味着它不能解决复杂问题，而恰恰是，这个简单规则，可以解决绝大部分问题，可以灵活定制出各种 各样的流程。 而您独辟Koodo语言，又能推动多少计算机技术的发展呢？ NGNc不是脚本语言，是面向嵌入式设备以及移动设备应用开发的。您说他的 IDE太复杂了，呵呵。。。不复杂。其所有的功能都是必须的。Keep It Simple，呵呵。。。Simple的标准是有高低的。 Bluesen: 我所说的简单是指用户体验的简单，更重要的是保持架构的简单，而不是功能的简陋。 我设计Koodoo当然是为了解决实际问题，它决不是我自娱自乐的玩具语言。我也很清醒，我从来没有认为它是一个解决广泛问题的通用 语言。面向特定领域的脚本语言，当然要在易用性和功能之间取得某种平衡。任何产品都有它的客户群，我认为CTI中间件/语音平台从 来就不是为最终用户设计的，它的真正用户应该是系统集成商，或者说业务应用的开发者。 回到你的问题： 1.为什么不直接借用Javascript或VBscript来做呢？ 答：我认为Javascript适合作动态网页，未必适合CTI领域，而且作为一个平台如果要完全实现其内部方法，系统对象，太复杂了。如果仅仅 是借用其语法，意义并不太大，很可能是作茧自缚。 2.用一个简单的规则不就完全OK了吗？ 答：你的规则用什么来描述，ini文件？复杂的规则发展下去不就是语言吗？ 我遇到到的很多应用不仅仅是简单的语音流程，需要和数据库打交道，甚至和非数据库的后台系统打交道，有些还可能要进行复杂的运算。 设计一个支持脚本语言的平台可以统一的解决这类问题。 应用千差万别，用一个简单的规则是不能完全OK的。 是否需要一种语言，当然是市场说了算。Intel有一个CT ADE，其脚本语言叫VOS语言(也叫AD语言)，在国外卖得也挺好。其介绍参见： http://www.ctiforum.com/train/intel/tech/tech01_001_00.htm 当然，我觉得其设计并不太佳，参见拙文"魔鬼隐藏在细节之中---我看Intel CT ADE"： http://www.bluespace.com.cn/koodoo/article_ct%20ade.htm -------------- AvayaEngineer: 简单规则当然是可以的，是完全可以代替你的Koodoo“语言”的 语音流程当然是指各种简单或复杂的流程，与后台系统交互当然包括与数据库，甚至交易中间件的交互，也包括与各种基于 WebService架构的应用或其它基于ASP的Web应用的交互。这些看起来似乎很复杂，其实说白了这些都是很简单的。靠一个极 其Simple的规则就可以解决，规则也未必需要INI的形式来定义，我不认为发展下去，他就是一种“语言”。也安全没有必要 让它复杂到需要用语言来解决的程度，我始终坚持认为，引入CTI语言来做平台，只是追求技术境界的花架子。我也看过同力 信通的平台，很简单，做流程就是简单的拖拉，然后设置几个参数搞定，就这么Simple。这不就是靠一种脚本规则解决问题 的实例吗？何需语言？根本就从中找不到任何“语言”的影子。 -------------- Bluesen: 我不知道你有没有做过复杂的IVR应用? “做流程就是简单的拖拉”，你看到的图形化的拖拉只是一个外壳，它后面的东西呢？ 贴一段我以前回应thinkp的话，算作是对你的回答吧： ------ " 我们原来在老泓那里讨论过，看来观点有所不同。 " 我们的论点在各自的文章里面已经说的很清楚，实际上是对目标客户的定位不同，还有对CTI应用复杂性的认识。也许这只能让市场来检验了。 " 其实“写程序的感觉”并非坏事，现在还很多人会用FoxBase写程序，做应用。关键是看如何更好的解决问题。 " 退一步看，即使是图形化流程设计，仍然需要好的语言来支撑。Delphi后面是Object Pascal, C++Builder后面是C++，VB后面是现代的Basic语言。 " 如果Delphi后面不是强大的Object Pascal，而是充满goto语句的节点描述文件，Delphi早就在市场上无影无踪了。 ------ 现在问题似乎转到了图形化拖拉界面的讨论，我的完整回答就是这篇文章"以语言为中心--论CTI中间件的设计"： http://www.bluespace.com.cn/koodoo/article_ctilan.htm -------------- AvayaEngineer: 看过了你的文章 什么叫复杂IVR应用？银行业务复杂否？税务业务复杂否？ 如果流程图做的像蜘蛛网，那说明流程设计器不完美。 如果流程设计器不能完成必要的功能，那说明做的不完善。 如果设计完流程图，还需要再改脚本，那说明做的不成功。 想必你曾经见过的流程设计工具都是这个样子的吧，要不然你不会有这样的观点。呵呵。。不要对流程图抱有成见麽。 你在文章所提到的流程图的种种弊病，在很多家的产品里确确实实存在这些问题，但是不要因为没见过Perfect的产品，而就否定流程图。 我始终认为，独创“语言”来做流程，确实是花架子，有故弄玄虚的感觉，因为，本来就是一件很简单的事情，为什么非要搞那么复杂呢？想必主流还是拖拽式流程设计吧。我想，不管是给最终用户使用，还是给集成商使用，有谁愿意去掌握一种独特的没有主流意义的语言呢？我同意ct_dev的观点，这是在浪费程序员的青春。 bluesen: 讨论到后来，就变成词语的重复了，说来说去就是那几句话了，旁观者未免乏味。 “什么叫复杂IVR应用？银行业务复杂否？税务业务复杂否？” 电话证券交易和有些较全面的电话银行系统可以称之为复杂的IVR，我也是行业中人，并没有见过完全使用图形化的 语音平台中间件来进行设计的。 “如果流程图做的像蜘蛛网，那说明流程设计器不完美。” 如我文章中论述，这是根本问题，也就是业务流程的复杂性和图形拖拽固有缺陷的矛盾，不必举例，相信所有做过复杂IVR的人都要同样体会。 如果硬要在图形层面解决，只能把平台做成和业务相关，减少一些图形节点，但这样又有违通用中间件和业务无关的初衷。 “但是不要因为没见过Perfect的产品，而就否定流程图。” 你就举例说明吧，让大家也开开眼界。 如同我上贴指出，即使是优秀的图形化产品，其后台核心就是语言。 至于你反复强调的“花架子，有故弄玄虚的感觉”，这只能是你个人的混乱感觉。 香港最大证券商大福证券采用Koodoo语言成功开发证券电话委托系统，我深感荣幸--我“浪费了”他们优秀程序员的青春。 -------------- AvayaEngineer: 平台就应该是平台的样子 既然是平台,那它就本来应该和业务无关,但是这妨碍节点的数量多少吗? Delphi是个平台,是个编程工具,它和具体的编程业务有什么关系吗?它的控件少了,程序员还可以自己定制ActiveX控件来丰富. 我认为语音平台也应该是这个样子,它和具体的IVR业务毫无关系,可以利用它象Delphi那样设计出各种复杂业务应用(这当然只是个类比).也许你认为,唯独通过语言才能设计出复杂应用.我不认同你这个观点.Delphi当然是靠优秀的Object Pascal来支撑它,但是您别忘了,Delphi面向的是程序员.而语音平台不是面向专业程序员的,它很有可能是直接面向用户的.为了解决这个问题,为什么不能把所谓的语言隐藏在平台后面呢?而呈现在平台使用者面前的只是简单的拖拽和属性的设置、以及逻辑的控制呢?然后在编译的时候，通过内部的语言机制来实现呢？这是完全可以做到的， 而且不是没有这样的产品。另外，这么实现也是无需独创语言来实现的，完全可以借用C＋＋的语法来直接实现。不管是采用何种语言，我认为这应该是系统内部的事情，而是不应该呈现到用户面前去的。呈现给用户的永远应该是最简单的，这样也许才符合Keep It Simple这个理念。 Bluesen: 为什么语音平台不能面向专业的程序员？ 面向没有计算机基础的最终用户，在我看来简直是天方夜谭。 你可以问问那些做中间件的厂商，他们的产品是什么人在使用它开发应用？ （首先声明，以下说法绝对没有贬低国内同行的意思，我一直以为只要有各自的用户空间，任何产品必定有它存在的理由。只是和AvayaEngineer争论至此，不得不发） 就让我再来说说Simple, 我试用或者分析过国内几乎全部厂商的图形拖曳的语音平台产品，他们的操作界面都是各不相同的，而且都是需要学习，学习的时间绝对都不短--要知道我作为专业程序设计师尚且如此，更何况普通用户乎？ 而脚本语言通常都在语法上接近于C语言，很容易上手。 “一幅图形胜过千言万语”，那也得看什么图，很少有流程图少于1页的，而且线条多有交叉，非常复杂。有些厂商都提出了一些办法，比如分层，或者模拟语言里面的“过程”抽象出可以复用的公共图，但是由于缺乏语言中变量和表达式的强大的表达能力，以及语言中函数、过程、全局变量局部变量这种种语言机制的封装能力，使得处理复杂IVR业务捉襟见肘。 有的产品稍微复杂一点的节点就要采用外部语言来写一个动态库，采用单一的流程图根本不能解决问题。 具体一点，在语言中的一句话，想想对于图形拖曳平台来说意味着什么: if( date=="2004.10.17" && (vol>1000 || price>19.36) && isOpen ) { ... } 你也许又会像上次那样说，是你没有看到好的。好的在哪里？银弹在哪里？ 如果没有，那结论就是：流程图没有办法解决复杂IVR的问题，落到最后它自己变得更复杂。 此外，你老是拿Delphi来说事，我不妨重复一下我的观点: "拖放式流程图的拥护者也往往认为图形化是软件设计的潮流，君不见VB, Delphi大行其道？这和应用有关系，很多桌面应用其操作界面就是图形化的。 而CTI应用本质上是一种服务程序，它是多路的、甚至是在后台进行的；它的操作也不是图形界面的交互，而是电话的、语音的操作。" 推荐各位看看一篇文章, 或者能够得到一些启发, "拖拽式IT开发还不成熟": http://www.zdnet.com.cn/techupdate/apply/collaboration/story/0,3800030473,39285683,00.htm 这篇不是我写的了，是ZDNET专栏作家的大作。:) |
|
已有回复： |
|
回复如下