|
主要是关于依赖关系在编程语言领域外的一些场景,
并不只有代码当中会呈现出这种模式,历史随着时间也有,
考虑到编程语言本身就是用来模拟的真实世界,这应该也存在相似性,
而且随着编程语言描述世界的能力的增强,是否能成为哲学语言也未可知.
代码中的"依赖"
最常见的依赖关系处理的场景,可以说是模块的依赖管理,
比如 npm 模块的依赖管理,是每个开发人员的基础课,
比如模块 A 依赖 B 和 C,而 B 依赖 E 和 F,就是个树状的关系,
A 缺失了任何一个依赖,都不能完整地运行它的全部功能,
而且当 B C E F 已经存在时,A 的工作量相对来说就很小了,
此外依赖更新还有冒泡的关系,E 更新通常会冒泡到 A,
如果 E 更新时接口发生了改变,而 A 未跟进,更新就会失败.
另一个可以看到依赖关系的地方是函数调用,let f x y = z.
从函数式编程角度看,z 就对 f,x,y 三种产生了依赖,
由于函数 f 通常在代码加载时生成,那么 x 和 y 满足时,就得到 z.
也就是说如果是异步或者 lazy 的数据的 x 和 y,那么 z 会进入等待,
等到 x 和 y 都完成时,z 也就自动完成了. 这是编程语言里的做法.
现实中的"依赖"
现实当中的技术或者产品,大量的依赖也是存在的,特别是说到产品,
比如说 VR 的成熟,就依赖很多东西,比如计算量,比如网络带宽,比如人类生理的研究,
比如 AlphaGo 的成功,依赖 GPU 的强大性能,依赖大脑神经的研究,还有很多,
粗略地也可以看到,现成生活当中的依赖条件往往不那么清晰,
我们在事先评估某个技术是否成熟的时候,大部分人看不清依赖有多少,
就像上面的例子展示的,它的依赖不成熟时,整个东西就无法完整,技术也会打折扣.
通常我们仅仅以"条件不成熟"一句带过,其实也可以说成"依赖不满足".
另一个是在事情的依赖发生更新时出现的问题. 比如说大脑当中的一个成见.
成见难以推翻的一个原因是它总是有着自己的依据,很多很多的依据,
这些依据就作为了依赖,而依赖的完整也就支撑了成见持久地存在.
我们知道世界很大,世界会变,这些依据往往会有更多,会发生改变,
然而我们的记忆并不容易改变,即便改变了,原先的成见也不会响应式地更新,
这都是人类记忆的一个缺陷了. 随着人见多识广,变老,观念也会固化,
年轻初入世界往往是不靠谱的,他们不立足我们的很多依据,但其实也就这样.
人类世界的事情有着太多复杂性,不是简简单单写代码可以媲美的,
因为有着太多的因素,往往思考问题难以覆盖到所有的依赖,
然而,把整个世界的运行规则看做一个函数的话,它的参数也就是整个世界,
要得到正确的结果,就需要正确的参数,也就是整个世界,
我们都知道不可能,因为人脑是及其有限的,考虑的因素也是有限的,
也就意味着人类必然犯错误,就像机器学习存在准确率问题一样.
由于依赖性,一个问题往往会牵涉到大量因素,其实是很累的事情,
特别是时间顺序上,比如 B 依赖 A 的工作结果,那么任何 A 的细节都会影响 B,
比如 A 因为私人的事情影响到了提交结果给 B 的时间,就影响到 B,
那么 B 的每个行为就是要依赖 A 那个小事么,当然不是.
这个时候引入接口和协议,B 依赖一个协议,A 只要遵从协议完成即可,
比如 A 限定在某天完成,那么 B 就从之后第二天开始工作. 也就是进行了解耦.
换个角度看也是对依赖关系的一种 Mock 的做法吧.
其他可能性
用编程语言解释现实世界或许看着无聊,但可惜大家都在这样做,随着我们用编程语言描述越来越多的业务,可以看到它有着强大的表达能力,甚至在某些大型 3D 游戏当中编程语言可以把整个世界造出来,不得不钦佩这样的能力,人类简直成了上帝,想想真是后背发凉.但是至少验证整个世界可以用数据,状态,函数,逻辑这些概念表达了,那么可以想象,未来更多的编程的概念可以在真实世界当中找到影子. （编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
