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

代码和配置有时候没有明白的一条界线.
XML 从名字它还是一门语言呢,  虽然一般作为配置
假设代码足够符合规则, 很容易由表格式的配置生成, 也可以看作配置

而如果配置里面可以用正则表达式,你说它是不是代码?

你说的挺有道理，你从这些表面看的话，看不出编码和配置的区别。可能我们本身描述上就有些问题。

我要说的是区分开发阶段的代码以及维护阶段的配置。

举个例子，如果这个工作是需要在开发阶段做的。那么就是代码。如果是在维护阶段做的，而且作为提供给最终客户的一个功能，那么我把它成为配置。暂且不管这种称谓是否正确。

比如我们给用户提供了一个参数表，用户可以配。那就是配置。如果我们写在一个属性文件中，那就是编码。但如果这个属性文件，直接允许用户改。那就又叫他配置。

好像太学究了。我要说的是，这两种方式，关注点是不一样的。

我是想简单的实现，将来是可以直接提供给用户的。也就说就想现在流行的SAAS这种模式一样，用户是可以增加修改功能。当然功能上会有些限制。直接给客户提供的东西，就是简单易用，只有设置，以及一些公式。因此不考虑MVC等问题，或者在他眼里但不到这些东西。只给他提供几个东西让他设置。

当然我们肯定在底层使用MVC来实现的，只是对他不可见的。

对于复杂的方式，就需要编码以附之，这就需要有一个扩展性很好的结构，或者就像Ruby这种约定的架构来实现。或者采用插件形式。这些都可以探讨。

不过我倾向于，用插件这种方式。就是要考虑插在哪里，我想还是前端界面展现合适些。

同感，其实LZ说的和MDA的终极目标类似，我觉得做这种东西是没多大意义，机器很难理解人类语言，难度太大，只能简化，难以替代。LZ做出来估计唯一的好处就是简化部分开发，还不如创造一门新的语言，比如ruby？

用户比较喜欢saas，因为只要花钱就可以了，其他啥也不用做。

对于单据管理、数据交换、流程、报表这些应用场合应该不需要DSL，做成图形化的设计器比较好，DSL比较适合用于定义业务逻辑。

这样的平台很抽象，很通用，很难做，和应用级开发不是一个级别，如果做不到最起码在国内是前几位，是没有前途的。

在不该发帖的地方发帖，版主一般会帮我们放到合适的位置吧。除非是人身攻击才会被删掉。

不同的应用和需求，确实其侧重会不一样。有些侧重界面的配置，有些侧重流程的配置，有些侧重逻辑的配置，有些只要数据结构配置一下就行了。

因此不是一种表现形式能满足所有的需求。但是像你说的DSL比较适于定义业务逻辑，那我们就去解决业务逻辑的定义问题。而不是说要去拿他解决所有问题。

平台有没有价值和有没有市场，其实不是等同的。市场需要培育的，很多时候不是一家公司所能解决的。一般情况下，我们只做觉得有价值的，然后再把产品改造成一个成熟市场产品的替代者，去参与竞争。这是产品推广的思路。

不过对于技术人员来说，能坚持自己，并且持之以恒的做一件自己觉得需要的产品，很多时候也不能太功利性的去考虑到底有没有市场。

看那些开源软件，真正做好的，当初都是根据兴趣再走。因为市场都已经有了领导者，至于后来为什么推广开来，有些时候是他自己都没有想到的。当让更多的开源还是在默默无闻。

一个产品只要你用心，不管你有没有时间，有没有其他人的帮助。你总能做好你自己都觉得满意的地方。如果到时再拿出来和大家分享，其实是一件非常快乐的事情。在自己衣食无忧的情况下。

谢谢指点，后来又发了贴，就被马上移了地方了，还好没有删掉。

现在csdn推出的cto俱乐部，还是有一定影响力的。我们也看到了好多人，当然现在还是软件公司以及互联网公司的cto为主。

je如果真的想竞争，对一些高技术人人员，还是要有捷径，也不能一味的去和一些有些知名度的人唱反调。当然该评论的还是得评论，不过不能只有一种声音。

任何事情都有两面的，每个人、每个产品、每个观点就看你从哪方面看。不能只有一种声音，也不能只有一种论断。

迎合吧，迎合迎合，就把婊子这个职业进行到底了。

我对通用的快速开发平台不感冒，如同我对ruby的active_scaffold不感冒一样。
可视化流程可能是个亮点，拥有IDE的平台可以充分利用IDE的可视化优势。这方面还有潜力可挖，但还没看到突破。
有业务背景的快速开发平台还有点意义，通过配置定制，生成同一领域的多个产品。我把它当作更粗粒度的框架，或者称业务框架。

