je专家挺多，想多请教一下

你写了很多内容，我们一点一点探讨。



如果你觉得有业务背景的快速开发平台是有价值的，说明你觉得采用更加简便的方式来实现系统这种方式还是认可的。但是你可能觉得，有业务背景的快速开发平台其面向的对象更多的最终用户，提供这个开发平台的功能，相当于为自己的软件增加了一个功能。

而通用的快速开发平台，其面向的是程序员。但是程序员由于日常采用的开发工具已经非常的强大，或者说也已经很易用了。你不管做的怎样，总不可能有实力比Visual Studio或者Eclipse还要强吧。

另外你可能觉得业务框架，作为自己的企业可以提炼出来。但是通用性的框架，如果能做的话，那么IBM、MS早就做了。也轮不到我们来做的，总不能说我们比IBM还强吧。

但是我要说的是，不同的立场是会带来不同的结果的。首先我想说的是，如果我们这个开发平台面向程序员的同时，又面向最终用户。也就是说，我们在同一个框架基础上，针对不同的用户推出不同的功能。面向最终用户的简单一些，面向程序员的功能复杂。面向最终用户的是为了解决维护时候的问题，而面向程序员的是为了解决开发时候的问题。你觉得这样有没有价值呢，另外Visual Studio或者Eclipse会往这方面发展吗？

通用性框架是为了屏蔽真实的框架。我们目前做一个开发平台以及的框架，可能是.net，或者是java的 SSH框架。其实我们已经将这些具体的实现屏蔽了。也就是说，我们将来是可以基于新的框架重新实现的，或者说可以做到跨框架。这些功能的话，IBM和MS是不会来做的。



你说的有道理的，平台的适用面是有限的。



ruby其实也可以说是一种快速开发平台。只是他应该为了能解决所有的问题，所以最后是一门语言。他用更加简洁的语法，来对应面向对象语言的实现。普通的快速开发平台是采用XML作为语言，并且通过开发工具对这个XML的实现做更多的限定。
这就是软件向更高抽像度发展的趋势决定的，只是两者适用面不一致，所以复杂程度也不一致。这就是普通的开发平台可以以更加简便的操作界面来实现的原因。


写开发平台当前一般有三个目的：
1、提高产品的技术含量。在销售过程中，更有竞争力。
2、可以减低对项目实施人员的技术要求。
3、加快项目的实施进度。



代码生成只是一种手段，是为了让平台定义的内容，可以以最快的速度运行的一种技术手段。因为你如果解析执行的话，速度会非常的慢。
生成代码不是为了得到所生成的代码，而是为了执行所定义的配置。对用户来说，就当生成的代码是不可见的。



流程图是可以作为快速开发的表现形式的，这个看现在工作流的实现就知道。表格是可以通过约定的结构，也是可以做到的，特别是决策表类表格，或者参数类表格。文档是需要约定语法的，一个文档加上一个DSL语言与程序语言的对照是可以做到作为输入方式的。开发平台要做的事情是，怎么让用户按照约定来用这些格式实现业务逻辑。




DSL是为了增加业务逻辑实现的可读性，比如读别的实现，或者管理人员、业务人员也能阅读。



我也在学习和研究当中，并不是权威。大家探讨吗，有不同意见会好些！

从我们研发平台的经验看，平台对生产力的提升主要在于催生新的软件结构方式，新的思考问题的方法，新的技术手段，而不是在现有技术框架上的一种代码的封装。

微内核+插件不是问题的核心，所谓的插件如何能以任意的方式与主框架的代码结合才重要。

代码的生成与解析只是一种技术性的困难，但是解决了代码生成和解析问题，仍然需要面对整体代码结构的控制问题。

我们在思路上没有大的分歧，在结论上差距很大，我不想说服你什么，只是有几个疑问想提出来。

关于平台

我理解平台是在库和框架之上封装的顶级框架，附送IDE，还可能带app server，啥啥中间件一整套东西。既有顶层软件设施，也包括开发环境甚至运行环境。



通用性框架就在软件栈的顶层。要做到在java和.net间移植，还得保证二次开发的代码也具有移植性。同时，平台所要收纳的组件库也需要谨慎选择，平台向开发者开放的接口也必须能移植。这些都不是容易事。不经大脑的想：选个在jvm和clr上都成熟的语言，比如python，无论平台还是扩展代码都必须使用python，选择的库也必须两个平台都兼容。代价大了些。。。扯远了。。。


