任何人都可以举例说明成功的非程序员,5GL(不是我确定它们是什么!),可视化,0源代码或类似的工具,业务用户或分析师可以用来创建应用程序?> 我不相信有,我想证明是错的。
在我工作的公司,我们开发了内部MVC,用于开发Web应用程序。它基本上是一个用XML编写的简化状态机(àlaSpring WebFlow)用于控制器和一个简单的基于模板的引擎用于演示。一些好处:
公司目前的趋势(或至少在管理层面)是尝试为需要0源代码的平台生成工具,视觉等。它对客户(或至少在管理层面)有很好的效果)因为:
我个人怀疑这样的事情是可以实现的。我们今天的解决方案有很多问题:
从历史上看,这方面出现了许多失败。由非程序员编写的程序的想法很老,但AFAIK从未成功过。在某种程度上,除了源代码的强大功能之外的任何东西都变得无法替代。 今天,有很多关于DSLs的讨论,但不是非程序员应该写的东西,更像是他们可以阅读的东西。
在我看来,公司在这方面采取的方向是一个死胡同。你觉得怎么样?
编辑:值得注意的是(并且这是一些潜在的来源),许多大型玩家正在试验这个方向。请参阅Microsoft Popfly,Google协作平台,iRise,许多Mashup解决方案等。
答案 0 :(得分:9)
是的,这是死路一条。问题很简单:无论你如何简单地表达解决方案,你仍然需要分析和理解要解决的问题。大约80-90%的(最好的)程序员花费他们的时间,这是真正的技能和思考的部分。是的,一旦你决定做什么,有一些技巧涉及到如何做到这一点(用你选择的编程语言)。在大多数情况下,这只是问题的一小部分,而且对时间滑点,成本超支或彻底失败等问题最不开放。
软件项目中的大多数严重问题都发生在更早的阶段,在这个阶段,您只是想弄清楚系统应该做什么,用户必须/应该/可能做什么,系统会出现什么问题(并且不会)尝试解决,等等。这些是难题,并且改变环境以某种方式表达解决方案,其他源代码将完全没有来帮助解决任何这些难题。
有关该主题的更完整的论文,您可能希望阅读Frederick Brooks撰写的 No Silver Bullet - 软件工程中的本质和事故(包含在20 th The Mythical Man-Month 周年纪念版。整篇论文基本上都是这个问题:软件工程涉及多少工作是必不可少的,以及我们使用的工具,环境,编程语言等的偶然结果是多少。他的结论是,没有技术可以提供高达一个数量级的生产力的合理希望。
答案 1 :(得分:4)
不要质疑使用5GL等的决定,但编程很难。
John Skeet - Programming is Hard
Coding Horror - Programming is Hard
现在,5GL已被认为是一个死胡同。
答案 2 :(得分:2)
我正在考虑包括Ms Access,Excel,Clarion for DOS等产品系列。在这里你可以使用0源代码而不是程序员来创建应用程序。并不是说它们能够进行AI quality操作,但它们可以制作非常有用的应用程序。
答案 3 :(得分:1)
总是会有“真正的”语言来完成工作,但我们可以拖放工作流程。
我正在使用 Apple的Automator ,它允许用户将系统上各种应用程序公开的“操作”链接在一起。
动作具有输入和/或输出,一些具有UI元素,并且基本逻辑可以应用于链。
自动机之间的关键区别 和其他视觉环境是这样的 动作使用现有的应用程序 代码,不需要任何特殊的 安装。
更多信息> http://www.macosxautomation.com/automator/
我用它来“自动化”许多批处理过程并取得了非常好的结果(每次都让我感到惊讶)。我已经让它运行构建和备份,每当我需要处理一堆文本文件时,它就会出现。
我很想知道iHook或Platypus(用于shell脚本的osx包装器构建器)是否可以让我在python中开发插件....
这样的应用程序肯定有空间,OSX应用程序开发人员可以提供更多支持,但这个想法很合理。
在有大量支持之前,没有多少“行动”可用,但快速检查我的系统只是向我展示了一个我不知道的额外30个。
PS。 OS-preX的另一个应用程序名为“Filter Tops”,它有一组更有限的插件。
答案 4 :(得分:0)
Dabble DB怎么样?
当然,就像MS Access和其他非程序员编程平台一样,它有一些必要的限制,以便用户不会让他或她自己陷入困境......正如约翰指出编程很难< / em>的。但它确实为用户提供了强大的功能,而且似乎非程序员想要构建的大多数应用程序都是数据库类型的应用程序。