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

    做开发已经有些年头了，一直做的好像都是写代码的工作。平时也很少上这些论坛，这么多年从来没有在论坛上发过贴。可以这是在最初工作时养成的习惯吧，因为那时候还没有论坛。最多写代码上，碰到问题搜索一下，找到解决方案后就关掉了。
    最近发现也需要宣传一下自己，不然万一找工作，也好有个宣传的东西，就在CSDN上注册了博客。才开始关注这些论坛，以及论坛上面活跃的人。结果发现就技术而言，je上面更加适合于讨论问题。下次有些关于自己工作上碰到的问题，也可以拿到上面来探讨探讨了。
    不过要发起一个题目，确实也想不好，下次就对敢兴趣的帖子发表一下意见好了。我想只有在相互的辩论中才能真正的得到提高。
    我是一直做开发的，主要写的还是java。当然什么C#、Flex、VC、Delphi、PHP什么的，也写过一些。对于程序员来说，很多时候根据环境决定开发语言的，以及你所需要采用的技术。
    很多新的技术，也是稍微看一下。等到大家觉得都没有了问题之后，才敢使用。因为对于公司来说，项目是不允许失败的。所有不能无谓的去增加技术的风险。
    我是一只搞开发平台的研制工作，当然现在做这一块的人很多。是个公司可能都在说快速开发平台什么的。不过我做的还是挺早的，最早从2001年就开始了。所以说我们做东西很少上论坛，因为还根本没人做。我们用eclipse时，SWT才只有1.0，还挺不好用的。
    不过当初选定的技术，到现在也一直都没有什么改变，回头来看看这几年技术的变化，好像感觉自己落伍了一样。因此现在想融合一些新的思想和技术进来。
    我现在对几项技术比较赶兴趣，一个是DSL语言。我看到robbin在一篇帖子中评价普元时，觉得如果普元不是基于XML总线结构，而是有一套DSL语言，然后编辑器来生成这种语言，再加上一个管理完善的运行平台，这样才会理想。
    对于普元我不做评价，但是robbin这种思想和我们做的东西的想法非常接近，或者说我们的目标就是这样，可能技术有限某些指标方面没有达到而已。
    我这里暂时不对我的产品展开了，以后还有机会。我只谈实现这种技术会遇到的困难。
    1、首先一点DSL语言，比较难以选择。按理想来说可以选择python语言，但这样会加重使用者的学习成本。毕竟python掌握的人不多，社会还是java的人多一些，或者学校里就教过java。因此我们最后选择java语言。
    2、语言和编辑器的逆向工作很难。如果按照robbin的想法，用户可以直接编辑dsl，同时可以和编辑器配合做。但是编辑器生成的代码会把手工写的代码替换掉。这种逆向工作不好做。因此我们的做法是两者完全独立的，编辑器配置生成的代码是不能编写的，手工编写的代码可以供编辑器配置使用。
    3、调试和测试不好做。你要做调试，就要做跟踪，这是程序员的常用思路。这样的工程量就很大了，我们的思路是只有测试以及跟踪输出，没有debug。
    先说三点吧，其实还是有挺多问题需要解决的。总之，做一个这种平台很难，当你解决了一个问题之后，会发现还会有新的问题。并且你的功能也是需要不断扩展的。所以普元最初的时候，以为发现了银弹，确实最初的一些项目可能极大的提高了生产力。但是随着项目的复杂，其产品也做的越来越复杂，最终也导致了越来越难用。
    je的规矩挺多，也不知道该在什么地方发布什么贴。慢慢再摸索了。希望有人指点。

用java的话, 可以看看groovy, 做DSL


只能靠自己摸索了... 偶5钻的... 这几天天天在做脑残小测验...

谢谢回复，看样子je的支持挺好。
看groovy介绍的不错。不过我看其可以很好的支持java，不知道将来对C#的支持怎么样？

关于我们现在技术选型的情况，我一直现在在做抉择。可能需要专门开篇帖子，讲述我们的目的，以及已有的技术，可能的选择。不过这这里大致说明一下。

我们选择采用DSL的目的，是为了我们业务逻辑层的开发工作。

现在大家都知道流行开发平台，就是说，持久层采用ORMapping技术、逻辑层采用配置技术、界面层采用所见即所得的设计技术。

但很多人，其实也都在反驳开发平台的必要性，首先认为不用重复发明轮子，用现有的那些框架就行。另外制作一个开发平台且不说开发成本，就其稳定性和性能来说也会带来新的问题。

我不想去过多的反驳这些言论，因为每个人站得角度不一样。我想说明的是，在项目开发中，确实有大量的工作是不需要高深的技术以及设计的。大量的工作是重复的，琐碎的。灵活性太大的东西，是难以控制的。

