问成功的非程序员，5GL，视觉，0源代码或类似的工具？

EN

谁能给我一个成功的非程序员的例子，5GL (不是我确定他们是什么！)，可视化的，0源代码或类似的工具，业务用户或分析师可以用来创建应用程序？

我不相信有，我希望被证明是错误的。

在我工作的公司，我们开发了内部MVC，用于开发web应用程序。它基本上是一个用于控制器的用XML (àla 弹簧WebFlow)编写的简化状态机，以及一个用于表示的简单的基于模板的引擎。其中一些好处是：

• 动态性质:不需要重新编译来查看更改
• 减少“语义负载”：基本上，控制器中的动作只知道“If”。因此，培训开发应用程序是很容易的。

公司目前的趋势(或至少在管理层)是尝试为平台开发需要0源代码、可视化等的工具。它对客户(或至少在管理层)有很好的影响，因为：

• 他们可以确信，这样他们就不需要程序员了，或者至少能够雇佣到比典型程序员低得多的无价值程序员。
• 这似乎减少了风险，因为该工具限制了实现者或用户(只是不要使用程序员这个词！)在他所能做的事情上，所以他引入错误的可能性较小。
• 它似乎简化了整个问题，因为似乎不涉及编程(众所周知的复杂)。由于应用程序是动态加载的，所以与J2EE生命周期相关联的复杂性要小得多:编译、包、部署等。

我个人对这样的事情能否实现持怀疑态度。我们今天的解决办法有几个问题：

• 实现者编写JavaScript代码来丰富页面(可以通过开发小部件来解决)。尽管是客户端，但仍然是一段代码，它可能变得非常复杂，并导致一些困难的bug。
• 已经有了可视化工具，但是实现者更喜欢编辑XML，因为它更快、更容易。作为比较，我想没有多少人使用Eclipse插件来编辑flow XML。
• 解决方案中的重用性很差(基于XML的复制粘贴)。这妨碍了生产力和其他一些方面，比如培养商业知识。
• 由于不正确地使用这些工具，出现了许多性能和其他问题。无论操场有多小，总会有出错的空间。
• 虽然这个平台可能比Struts更有效率，但我怀疑它比今天的RAD框架(如RoR或Grails )更有效率。
• 罗嗦

历史上，在这个方向上有许多失败。由非程序员编写程序的想法是古老的，但AFAIK从未成功。在某种程度上，除了源代码之外，任何东西都成为不可替代的。今天，有很多关于DSLs的讨论，但不是非程序员应该写的东西，更像是他们可以阅读的东西。

在我看来，公司在这方面采取的方向似乎是一条死胡同。你认为如何？

编辑:值得注意的是，很多大公司都在朝这个方向做实验。参见Microsoft，Google，iRise，许多Mashup解决方案等。