- 主题:现在有很多图形化编程语言，编出的软件跟正常代码生成的有什么
车上单一功能ECU的代码数量一般在几万行到几十万行C代码，都是用Simulink模型自动代码生成的，
这个模型也没有多大或者多复杂。
图形化编程关键点是模块化与层次化，而不是把图形画多大。
【 在 ArchLinux 的大作中提到: 】
: 你这么一说出来，我可以想象到一个上千行的代码要变成图形会变得多大。
:
--
FROM 122.238.140.*
图形化编程的用户是比较多的，尤其是在一些涉及到复杂电子控制的行业，比如汽车电子、航空电子、工程机械等，图形化编程是主流的编程方式。
【 在 eGust 的大作中提到: 】
: warcraft 3 的地图编辑器就带了图形化界面。功能还是比较完整的，不过受限于当时的技术，wc3 的脚本语言没有 gc，很多资源都必须手动释放。导致实际上只有很少人用，一般都是直接写脚本的，而且转换的过程不可逆，也就是说再没办法转回图形方式了
: 其实 blockly 的概念挺好的，个自带的那些东西也都挺完整的，你说的 and/or 之类的功能都有。而且自带能转成 lua、js、py 这些比较主流的嵌入性脚本，我个人感觉对非程序员来说已经非常友好了。不过具体到用户的话，我怀疑依然不是人人都能用的东西……
: 所以归根结底，图形化编程的问题是目标用户实在太小众了，就是一个不上不下的东西。稍微动点儿编程的，写点儿简单的脚本语言应该问题不大。剩下的基本上就是那种根本扶不起来的，给他啥都没用，不适合干这种活儿……
: ...................
--
FROM 122.238.140.*
主要是NLP技术突飞猛进啊，这几年基本上领域内的理解能力已经完胜人类了。
现在在搜索引擎上打一句话，实际上就是后台的机器学习芯片帮你做个阅读理解题了
【 在 No1 () No1 () 的大作中提到: 】
: 是不是就是wolfram和github那种用自然语言或关键字描述个问题，他把代码和结果就给出来了，有时候还挺精确的
: 其实人类确实应该分门别类构建统一的知识库，一般人在一个行业一辈子能碰到的问题也就那么多。
--
FROM 27.91.71.*
simulink存在的目的就是让非cs专业的人能享受科学计算吧
【 在 spadger (void*) 的大作中提到: 】
: simulink很成熟没错，但是simulink搭出来的模型就不见得了，很多用户只停留在用si
: mulink搭模型，看现象的阶段，对于模型后面的原理是不理解的。这样的情况下想用好
: 很难。
: ...................
--
FROM 27.91.71.*
图形的缺点是比较难输入，但优点是明显的，人脑处理图像比处理序列信息高效得多
【 在 ECUCoder (Engineer) 的大作中提到: 】
: 图形化编程的用户是比较多的，尤其是在一些涉及到复杂电子控制的行业，比如汽车电子、航空电子、工程机械等，图形化编程是主流的编程方式。
--
FROM 27.91.71.*
图形化的最大好处是减少拼写错误
手头一个图形化生成的模拟器
控制系统从前往后调用就可以
流体网络的计算涉及到矩阵，随便加个模块或连接线就要重新建立矩阵，手写要吐血
仅仅赋值和模块调用的代码文件有6000多个，70M大小
涉及的变量有近200万个（类似全局变量），都是下面这种风格
C14A12_13_14_B52_MV_IN
C14A12_13_14_B53_SV_IN
C14A01_B27_SV_IN
C14A20_B19_MV_IN
C14A20_B17_SV_IN
手写的话，写错一个没几天时间找不出来
【 在 ECUCoder (Engineer) 的大作中提到: 】
: 车上单一功能ECU的代码数量一般在几万行到几十万行C代码，都是用Simulink模型自动代码生成的，
: 这个模型也没有多大或者多复杂。
: 图形化编程关键点是模块化与层次化，而不是把图形画多大。
: ...................
--
FROM 221.221.162.*
这个不能用点数据结构整理下吗？矩阵、链表，树装个几十万变量没问题啊
【 在 dilemma 的大作中提到: 】
: 图形化的最大好处是减少拼写错误
: 手头一个图形化生成的模拟器
: 控制系统从前往后调用就可以
: ...................
--
FROM 183.95.135.*
anyLogic呢？
【 在 spadger 的大作中提到: 】
: simulink很成熟没错，但是simulink搭出来的模型就不见得了，很多用户只停留在用si
: mulink搭模型，看现象的阶段，对于模型后面的原理是不理解的。这样的情况下想用好
: 很难。
: ...................
--
FROM 183.95.135.*
这个不如presagis的vaps xt
【 在 Lappis (拉皮斯) 的大作中提到: 】
: 标 题: Re: 现在有很多图形化编程语言，编出的软件跟正常代码生成的有
: 发信站: 水木社区 (Thu Nov 25 00:18:11 2021), 站内
:
: 还有Ansys的Scade
:
: 【 在 ble 的大作中提到: 】
: : matlab里面的simulink也算一种图形化编程吧，但是论质量成熟度已经是工业化工具了，所以不能一概而论。
: :
: : 【 在 No1 的大作中提到: 】
: : ....................
:
: - 来自「最水木 for iPhone 11」
: --
:
: ※ 来源:·最水木 客户端·[FROM: 194.132.208.*]
--
FROM 49.5.10.*
不会拷贝粘贴吗？
这还能出错？
【 在 dilemma (何日骑鹤返仙乡) 的大作中提到: 】
: 标 题: Re: 现在有很多图形化编程语言，编出的软件跟正常代码生成的有
: 发信站: 水木社区 (Fri Nov 26 11:48:16 2021), 站内
:
: 图形化的最大好处是减少拼写错误
:
: 手头一个图形化生成的模拟器
: 控制系统从前往后调用就可以
: 流体网络的计算涉及到矩阵，随便加个模块或连接线就要重新建立矩阵，手写要吐血
: 仅仅赋值和模块调用的代码文件有6000多个，70M大小
: 涉及的变量有近200万个（类似全局变量），都是下面这种风格
: C14A12_13_14_B52_MV_IN
: C14A12_13_14_B53_SV_IN
: C14A01_B27_SV_IN
: C14A20_B19_MV_IN
: C14A20_B17_SV_IN
: 手写的话，写错一个没几天时间找不出来
:
: 【 在 ECUCoder (Engineer) 的大作中提到: 】
: : 车上单一功能ECU的代码数量一般在几万行到几十万行C代码，都是用Simulink模型自动代码生成的，
: : 这个模型也没有多大或者多复杂。
: : 图形化编程关键点是模块化与层次化，而不是把图形画多大。
: : ...................
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 221.221.162.*]
--
FROM 49.5.10.*