因此开发平台就是希望可以解决，项目中那些简单的、琐碎的、易重复的工作。当然很多程序员，觉得现在使用代码生成器，完全可以解决这些工作的工作量。但我们还应该再深一层，就是这些工作是易维护的。简单的说，就是我项目运行阶段，要改动，也是希望一样快的。

这就是采用代码生成器的弱项了，你在运行阶段，就不能重新生成一遍代码，而是需要手工去改代码了。

因此我们要将这些简单的工作，从一开始就不是基于代码，而是基于开发平台配置的。那样将来修改的时候，也就不用去改动代码，仍然是改动配置，这样才能真正的做到敏捷性。

说了这些，还没讲我们为什么需要DSL。

我们现在就是需要业务逻辑的实现，不采用代码的方式来实现，而是采用配置来实现。并且我们希望java可以很方面的调用这些逻辑、Ajax可以很方便的调用、C#可以很方便的调用。

我先好好研究一下，grooy的语法再说。其实配置器的目标应该是可以生成不同语言的，然后和不同语言的进行配合。所以需要研究各个语言的特点。

Orz... 貌似你做的东西都挺深奥的...

可能我讲的不清楚，所以显得深奥了。其实也简单的，国内做的人也挺多。
我的想法就是通过一个配置器，能够轻易的配置业务逻辑的实现，然后生成代码来运行。
这个和普元做法类似，不过就是表现形式不一样。普元什么都用流程图来配，而我们用规则、用表格、用流程图来配。另外我们就是做到程序语言和业务领域语言的映射。
貌似规则引擎，但又不是真正意义上的规则引擎。规则引擎不会像我们这样直接映射代码，不会考虑测试与跟踪，不会考虑直接映射数据库。
我们没有匹配算法，没有理论。纯粹就是编写代码的另外一种方式而已，用失去语言灵活性来强化规范性以及易用性。
刚才说到的DSL语言的问题，是目前我们考虑需要解决的问题。
原先我们都是基于java的，我们可以在配置时直接调用java类，并且配置的逻辑是直接映射成java代码的。而且我们可以做java的语法提示等，因为java的反射机制支持这一点。
但是现在我们发现.net平台将有可能占领大量的市场。这样的话，我们基于java就不合适了。因为有可能服务器上安装的就是IIS，要让只懂IIS的人，去维护一个Tomcat不是一件很好的事情。因此需要我们配置的逻辑，可以直接供 .net调用。
因此现在在考虑究竟是基于动态语言呢，还是再为 C# 做一套。如果再为 C# 做一套的话，这个工作量可能会很大。因此现在要评估了。

要让用户去改DSL语言？这个只怕不合适。
任何语言都难以让用户去改，不是语言的问题， 而是逻辑完整性的问题。这就牵涉到必须有DEBUG等工具的配合才能达到较高的开发效率。
所以，我并不看好DSL给用户修改这样的特性。
我认为大多数时候，语言这个层面的东西不能过多的暴露给用户。这个特性只对少部分高级用户有用，不会是很重要的特性。

。net的话，建议看一下MS DSL Tools，如果是平台，平台不能建模，需要手工生成code，对dsl定义不清，还是在现有架构下面开发吧

用ruby ---代码生成器 + DSL
http://www.artima.com/rubycs/articles/ruby_as_dsl3.html

这帖怎么会有人投灌水？

LucasLee可能你在做类似的开发配置工具的工作。

确实目前做这类问题有个矛盾，就是如果你太简单了，就很难满足各式各样的需求。但如果你的功能很强，却会使易用性得到很大的限制。最终搞得又像一门新的语言。

怎么来权衡这个东西，就要看针对不同的用户。

对于一些管理人员或者维护人员，最容易让人理解的是图形、表格和文档。因此我们可以用流程图、用表格、用中文说明来实现。这样这类人员就适合可以用这些工具来进行开发。

对于程序员，最容易理解的是结构图和代码。如果是流程，那就是流程图的表现形式最直观，如果是逻辑，那对于程序员来说，代码比文本更加容易读通。

对于这两类人，是要有不同的工具来提供的。当然这两类角色的职责也不一样。管理人员只关注业务逻辑、操作界面、数据。程序员只关注技术实现上对不对，性能是不是最优的。

所以说，除了配置器能提供实现以外，还需要提供DSL语言的编辑功能。

但是这会设计一个debug的问题。其实这个问题，就是看你能提供给程序员的手段到底有多少。

debug目前在编码方面也是值得争议的问题，很多人开始提倡不要debug。因此你可以提供给他们更加方便的测试工具。

比如单元测试、轨迹跟踪、调试输出等。通过看日志，看数据变化的轨迹，可以非常清晰的看到出现错误的地方。

这些功能比debug，可以花更少的时间来发现问题。