- 主题:我想搞个图形化(模型化)编程的github，大家看看有没价值？
图形化编程，我一直有如下困扰：
一是怎么编写循环。就是for/while，用图表现起来特别费劲。程序控制三大要素，我用图只能很方便地表达判断（用个一入多出块）和跳转（用箭头），但是循环的表达太臃肿了。。。
二是怎么表达复杂数据结构。struct、数组、链表、map、指针，这些数据结构，低代码都很难表达。
【 在 wjhtingerx 的大作中提到: 】
: 就是我业余搞了套基于云原生的图形化开发工具，可以通过拖拖拽拽生成软件基础架构，然后嵌套的每个功能模块可以通过类似scrach那种搭积木，也可以手写代码。
: 1. 设计即开发，你把架构设计图画完了，也就是自动把软件框架生成了；
: 2. 零环境的云原生环境，包含设计、开发、编译、生成等全部在网页和后台完成，本地不需要准备任何环境。比如你要写个树莓派应用，不需要提前准备任何资源，直接出来的是应用或镜像。
: 3. 精心设计过的底层架构和中间件，适合绝大多数嵌入式软件场景，尤其是以数据流为基础的控制领域；
: 4. 目前开源界，以源码项目为呈现的智力资源，共享的难度和成本还是很高的。我这个实际上是把架构和功能模块高度抽象和约束化，用图形化的方式，把代码模块的分享变得非常容易。
: 不知以上说明白了没有，欢迎大家讨论。
--
FROM 125.35.5.*
你的3个思路还是没有提及复杂数据结构、数据存储的处置方法。这些在正常点的后台服务都要用到。
我现在大概能理解，在嵌入式平台上，数据大都是流式的、不存储（用不到结构、数组和链表等），也很少在多数据实体间交互，所以比较适用你的3个思路。
【 在 wjhtingerx 的大作中提到: 】
: 我思路是这样的：
: 1. 图形化分为两个层次，架构和功能。我发现，几乎所有的嵌入式软件都可以抽象成数据流框架和数据处理两个层级，合理搭配数据流就可以形成任何框架功能。框架层对数据本身做了各种诸如缓冲、对齐、触发等预处理，让数据处理层次不包含任何架构特性，配置好需求，纯粹做数据的
: 静态算法就行。如果某个数据处理太复杂，那么就再拆解。
: 2. 数据处理模块，本身可以选择图形开发，也可以手写（支持多种语言），怎么方便怎么来。图形开发，也就是基于模型开发，其实主要目的不是开发效率，而是健壮性和维护性，因为不容易出错。另外，图形模块，更容易无缝部署和迁移。
: 3. 对于数据流里的数据表现，复杂数据其实还是以C结构为形式。只是提供了一个界面工具，能够快速的创建C结构体。可以不关心类型（内部默认都生成int），也可指定类型。少的数据直接就是数据参数，不需要结构类型了。
--
FROM 125.35.5.*
按我的理解，这只是把困难藏起来了而已，当然也可以看作是扬长避短。
当复杂数据的处理，占据了一段程序的主要体量时（比如非嵌入式平台上的后台服务，非流式服务），那么低代码这种表现形式的边际效益就大大缩减了。
labview程序为什么可以低代码？因为它贴近数据采集层，它封装得最好的就是板卡驱动。
很多消息调度中间件为什么可以低代码？因为它是流式服务。
【 在 wjhtingerx 的大作中提到: 】
不是，是说架构级已经把常用的数据处理方式都处理了，让功能模块对复杂结构依赖降到最低。
比方说，一个功能数据处理，可能需要对输入数据做一定缓冲，然后做一定排序，然后在时间上做一定对齐处理之类的。我在架构中间件把这些常用的处理方式都处理掉，给你的就是你能直接当次运算的数据，你也就不需要那么多复杂结构（数组啊，链表啊，同步啊之类的）了，直接操作数据就行。
--
修改:lipp FROM 125.35.5.*
FROM 125.35.5.*