【项目】数字基座（OGAS编辑器探索版）

💡OGAS（俄语：Общегосударственная автоматизированная система учёта и обработки информации，英语：All-State Automated System，全国自动化系统）是一项苏联的全国性网络工程
数字基座 是一个OGAS在新时代下的新尝试，目的是建立全国性的自动化系统，以统一的形式构建数字基础设施，打通各行各业的壁垒，形成一个高效的整体。
🥜姊妹项目：Sait平台开发计划，SAIT平台项目（迭代）说明
项目说明：
1. 引言
从长远看，随着 数社小组 或者 其它类似的组织的不断壮大，对于各类 App 的需求一定会越来越多，而人手必然会面临不足，且各模块的衔接也需要大量人手，到时候需要一个类似【低代码】编辑器的 App，用于辅助或加速生产其它 App 并将它们衔接在一起，同时还需要提供一些基础服务，比如用户服务、支付系统、任务系统、插件市场等等。简单的说，数字基座是一个提供基础组件的积木式的工具型 App，一个可以加速【生产 App 的 App】，将来这些子 App 涉及的面，包括但不限于：影视、游戏、数控机床、自动化农业、数学研究、数据显示、系统工具、中台界面等等。
有人会问，为什么不直接使用微信、企业微信、飞书、淘宝、抖音这样的“基础服务”？为什么要另起炉灶？
因为现有的资本企业之间存在壁垒，数据的流动和页面的跳转存在非常大的障碍，如果我们拥有自己的数字中台或者基础服务，则可以省去各种繁琐的开发和对接，提高整个社区的运作效率。
那么，为什么不使用 IDEA、VSCode 等编辑器，为什么要制作我们自己的编辑器？见 附录A。
数字基座 带来的好处（能解决什么）：
1. 提供基础组件，使得在其基础上生长出来的子 App 天生具有较强的功能。
2. 提供类似低代码的拖拽式编辑方式，使得普通人也可以制作 App，这是与低代码相似的地方。
3. 提供强类型编程环境，使得我们可以精确地、深度地定制应用中的每一个细节，这是与低代码不同的地方。
4. 提供近似 Notion 或 Unreal蓝图 一样的无字符串编程环境，降低用户使用的门槛，提高底层编译器的速度，减少因反复解析带来的性能损耗，同时将来还会提供编译到 C 的能力，解决性能焦虑问题。
凭什么数字基座能做到，而别的平台做不到（区别在哪里）：
1. 其它平台存在壁垒，而我们的没有壁垒，任意同类型组织或集体，都可以共享数据，共享组件。
2. 基于非字符串编程环境，类型不会丢失，文档和注释与类型明确绑定，用户负担轻，操作体验更好。
3. 在其它平台中，写死的界面是第一公民，而逻辑是次要的或缺失的，而在数字基座中，逻辑是第一公民，这使得任意修改都变得极其容易（不论文档编写还是逻辑编写都是拖拽式操作），而无需用户学习多种语言和配置语法。
以上这些，归总起来意味着什么？ 意味着一旦这个基座完成，我们会获得极大的效率提升。不论是单一内容的创作，还是多模块的衔接，都非常便捷迅速，因为所有的功能都基于这个底座，所有内容都是可以自然衔接的。这里的效率提升，跟现有的 SAIT 项目有一定的交集，区别在于，数字基座以逻辑组件为主体，且不专门面向某个特定领域，数字基座面向的是相对泛化或相对通用的需求，用户可以基于数字基座打造其它应用。
也就是说，数字基座更偏向数据和逻辑编辑器，而 SAIT 偏向数据和文档编辑器。两者没有好坏优劣之分，只有适用范围、交互方式和阶段性目标的差别，且由于 SAIT 使用了更成熟的技术（React），所以可以快速呈现，解燃眉之急，而数字基座则是一种探索式的尝试，难点太多，不一定能成功：
2. 方案
怎么解决
先实现最基础的交互逻辑、代码方块的运行和调试，再引入外部功能组件，然后进一步优化体验细节。
产品形式
短期的 交互 界面类似游戏：《70亿人》
长远规划中的 功能 类似：Apple App Store + Steam + B站 + 淘宝 （看着很杂，但所有界面风格都脱胎于《70亿人》，界面风格会保持统一，而功能则进行融合，本质上软件市场和商品市场是同构的，可以融合）
设计原则
A. 统一：尽量不采用多语言和多配置，而是尽量使用一种语言、一种交互逻辑（但可以通过序列化在多环境中传输）。
保持风格统一，不区分文档和逻辑，不区分前后端，一切皆逻辑，一切皆数据、一切皆可运行。
所有功能尽量使用编辑器本身创造的语言来实现（实现一定程度的自举）。
B. 简单：保持简易，简易优先。
C. 自动：服务于自动化，消除尽量多的人工环节。
D. 有趣：吸引年轻人
技术栈
• 前端：Flutter支持的多平台架构，预计开发网页和移动端两个版本供技术与非技术成员使用。
• 服务端： C++、Golang、Node.js 、Rust 等多端支持（仅逻辑和数据层面，不涉及界面）。
• 部署：手机端、Web端、将来可能部署到 AR眼镜、VR 头显端。
• 数据源：任意支持 Key-Value 结构的载体，包括但不限于文件服务、Redis。
迭代计划:
[x] UI 界面
[x] 基本的逻辑方块显示
[x] 拖拽空白处平移画布
[x] 方块的次序调整（上、下）
[x] 方块的父子次序调整（Tab前、Tab后）
[x] 双指缩放画布
[x] 鼠标滚轮缩放画布
[x] 插入点的显示
[x] 白色插入点
[x] 定位到最接近的方块
[x] Tab 退格距离与方块保持一致
[x] 绘制一条曲线，连接白色插入点和绿色拖拽点。
[x] 绿色拖拽点
[x] 超出边界时仍可拖拽
[x] 超出边界时可弹回（左上方弹回）
[x] 拖拽父对象时子对象跟随
[x] 拖拽父对象，并松开时，以动画缓动的形式重新嵌入到队列中。
[x] 同时显示方块的类型和值
[x] 方块功能扩展
[x] 编辑方块的值
[x] 可编辑文本
[x] 可编辑数字
[x] 如果输入不合法的数字则弹出提示
[ ] 参数的显示和定位
[ ] 可编译到简单的 Html 界面
[ ] 可编辑逻辑运算（if、else、goto、for、return等）
[ ] 可封装
[ ] 可保存
[ ] 可搜索
[ ] 可导入（复制）
[ ] 可导入（引用）
[ ] 可分享
[ ] 可执行
[x] 可调试
[ ] 语句可在显卡中运行，如 inGPU( add(128, 256) , 1024*768)
[ ] 历史记录对比（类似 git 代码比较，且支持多人在线编辑同一个逻辑视图）
[ ] 可编译到 C 、可编译到 Rust，对比 AST 执行效率和编译后的执行效率
[ ] 引入影视相关函数（如：调用一个函数处理一个视频，导出到硬盘）
[ ] 引入聊天相关函数（如：开设一个 Room，生成邀请链接，然后弹出聊天窗口）
[ ] 引入游戏相关函数（如：路径追踪光照、面部表情动画匹配语音、显示骨骼动画）
[ ] 引入大数据训练和执行的函数（如：MiniGPT、可调用和显示股市数据）
[ ] 社区构建（贡献排行榜、用户、点赞、评论、转发、博客、教程、买卖等）
[ ] 体验的迭代
[ ] 按钮布局改版
[ ] 伸缩和动画按钮
[ ] 支持键盘操作、支持快捷按键操作
[ ] 支持VR射线的点选和拖拽
[ ] 点击后的声音效果
[ ] 点击后迸发出的粒子动画
[ ] 星空地图
[ ] 摄像机靠近后，挂载用户头像
[ ] 摄像机再靠近，呈现该节点对应用户的动态，点击后进入其空间
[ ] 贡献排行榜（消费排行、点赞排行、编辑推荐榜）
[ ] 函数智能推荐
[ ] 语音 API 支持、引入实时翻译函数。
[ ] 售卖硬件函数，硬件即函数，卖出去后，能自动联网，且可以在屏幕上被调用、被调试。
以上功能有待展开，目前 App的功能完整度约为 6%。
内容发布
https://poerlang.com/ogas
源码
digso/ogas (github.com)
(需获得团队权限方可访问，请联系 @破耳狼 或 @廿一日的船)
相关人员
当前开发人员 @破耳狼 ，参与讨论和 review 的人员 @廿一日的船
欢迎加入、或直接在0群讨论。
附录A
传统编辑软件的弊端：
1. 传统编辑器倾向于容忍太多风格各异的语言和配置语言混杂，没有做必要的融合，加大了新手入门的难度(例如网页开发环境 html+div+css+typescript+javascript+sql+java+node.js+各种配置文件，加大了学习难度)。
2. 没有对语言的风格和功能本身做隔离、没有对性能和界面做彻底的隔离。
3. 没有杜绝代码文件的反复 parse，加大了CPU消耗，增加了卡顿。
4. 传统编辑器大多基于字符串的编辑，边界不明晰，新手容易写出多一个括号或少一个逗号的代码从而报错。
5. 编辑位置（前端、后端）做了太多不必要的区分，不能在同一个地方同时控制所有逻辑。
6. 注释与代码并不完全对应，有时候分不清注释与上下两行代码的关系。
7. 注释文档不能直观呈现，需要额外 parse 运算和渲染，加大了计算量，降低了学习体验。
8. 很多脚本不支持调试，或需要复杂的配置才能调试、或者购买WebStorm才能方便调试。
9. 由于插件的配置环境相对复杂，用户并不能基于函数这种颗粒度来进行快速的“插件”开发。
10. 由于以上种种，各个模块之间存在很多断层，类型和文档经常丢失或分离，加大了模块对接的难度，拖长了项目周期。
解决以上问题，即可极大地加速应用开发。