说说我对框架和函数库的理解。如果把软件比喻成一块完整的板子，框架就是挖了很多窟窿的石灰板，需要我们拌泥巴（写代码）填这些窟窿。
函数库就是一个个大大小小的泥球，我们可以把它们直接填到窟窿里，也可以和泥巴掺起来填窟窿。甚至填进去的是我们用自己的泥巴弄的小泥板，上面留了些小窟窿。。。

板子是死的，窟窿是活的，从灵活性看，函数库 > 框架 > 平台。
以前ruby讨论中，提到过java编程语言不足，只能用函数库来顶的现象。平台和框架的插件机制，是“微内核”的思想，即提炼出核心功能，将外围功能“函数库化”。插件的概念，不限于表现层。
如果这些东西不包含业务，长期看，平台的部分功能向框架转移，框架部分功能向函数库转移，函数库部分功能向编程语言转移。
类比以前有些是石灰的，现在要打掉变成泥板，一些泥板要变成泥球，一些泥球变成最基本的砂石。一方面，某些共性内容成为更低一层的设施，利于知识积淀和共享;另一方面，打破不合理的约束，让更多竞争者进入。这是软件向更高抽像度发展的趋势决定的。
(我以前发贴说过类似的观点)

业务多样性（不确定性、开放性）与平台约束（确定性、封闭性）会有冲突。

提到平台，总让我想起ejb的早期版本，它给我的印象是：把没有必然联系的东西非要纠扯到一块，不搞个app server你就没法玩，改行代码都得重新打包布署，说实在的我一直怀疑是这些公司的阴谋，不就想让用户买你捆绑了好多零件的app server吗？把开发者折腾惨了。现在终于轻生点了，本来嘛，如果我只需要ORM工具，干嘛还要买个app server，一点关系都没有啊。

写函数库、写框架在国内不好赚钱，写平台就显得大气，有技术含量，还能绑住客户，最重要的是能赚到钱。两个方向：
1. 努力做特别好的技术方案，采用开放的标准，可被直接替换成别的方案，不要绑定，平台只当成销售用的标签
2. 做业务平台，学SAP。


楼主说







代码生成是万恶的：不能逆向工作，一锤子买卖，每次覆盖。这个固有问题决定了它在工业化的开发流程中只能当个可有可无的小角色。
利用编程语言、函数库提供的能力，依照对问题域的理解，进行抽象封装，把精力重点放在这个方向更好。因为做好这些，就算合理使用代码生成，也能让生成的那一次代码更可读更可维护。
代码生成对于ruby这类编程语言来说没必要，这里还有编程语言能力强不强的问题。

如果能够确定要生成的文件哪些是不允许开发者修改的，就可以用ant把源码生成到临时目录，同时编译成jar，让开发者直接拿着jar用就行了。如果想看源码，就把源码也打到jar里。后面想重新配置的话，重新生成就是了，反正开发者不会修改jar的内容。IDE的方法提示、编译期检查也没丢；把IDE的lib和source目录指向过去，调试跟踪就没问题了。

开发者利用继承和组合的方式对它们进行扩展。前提是设计搞的好。

如果把配置存到xml里，通过解析xml生成代码、在IDE显示，就会解决逆向工作问题。允许开发者修改生成的java文件会怎样：解析java文件，还原成编辑器理解的模型？如果开发者添了大量代码，甚至改成了一个编译正确、逻辑也正确但就是不能匹配-还原出配置模型呢？

如果把流程图、表格和文档当成配置的输入，那就更明朗了。比方用户用word文档写了一段需求，传到服务器，服务器把它存起来，同时解析出用户意图，生成只读的jar。下一次用户想改，就把这个word文档再展现给他。这时候，word文档就是一个DSL。ruby的cucumber不是干这个的，它是写测试用例的DSL，但都属于external DSL，有可比性。

DSL(Domain Specific Language)，含Domain，让领域人员用？含Language，让开发者用？
楼主没拿出例子，只能跟着空想了。
我们不管是开发者还是业务人员，不管是internal还是external DSL，之所以用DSL，因为它能帮助人们用接近人类语言的方式表达问题域，是用来方便让人写，让人读，让人改的。如果用代码生成DSL，还不允许人改，那其实这里的DSL是面向机器的，有背常理。

如果用internal DSL，显然java没那么“高档”，还是在设计api上多下些功夫实际。

我没有快速开发平台的任何经验，说话粗鲁，见谅

--
投个良好，防止沉了