这个不赞同，ruby是编程语言，在软件栈中处于最低层，是最基础的组件。这里说的平台在软件栈中处于最上层的位置。
尽量由最低层的编程语言可以搭建出整个系统，或者说整个系统运行中都必须受平台这个最上层组件的管理，但两者的位置是不同的，导致大的方向不同。
如同说jvm也是平台，跟我们现在讨论的这个“平台”也不是一回事，一个在地上，一个在天上。



Visual Studio、Eclipse，如果把它们称为平台，是跟楼主和canonical的平台意义是不一样的，它们是通用型平台，ecllipse绑定了SSH才跟现在的话题更象。


关于代码生成



开发流程是这样的(？)： 程序员在平台上开发(1) -> 客户的业务人员进行使用可视化工具进行配置(2) -> 运行(3)
1、2两步如果不重复迭代，问题就简单了，否则需要仔细研究研究。

最简单的方式，写个常规应用，带配置文件，再带一个方便业务人员查看、修改配置文件的GUI程序就够了。
这里既省了平台的“通用性框架”。也省了IDE，取而代之的是专有的GUI（比如写个swing程序）。


你说的没错，代码生成只是一种手段。只是为了让配置文件生效。我认为，不论生成代码，还是解析执行，都完全没必要把这部分功能放到“通用性框架”里，把它做成一个独立的程序库就行了。最简单的实现方式，就是GUI存盘的时候，按模板批量生成java文件，调javac编译，打成jar丢到工程里。同时它依赖另外一个库，这个库定义了它的实现接口以及加载方式（比如通过反射加Interface执行）。工程启动时，加载这两个库。我见有的工作流引擎就是这么干的。我估计通过osgi、classloader上做手脚，运行期间也能达到同样效果。“配置即代码”的效果

关于IDE和DSL



既然业务人员使用平台的IDE(或我说的gui)进行配置，那么这个界面就可以做到足够人性化，比如表格、流程图、关系图，根本没必要让他看到DSL。而DSL的本质，是用文本描述业务，不论这段文本是一段可以执行的代码，还是自己创立的语法规则，都不如在GUI界面上看起来直观，操作起来简单。如果是internal DSL（用编程语言表达的DSL），相比GUI有个优势是可以让开发者利用编程语言的灵活性书写复杂的逻辑，但你又说是只读的。最终DSL在什么位置？什么时候以什么方式展现给什么人？允许哪些操作？有什么意义？我看不到。

关于平台封闭性障碍和讨论中业务场景的需要



既然要做平台，让使用者绑定顶层的“通用性框架”、IDE，开发者再想扩展，就只能在有限的空间里进行了。
平台位于软件栈的顶端，既是平台控制力的体现，也是约束的象征。就像天上给遮个保护伞，既感到安全，又不能逃出它的阴影。
如果面向通用领域，这种从上到下一体化的软件布局既不容易招人待见，也不是小公司做得来的。程序库可以随意接入到其它产品中（调用就行），平台，这个一体化的大东西，怎么与其它系统整合，尤其需要部分整合或子功能使用呢？
功能模块分离（解耦）是技术方向，功能捆绑只是商业策略，平台是将功能捆绑销售的光明正大的理由。如果平台内部模块也没有道理的耦合那可就麻烦了。

平台整体走的是一体化、封闭化路线。

所以，这个约束，必须有足够的好处才能交换。比如在业务支撑上做文章，在概念一致性上做文章，在开发模式上做文章，还有canonical说的。
如果没有特征性的业务场景，没有除了平台就不可能有其它途径做好同一件事的理由，就只能泛泛而谈，最终大家谈论的话题变成了：对业务普适，对技术约束。如果我把springside定制一下，绑个IDE(springside连工程文件都生成好了),写个简单的配置插件，好象也算个平台了呢？

庄表伟老大和canonical老大的发言，都提到一点，是怎么定位出平台里哪部分是内置的，哪部分是扩展的，哪部分是对外开放的接口，哪部分是允许用户直接配置的。这个看起来容易（如果目标足够明确且简单就真的容易），不过，需求变更常常是不可预期的。面对这种不可预期，平台作为一块板子，就要经常在上面敲敲凿凿，而对程序库而言则更象往一块泥球上刷一层新泥。糟糕的平台比糟糕的程序库更容易将这种不可预期性放大化、扩散出去。

没有足够的业务背景，看不到充分的理由和价值。

