为什么至今还没有没有一个图形化的系统，只需要我们写写画画或者点几下鼠标就能实现编程?
我们都知道Windows出世以前大家都是用命令窗口来实现各个计算机功能的，后来就有了图形化界面，一切都只需点鼠标就行了，再后来有了Linux，开始的Linux仍然是命令窗口，后来也有了自己的图形界面版本，但是现在编代码的码农们为什么始终得不到解放？或者说是没有这么一个用于编程人员的简单的操作界面，码农，形象吧，现在的农民都靠机械化了，而现在的码农还是无法翻身，为什么？
有很多，我之前也尝试过使用可视化编程工具进行开发。
应该说这一类可视化编程语言（Visual Programming Language）开发出来的目的就是降低编程的上手难度，以及便于调试。但这只在逻辑比较简单的情况下适用，一旦牵涉到写核心部分比较复杂的算法，这类语言只会拖累开发速度。
比如说稍微复杂一点的逻辑最后出来大概就会变成这样......
显然，这已经违背了VPL设计出来的初衷了。
虚幻引擎的blueprint我个人还是持保留态度，因为哪怕是官方给的例子也只是简单的小游戏，即便如此，blueprint的复杂程度也已经让人头皮发麻。
所以我的结论是，没有银弹，题主还是老实点先把代码撸好吧。
自由度越高的语言或工具，你需要提供的有效信息就越多。
拿刀切肉的话，你需要告诉你的胳膊和手从哪个角度切，用多大的力度切；如果是工厂自动切片的机器，那么可能只需要按下按钮。
虽然使用自动切片机器需要的信息少得多，但同样其自由度也远比一把刀小，比如只能用来切肉而不能用来削苹果。
一个需要三个变量的函数，比起一个只需要三个变量中两个的同类型函数，理论上应该能做的更多，自由度更大。如果不是，那么显然额外多的那个变量并没有被函数使用，是无效的信息。
对于大部分主流编程语言，基本上百分之90%以上的信息都是编译器需要的有效信息，无法再精简了；而剩下的10%的无效信息也都大多关乎信仰，比如函数后的大括号是否换行、缩进用tab还是空格、如果缩进用空格那么是两个还是四个还是八个、变量名首字母是否大写、变量名单词之间是用-还是_还是用大写字母等等，这些当然也不能舍弃。
那么问题来了，如果我们使用图形界面但希望维持同样的自由度，那么相较之文字界面，我们可以减少多少无用的信息呢？可能并不多。反而，我们可能额外要添加很多新的无用的信息，比如派生类的位置要在基类的右边还是下边还是上边等等。是故，不提原有的有效信息怎么都要输入，无效信息反而多了，效率不但没有提升，反而下降许多。
而如果可以牺牲自由度的话，很多编程现在已经可以通过鼠标点点画画完成了，比如已经有人提到的RPG Maker，又比如很多软件都提供的宏录制功能——开启录制之后，你做一遍操作，然后这一次操作就被编为宏，可以在以后调用。对我们这样的程序员来说，点鼠标比敲程序痛苦多了，一千多行的程序一个下午就能敲出来调对，你让我画流程图我可以死给你看……
以前我因为C程序课程报告要画流程图还专门写了个从程序“编译”出流程图的软件呢……说白了你这个问题就好像在问“为什么大家都要用文字来表述意思而不是画画”，你不知道原始人都是在墙壁上画画来表示意思的吗……
想起来，以前提过一个问题：如何高效地看复杂一些的节点图？ - 图像处理。这是放在问题补充说明里的图：
如果要是用图形化系统编程，差不多只能做成类似这样的节点图的形式。这种节点图要这样读：
- 最左边是输入，最右边是输出，从左往右读；
- 每一个节点可以看作一个函数：接受一组输入，生产出一组输出。节点之间通过连线连接起来，像工厂流水线的传送带一样连接每个加工机器；
- 所有数学运算、逻辑判断以及高阶功能都可以看作节点和节点的组合；
这样看起来已经够眼花缭乱的了吧，而且这张图顶层（没有被绿色遮罩的）部分，仅仅是底层那张大节点图的一个子模块而已。所以可以看出图形编程系统的最主要缺点：如果工程的复杂度稍微上去那么一点儿，那么相对于文本代码来说更不易读。
不过话说回来，如果逻辑复杂度要求没那么高，并且节点模块功能分类清晰的话，其实用节点图编程更易学、易读，并且目前在业界里的应用已经挺广泛了的。比如
Unity 的 Shader Forge 插件（Shader 编辑器）：
编程的难度不在于敲键盘，而是所要实现的逻辑的复杂度。
Scratch - Imagine, Program, Share
MIT 开发面向 12岁以下儿童的可视化编程“玩具”。
就这种人家认为“玩具”级别的工具，当初在大学计协向“大学生”们科普学习曲线都陡峭的可怕.....局限性还如此之大。
工业级应用编程还是老老实实手撸吧.....233解释一下，最初知道 Scratch 的时候，是在哈佛大学 David J. Malan 教授的公开课 CS50 中介绍的。因为 CS50 中面对了大量非计算机专业的学生，所以利用趣味十足的 Scratch进行启蒙。
但 Scratch 也是作为启蒙阶段一两周就带过的内容，最后上的都是工业级的语言（C语言等等），涉及的也是实际的编程开发。而我们当时计算机协会向计协会员普及相应的编程知识时.......T . T #剧本里可没这一条......
这东西好像N年以前就有了，Authorware算不算？labview应该也算
事实上早就有了，而且还很流行。
你听说过Lego NXT-G么，对，就是那个给乐高智能积木编程的语言。
目前的TIOBE排名是50-100名之间，曾经排进过前20， 这已经是非常令人吃惊的程度。
虽然NXT-G是非常工业化的东西（绝不只是为了做个智能小车玩玩的），但是很显然他的缺点同样明显，我初中、高中的时候参加机器人竞赛，写这个东西十分痛苦。。。因为一旦涉及复杂算法的描述，整个图形就会变得混乱不堪，到处是飞线。。。
NXT-G的好处是直观，程序即流程图，如果没有很复杂的或与非、循环之类的话，还是不错的。NXT-G的初衷是为了降低非计算机专业人士开发程序的门槛而并非是要做成一个效率工具。其实并非完全没有，但是要么功能非常有限，要么极其繁琐。
编程的本质，是人教电脑做事。告诉电脑什么情况下，应该怎样做。人将自己的想法翻译成代码，然后编译器再将代码翻译成电脑能理解的指令。以后执行这些指令时，电脑就会根据它们的指示，处理输入产生输出。
只要用常理考虑就能知道，这件事在本质上就是非常繁琐和复杂的。即使你教的不是电脑，而是人，只靠表情动作也只能教会最简单的东西。稍微有些细节和深度的内容，不靠某种语言来表达是不行的。而对于没有真正思考能力的电脑来说，他只会严格按照指令行事，不用某种语言来表达相应的指令，是极其困难和繁琐的。
这其实也是大量命令行程序存在的理由。因为当事情复杂到一定程度时，用一套预先定义的指令直接下令，往往是效率最高的办法，无论是对下令的人，还是对执行的人都是。当然，这需要耗费时间去学习这套指令，但是为了效率提高这是完全可以接受的。所谓编程，就是向电脑发出一系列指示。编程的手段，无非是描述这些指示的手段。
描述的手段可以以种种方式变得更有效，但这些指示本身无法被自动制造出来。比如如下指示：
如果输入为1，则输出2，否则输出0。
无论你如何优化对以上指示的描述，用图形也好，用打字也好，用语音也好，甚至用扫描脑电波也好，仍旧需要程序员明确表达以上指示，因此，编程的复杂度不可能被无限简化。任何表达方式也做不到。光是把需求表达出来就已经是一个很复杂的过程了
我就是不怎么懂代码和C++的小白，然而别人写的再复杂的blueprint，我只需对着官方文档对那些特定函数或小方块的解释，一会就能搞明白一个复杂的蓝图是如何工作的。
蓝图真的是个很好的东西，不解释了。有的。uml建模后直接生成代码的软件多的很。并不怎么好用。
你能用简单的几个步骤表达清楚你要的功能，还能让程序员理解，你就比大部分产品经理强了……
Agilent VEE
不会有人在正经工作中考虑这种方式的。
规模上去以后呈现就会很困难，而且“图”其实不是一种方便人类阅读的形式，人还是更适合平面化的呈现方式。首先，你没定义清楚“编程”和“图形化”的含义。乐高机器人用的拖拽算图形化编程么？UML根据类图自动创建框架代码算么？用工作流引擎修改已有程序流程算么？关键在于，真正复杂的逻辑，你没法纯靠拖拽方框来实现，你总要往里面写描述性的文字吧？这就不是纯“图形化”了。
其实程序写出来是给人看的。机器不那执行你写的程序，编译器也只关心你写错了什么。所以相对来说，还是文本比较好。
点点戳戳的过程，别人不容易理解，这样你编写的程序就不能演进。而且你自己也搞不明年，显然是不靠谱的。
就算计算机有了一定的智能，和其沟通还是需要通过比较严谨的文本的。估计和合同差不多。点点鼠标、戳戳屏幕就能编程的环境早就有了哇。
题主需要的关键字是Visual programming language，或者叫Graphical Programming。用对关键字就能找到各种资源了。例如：Alice (software)https://www.touchdevelop.com/推薦閱讀：
※考上計算機二級什麼水平,能開發操作系統和桌面應用不?
※如何評價王垠這個人？
※遊戲中非人形boss碰撞到底是怎麼處理的?
※用vim打開後中文亂碼怎麼辦？
※gvim 為什麼這麼多年沒更新了?