人心中的成见是一座大山,数据转换思想

212 天前
 muchan92

https://github.com/rainforesters/imsure 一直在用,确实好用,已经离不开了

https://github.com/rainforesters/imsure-demo

上周发了一个主题后评论区颇为热闹,就用此文统一回复下吧。我不想争论是非,只是我觉得这个理论就像日心说一样值得被更多人知道,应该被更多人知道,哪怕它和日心说一样被证明是错的,也算挣脱了思维桎梏,启迪了方向。若值得在茶饭之余引发讨论就更好了。


程序的本质是数据转换,那么逻辑过程的意义可以一概视为根据 input 转换为 output ,所以我们可以试着改变一下程序的编写方式,

从:

f(input) ⇒ output

进化为:

output ⇐ Watch_transform(input)
Rule = Watch_transform
output ⇐ Rule(input)

为了让观察转换变得可行,我们把 input output 作为字段都定义在抽象的 Struct 类型上,

那么就得到了:

self.output ⇐ Rule(Struct.input)
self 是 Struct 的实例
Rule 就可以在 self 未实例化之前,提前定义在抽象的 Struct 类型上;同时也允许 input output 在 Struct 的不同层级

这就变为了纯粹的数据转换链。只要依赖的 input 更新 output 也会随之更新,整条链也随之更新到最终稳定状态,既简单又保证了确定性。在转换链中,每个节点只干一件事,只需观察依赖的前置数据而不必考虑后续自己会驱动谁或被谁所依赖,彻底摆脱逻辑控制流。

这种写法就像从算术方法到方程解法一样具有普适性。
从传统编程需要根据不同业务需求设计不同的实现过程,到全然不用设计,只套用一条普适的方法就行:

  1. 定义数据结构。(设未知数)
  2. 定义转换规则。(列方程式)
  3. 为字段赋值。(代入已知数)

至此,就再也不需要推导业务逻辑了。


若你看懂了以上内容,那这段自不必说,若没看懂请继续。

传统逻辑过程可以细分为两部分:

  1. 先把将要进行转换的 input output 建立关联。
  2. 然后进行转换,纯粹的转换算法。

传统写法下 80% - 90% 的代码都在建立关联、维护关联,其实转换算法的代码很少很少。
新写法中建立关联就像呼吸一样简单。

8436 次点击
所在节点    程序员
56 条回复
llsquaer
211 天前
觉得最后一段在 CPU 我
cyoking
211 天前
@ZiChun 太秀了哥
linkopeneyes
211 天前
或许你需要一个 rxjs ?
lyxxxh2
211 天前
@scyuns
俺也一样,看着文字,一脸懵逼。
看到他文档代码才知道他说的啥。
正常我们是调用函数来改变数据。
而他: 数据发生改变 -> 调用函数
kamilic
211 天前
以前我也很喜欢 rxjs 这类的思想,定好结构后让数据自然流过我预设的规则,那些不懂的都是菜狗。
看了 staltz 的演讲,用它的 cycle.js 觉得很牛
这么美丽的结构,仿佛就能解决一切(狗头

1. 实际情况下也没有多少业务会处理这么复杂的数据流,很多时候局部 + 全局就能解决问题
2. 接受的人懒得关心整体架构层面上思想再来具体理解你的代码,部分通用抽象加业务层面条可能更好看(虽然持保留态度

这玩意貌似就是懂的人爽,一般人接手大概都是想骂娘的吧,不然函数式编程和响应式编程怎么需要传教呢(狗头保命
ming159
211 天前
首先 挺楼主,从工作中凝练出思想,动手实现,再应用到实际中. 这本身就吊打一众喷子了.

另外,我的理解是这个库是可以大幅度减少很多代码的. 或者说是这个库帮我们简化了很多垃圾代码.
比如 定义一个函数,里面判断数值是否变化,或者是否满足条件了,如果满足则去调用另外一个函数. 跳过这些垃圾代码. 直接考虑的是. 1.条件满足的标志是什么? 2.满足后如何处理?

另外 规则执行时得到的是 Promise 对象.这一点就可以处理很多场景了.
个人感觉非常不错,楼主加油.
willatman
211 天前
题外话,我一般判断一个理论可不可靠,一看有没有引用。如果没有引用就看作者是否业内大佬。 如果没有引用也不是大佬,基本上是民科。其理论可以不看。 如果称这是理论的话。
slert
211 天前
有点走火入魔的感觉。首先这个理论非常的不新,其次也并不是什么银弹,不可能存在“从传统编程需要根据不同业务需求设计不同的实现过程,到全然不用设计,只套用一条普适的方法就行”。业务逻辑你还是要实现,可能就要换一种很别扭的方式。真想证明的话,拿出一个用这个写的实际项目来看看,很好奇你一直在用是用在哪里。
建议多看看市面上的东西,不要闭门造车了。
aboutier
211 天前
你们说的是这个吗?

https://cn.redux.js.org/
nuk
211 天前
@muchan92 trampoline 可以实现尾递归,我拿来写 shell 也能尾递归
rupert
211 天前
@ming159
这语气跟饭圈很像,“哥哥都那么努力了”
别只口头支持,订阅一下呗
ming159
210 天前
@rupert 说话阴阳怪气,这是讨论技术的地方,你一个关注娱乐圈的人,来这里丢人现眼干嘛....无语. 这库你理解解决的是什么问题吗? 呵呵了....
flyingghost
210 天前
从本质上来说,这个结构没错了,抽象的世界的本源确实很简单。输入,f ,输出,咦这不就约等于图灵机了吗?
但这图景不能放大。因为,事情的复杂度如果是 100 ,被抽象成为 3 了,必然是因为抽象忽略了细节。忽略,并不是消灭,物质是守恒的,复杂度或者说信息也是守恒的,它只能被忽略、被分治、被自顶向下,但不能被消灭。
站在一定 level 看事物依然有价值,就像我儿子站在正数、零、负数的高度看自然数一样,瞬间就把正无穷通过分类法简化到了 3 类。但一个 level 说一个 level 的话,不能因为这个 level 得到了 3 的视图,就说自然数本体也就 3 个对吧?

既然不得不下沉,那就下沉到每个抽象内部去。输入有多少种?世界的真实状态有多复杂,就有多少种。用户输入(各种各样的格式)、自然输入(例如时间)、外部依赖输入(例如网络)、异常输入(这耗费了程序员一半心神)。。。我还能继续数,继续下沉。
f 有多少种?不敢数,怕指头不够,反正我这业务逻辑写了好几 M 了。别说 Fn 的个数,就有限个,排列组合一下呢?键盘上就有限个字母还能排列组合出莎士比亚呢。

不反对哲思,我甚至提倡哲思,不管对不对过程都是值得鼓励的。但反对哲思结论跨层应用。讲个笑话:
老爷吃饭不吃屎, 饭进肚里变成屎。 吃饭变屎多费事,不如当初就吃屎。
lucasdev
210 天前
@ming159 #52 你说的这个理解不就是响应式编程? React 状态和钩子,Vue 计算属性和监听器、RxJS 、Redux 、Vuex ,还有楼上老哥给的“纯 TypeScript 响应式代码”不都是?用得着 op 在这故弄玄虚?
csh010101
210 天前
k8s 是不是也是这样的。。
csh010101
210 天前
@csh010101 好吧 k8s 更多的是声明式 ,虽然都有 event drive 但是响应式 主要强调的是数据的流动

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1122487

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX