programming-languages - 成功的非程序员，5GL，Visual，0源代码或类似工具？

Question

谁能给我一个成功的非程序员，5GL(不是我确定的样子!)，可视化，0源代码或商业用户或分析人员可以用来创建应用程序的类似工具的示例吗？
我不相信有，并且我想证明自己是错的。

在我所在的公司，我们已经开发了内部MVC，可用于开发Web应用程序。从根本上讲，它是一种用XML(àla Spring WebFlow)编写的简化状态机，用于 Controller ，是一种基于模板的简单引擎，用于表示。一些好处:

动态性质:无需重新编译即可查看

的更改

减少了“语义负荷”:基本上， Controller 中的 Action 仅知道“If”。因此，培训某人开发应用程序很容易。

公司当前的趋势(或至少在管理级别)是尝试为需要0个源代码，可视化等平台的工具生产工具。由于以下原因，它对客户(或至少在管理级别)具有良好的效果:

他们可以确信，通过这种方式，他们将不需要程序员，或者至少可以雇用价格比典型程序员低得多的高级程序员。

似乎所涉及的风险降低了，因为该工具限制了实现者或用户(不要使用程序员这个词!)，因此，他引入错误

的可能性较小。

它似乎简化了整个问题，因为似乎不涉及任何编程(非常复杂)。由于应用程序是动态加载的，因此与通常与J2EE生命周期相关联的复杂性降低了:编译，打包，部署等。

我个人怀疑是否可以实现这样的目标。我们今天拥有的解决方案存在许多问题:

实现者编写JavaScript代码来丰富页面(可以通过开发小部件来解决)。尽管是客户端，但代码仍然会变得非常复杂，并导致一些棘手的错误。

已经有一个可视化工具，但是实现者更喜欢编辑XML，因为它更快，更容易。为了进行比较，我想使用Eclipse Spring WebFlow插件编辑流程XML的人并不多。

解决方案中的重用性非常差(基于XML的复制粘贴)。这会影响生产力和其他一些方面，例如培养业务知识。

由于对工具的不正确使用，存在许多性能和其他问题。不管缩减的运动场如何，总会有出错的空间。

虽然该平台可能比Struts生产力更高，但我怀疑它是否比当今的RAD Web框架(如RoR或Grails)生产力更高。

详细程度

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

在我看来，公司在这方面采取的指导方针是死胡同。你怎么看？

编辑:值得注意的是(这是一些侮辱的来源)许多大公司正在朝这个方向进行试验。请参阅Microsoft Popfly，Google网站，iRise，许多Mashup解决方案等。

Answer 1

总是会有“真实的”语言来完成工作，但是我们可以拖放工作流。

我正在使用苹果公司的Automator ，它允许用户将系统中各种应用程序公开的“ Action ”链接在一起。

Action 具有输入和/或输出，某些 Action 具有UI元素，并且可以将基本逻辑应用于该链。

The key difference between automator and other visual environments is that the actions use existing application code and don't require any special installation.

更多信息> http://www.macosxautomation.com/automator/

我用它来“自动化”许多批处理过程，并取得了很好的效果(每次都令我感到惊讶)。我已经在运行构建和备份，并且每当我需要处理一堆乱七八糟的文本文件时，它就会通过。

我很想知道iHook或Platypus(shell脚本的OSX包装构建器)是否可以让我在python中开发插件...。

肯定有更多这样的应用程序以及OSX应用程序开发人员提供更多支持的空间，但是这个主意是合理的。

在没有主要支持之前，没有多少“ Action ”可用，但是对我的系统的快速检查仅向我显示了我不知道的30个额外的“ Action ”。

PS。 OS-preX还有另一个名为“Filter Tops”的应用程序，其插件集非常有限。