图形化编程的理解

• 图形化编程的高效率在于阅读和理解，而输入效率是低下的。如果拥有好的IDE，敲代码的输入效率远高于图形化编程；
• simulink、labview、PLC、乐高这几种风马牛不相及的编程环境，之所以能够成功“图形化编程”，根本原因不仅在于这些环境都已经完美抽象成一个个图形和接口，只需要用户直观的逻辑流，更在于这些工具编程的复杂度极低，大部分情况下不超过50根线——在这种情况下，输入效率远远不是瓶颈，你本质上大部分时间是在“连线+试错”，而不是“设计复杂的逻辑和架构”——这种才是“图形化编程”最好用、最高效的场景——哪怕是simulink和PLC，在复杂的前提下你也得敲代码；
• 不是不看好“图形化编程”，而是“一个人如果有1小时的训练时间，足够学会python和javascript来完成基本工作”，这些编程语言的语法并不是普通人学习的门槛，相反“图形化编程”这种“比python更容易上手，一看就会”的假定才是站不住脚的，因为“并不是所有概念都可以抽象成几个元件连线连接”，很多时候反而更麻烦更复杂。

图形化更优还是语言更优，个人认为本质上只取决于一个操作中概念分支（信息密度）的多少。

信息密度低信息量少不代表低端，即使简单的分支也可以组成复杂的逻辑和排列，它可以复杂在逻辑和组合而不是分支与信息的绝对数量。因此根据不同的场合需要合适的信息密度的载体。

1.图形化占绝对优势的情况，操作的分支数量极少

sourceTree 就可以认为是git的一种图形化编程，git本身一共就几十个命令，常用的就那么几个，用图形化表达这种分支很少的情况就非常的优秀，用按钮代替指令输入并无什么不妥。个人认为这个场合图形化编程是可以战胜代码编程的。

sourcetree 我日常使用sourcetree代替95%以上的git操作，很少用命令行

2.二者势均力敌，操作的分支在几十的数量级。

写代码的ide算是一个势均力敌的场合，一个代码ide有很多功能，姑且认为总数在几百，常用命令几十个。现代ide，比如xcode，idea，vs就是图形化编程，vim就是纯命令，vscode介于二者之间。 有的人喜欢vim，只要用键盘敲几个字符的命令来选择使用哪个操作。有的人喜欢ide，用鼠标寻找一下，找到要的操作。这种几十个分支的场合二者势均力敌。

大型ide的分支决策。除了图形化，实际上操作大多数还是基于快键键组合，本质上可以理解为一种文字语言表达分支概念，因此大型ide可以算作图形化和快捷键两种分支决策手段结合。

操作系统的道理也是类似的，打开电脑后运行什么东西，该做什么。分支也是在几十的数量级（一般电脑或者手机常用的也就装这么多软件），在这种场合下纯图形界面占优一点，linux命令行有命令行的好处。但是对于程序员来说，需要花式用软件的各种乱七八糟的特殊功能命令，分支就会上升到几百的数量级，这时候就必须写一个shell脚本来解决问题了。

3.文字方式占绝对优势，操作的分支在几百至几千数量级。

这就是写代码的情况了。通常一个工程写到后面，几千个类，函数，变量很正常。在这种情况下只有文字可以表达这种分支关系。图形化界面不管怎么做都没有办法表达这种程度的分支。图形化不管多努力都没有办法表示几千个分支的函数决策，强行做出来要不就会变成密集恐惧症一样的连线，或者点开八级菜单才能找到函数。

那么回到原始的问题，什么场合下可以使用图形化编程？

如果有一种编程语言，它的概念只有几十个，所有标准库的api加起来不超过100个，写出的程序换算成代码语言不超过100行。那么它从理论上来说就就可以用图形编程。单就编程语言的流程语句来讲，完全可以使用图形化，但是由于函数api没有任何图形化可能，因此为了工程考量，即使是图形化依然需要用文字表述部分内容。

实际例子也是有的，比如shader语言，很多时候有人会认为是因为美工没有文化才要用图形化编程伺候他们，实际上并不一定是如此，shader复杂归复杂，但是单个分支确实不多，符合上一段所述的情形。即使简单的分支也可以组成复杂的逻辑和排列，它的复杂复杂在逻辑和组合而不是分支的绝对数量。

Unity的shader forge

UE4的蓝图是一门现行有较广泛使用的图形化语言，在处理一个挂载物体上的小脚本的编写上并无问题，通常体量也很小，完全符合上面的论述。需要注意的是有一些蓝图被连成了蜘蛛网一样，然后来喷图形化我觉得不好。蓝图连成蜘蛛网是蓝图编写者的问题而不是蓝图的问题。试想即使用代码编程，也有人把代码写成了一个函数1000行完全不知道在干什么，代码编程一样可以写的乱作一团，需要用代码规范和设计模式来处理。图形化编程不需要写代码，但不代表它不需要设计模式啊。

最后举两个游戏的例子。

这是明日方舟的基建页面。其中图中那些个睿智图标，就是名字上面，代表角色的技能属于哪个分类的那个图标，原来是用文字表述的。突然有一天策划一拍脑子给换成图标了，我见过的玩家几乎没有不骂街的。如果他但凡有一点理工科的思维都不会做出这种事情。

这个设计失败在哪呢? 就是在这个图标的场合产生的分支过多。

假设现在有这样的一个需求。需要用一种东西（文字vs图形）来区分100个不同的概念，并让人容易理解每一个是干什么的。这个需求用图标是极难实现的，还会带来大量的学习成本。这是一件很没有意义的事情，因为这件事情已经有人做过了，就是发明文字的人。 这个需求的性质就和，你用一个图标来表示“日”字，再用一个图标表示“人”字，最后用一个图标表示“爨”字（前两天刚认识的，音cuan）。最后绞尽脑汁画了图标和图形来做了这个概念，最后一看，直接用汉字多好嘛。

这个设计的问题就是一个需求的分支信息和种类数已经超过了图标（或图形界面）能承载的信息密度上限。因此只有用文字才能表达这个信息密度，图形化编程表达不了这个信息密度。如果图标一共只需要十几种的话可以用图标，但是这个场合的分支已经差不多接近一百种了。

最后举一个相反的例子，就是P社游戏，P社游戏的分支已经接近甚至事实上已经超过了图形界面能够容纳的上限了，和一个现代大型代码ide相比不分上下。因此想要更好的表达和继续在这个基础上放飞自我，在N级的图形点点点已经带来了一定的负面体验，P社游戏需要一个命令行系统来进行游戏中各项指令的下达。这也是为什么我觉得编程是一件很愉快的事情，毕竟写程序和这种策略游戏分支决策的体验是很像的。

这种程度的复杂界面显示起来问题不大，但是操作起来问题很大。总是很难能找到对应的按钮在哪里，如果可以命令行输入的话就很舒服了。