为什么大多数程序员不看好图形化编程？

xiaozongpeng · 发表于 2021-8-3 20:06

那他们又如何评价simulink和gh的呢？

fwalker · 发表于 2021-8-3 20:13

其实Zachtronics都帮你想好了：因为图形化编程只适合少量的“原子操作”。
比如Infinifactory（《无限工厂》）这是3D的编程，必然要图形化：
Save 50% on Infinifactory on Steam而Spacechem（《太空化学》）这就是完整的2D图形化编程：
Save 75% on SpaceChem on Steam因为它要求你要考虑collision和严格的时序，而且可以使用的操作元件很少，所以用图形化编程非常直观。
同理在Opus Magnum（《巨著》）中：
Save 50% on Opus Magnum on Steam由于机械元件的操作非常固定，因此依然是纯图形化编程。
这些破事在MOLEK-SYNTEZ中发挥到了极致：
Save 51% on MOLEK-SYNTEZ on Steam要命，不要再虐我的脑细胞了。
而SHENZHEN I/O（《深圳I/O》）就从另一个角度告诉你，当操作变得复杂的时候，图形化编程也需要文字编程相辅相成：
https://store.steampowered.com/app/504210/SHENZHEN_IO因为每个可编程芯片都有不同的操作指令和逻辑，如果每个芯片都用对应的图形化编程，就无形之中提高了操作难度，并没有提高效率。
到了EXAPUNKS，复杂度的提高就直接让你文字编程了：
Save 50% on EXAPUNKS on Steam这要是每个小EXA都用图形化编程写一下你还不如直接鲨了我。
所以要不要图形化编程，还是和需要怎样的操作有关。
至于说常规的通用编程语言，用图形化编程手可能会断。

mastertravels77 · 发表于 2021-8-3 20:22

图形化更优还是语言更优，个人认为本质上只取决于一个操作中概念分支（信息密度）的多少。
信息密度低信息量少不代表低端，即使简单的分支也可以组成复杂的逻辑和排列，它可以复杂在逻辑和组合而不是分支与信息的绝对数量。因此根据不同的场合需要合适的信息密度的载体。
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社游戏需要一个命令行系统来进行游戏中各项指令的下达。这也是为什么我觉得编程是一件很愉快的事情，毕竟写程序和这种策略游戏分支决策的体验是很像的。
这种程度的复杂界面显示起来问题不大，但是操作起来问题很大。总是很难能找到对应的按钮在哪里，如果可以命令行输入的话就很舒服了。

七彩极 · 发表于 2021-8-3 20:29

simulink、labview、PLC、乐高这几种风马牛不相及的编程环境，之所以能够成功“图形化编程”，根本原因不仅在于这些环境都已经完美抽象成一个个图形和接口，只需要用户直观的逻辑流，更在于这些工具编程的复杂度极低

xiaozongpeng · 发表于 2021-8-3 20:36

且不说图形化，单说编程语言，世界范围内叫的出名字的就得好几百种。
编程语言也是竞争激烈的啊，不是说你一拍脑门发明个语言就得被人接受、看好的啊。
得讲理啊，
能被“大多数程序员”看好的语言，总共就那么几个，哪个掏出来都是能吊打一片的，都是能解决某几个领域的大问题的，
你说目前有什么领域是对于大多数程序员来说非“图形化编程”不可的，或者被“图形化编程”解决了正面的、划时代意义的问题么，还真没有
连lua、dart甚至golang还没被“大多数程序员”看好呢，哪就轮的上别的语言啊

zifa2003293 · 发表于 2021-8-3 20:44

图像的表达力和精准度有限，信息冗余和歧义多，特别是无法(或很难)表达抽象，抽象是编程之魂
相对的，我看好公式公理化数学化高阶逻辑化编程.

TheLudGamer · 发表于 2021-8-3 20:45

道理和为什么我们不用象形文字而是现代的文字体系完全一致。
字母→词→词组→句
每一层都是一层信息压缩，对应大脑的分类检索，因此可以容纳极高的信息密度。
图形化信息密度低。
而编程语言致力于提高信息密度，以更少的字符容纳更高的表达力来提升代码的可读性和开发效率，提供更丰富的元信息以供编译器使用。
字母是一层封装，单词是一层封装，关键字和标准结构是一层封装，在此之上还有类型声明，显式异步标记，可变不可变标记。
随着语言的发展，还可以定义更多的概念。
每一层都相当于一次信息的压缩，因此才带来了超高的信息密度。编程语言与自然语言在词组和结构化这一层分裂，根本原因是编程语言不能是模棱两可的，必须通过规范来确保没有歧义，因此不允许像自然语言一样的随意组合。
而图形一层就消耗了过多的空间和算力，空间利用率极低，学习成本极高，辨识度低，特征难以规范，因此不论在信息压缩还是索引构建上，都远弱于自然语言。

至于中文编程的缺点，主要是汉字输入繁琐，其它问题上并不输英语，然而这点影响还挺大的。

c0d3n4m · 发表于 2021-8-3 20:53

因为这货本来就不是给程序员用的

mastertravels77 · 发表于 2021-8-3 20:57

玩了一下乐高boost
写了个斐波那契数列递归
用代码一下子就完成的事，
要拖动很多组件
可读性也非常差
所以我还是教孩子写代码
并不认为图形化编程会更容易理解

mastertravels77 · 发表于 2021-8-3 21:07

这不是实践给出的结论么。
除非目标客户根本无法掌握面向字符与符号的编程，否则图形化的效率一定更低，无论是程序员的编程效率，还是开发图形编程IDE的开发效率。
其实参与商业编程的程序员基本都不会对此产生疑问。绝大多数情况下，根本没有办法使用图形编程工具做出符合产品需求的东西。

		自动登录	找回密码
密码			立即注册

为什么大多数程序员不看好图形化编程？

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源