总结一下，我的疑问：
1。平台到底是什么？
2. 平台必须要提供full stack方案吗？
3. 平台必须带IDE吗？有什么是普通GUI程序做不到的？
4. DSL在平台中的位置和价值
5. 平台在具体业务场景下的价值
6. 探讨平台功能模块的独立性及其意义
7  分别探讨平台捆绑性、排他性在商业上和技术上的必要性以及价值


记得canonical很久之前就做过平台，是这里的大牛，楼主也是资深人士，我主要是长期以前有这样的疑惑，今天借着这个机会发了出来，下一阶段主要是坐下来学习了。

你挺谦虚的，理解也很深入。我想讨论的目的，不是为了说服对方，而是为了说服自己。觉得自己的分析是有道理的，这样才对自己有用，才能真正达到讨论和学习的目的。

我想我们的目的，是为了明白平台到底有没有用。当然我们都看到这样的现象，做过平台的人，觉得平台是有价值的。而用平台的人（没有开发过平台，或者没有开发完平台），觉得平台是没有什么价值的。

感谢你给我介绍大牛，我先去拜读一下他们的文章，再来和你讨论吧。不然就会显得基础太差了。

由于没有太多的时间，没有看明白大牛的文章，可能要过些时日，才能慢慢消化吸收。

根据我自己的体验，我对上面提到的一些疑问，提出自己的见解：



平台本身应该是一个非常功能完备的系统，除了要有专门的框架、还要有自己的工具以及管理系统。另外还有有很多的标准和规范需要遵循。

但是我们平台在实现时，却不可能做一个功能完善的平台，因此只能根据自己的实力，来实现自己觉得必要的部分功能。然后通过其他的框架等来补充平台缺失的功能。

每个平台其实有自己的重点，就目前来说，我个人认为平台应该最关注的是简单、易用。以及通过开放性，来解决平台的功能全面问题。

认真的来说，目前宣称的平台，都还不能说是完整的平台。很多时候，还是一套框架以及一些工具，还不是一个自成体系的系统。



我一直都是根据项目的实际需要来开发一些使得开发简便的工具，以及通过框架来进行约束和限定。老实我，还还不是很理解full stack方案的意思，因此不好说。



平台必须要有自己的IDE，不然就很难实现自己特色的功能。
目前来说，普通的GUI程序来做IDE时，易用性和可扩展性是比较难处理的部分。OSGI是比较好的实现结构。



DSL在我的理解中，是希望采用语义更加丰富的语言来描述逻辑。更多的是将语言像本地自然语言靠拢，加强可读性。



在具体的业务场景下，真正有价值的还是包含了业务数据和逻辑的构件。应该说是非常粗粒度的复用，才是真正有价值的。

平台很多时候是相对细粒度的，平台的作用是可以加快粗粒度业务构件的可变性。



平台在我的理解中，就是将高手的经验，融合到平台中。让初级的人员，可以更加方便的复用这些经验。
让水平不高的人员，在短时间内，开发出优秀的系统。当然优秀与否要看开发平台人员的水平。



一个系统如果采用平台来进行开发，就势必对平台有了很大的依赖性。
这也是为什么快速开发平台，对于软件公司来说，是没有什么市场的。因为软件公司不能依赖于其他的公司。要依赖也要是 微软、IBM、Oracle、SAP这些大公司。

对所谓的通用开发平台，我来谈一些我的看法。我个人来说对通用开发平台持否定态度。
1.对于应用程序员来说，看不到使用这个平台对我日后的职业发展有什么好处。更有可能因为平台用多了，造成离开平台不会干活，丢失本身的编码能力。而且因为平台入门门槛比较低（很多吹嘘不会编程也可以开发MIS），造成相关开发人员薪水低下，企业也不怕这些人跳槽。跳了更好，招个新毕业的，2星期就可以干点简单的，还便宜（什么，新手干活慢？不怕，加班就是）。
2.说是开发平台，但是实际上能做的东西就是MIS、OA。开发更加复杂系统的话，那么带来的复杂度比直接编代码还麻烦。
3.运行速度慢。基本上使用平台开发的应用系统很多都是以慢为特点的。平台封装了太多的东西，造成运行效率低下。
4.平台开发速度实际上并不比RoR、Grails这些快速开发框架更快。简单模块上Ror号称10分钟一个博客。这个速度恐怕很多通用平台也无法达到。复杂业务开发上平台速度可能更低。不过平台因为其上手容易，更容易搞人海战术。
5.这些通用平台提供的技术支持有限。在文档、技术问题反馈等方面是比较差的。无法和开发语言相比。

没错，以前我也做和楼主类似的工作，得出和你一样的结论.