数据结构+算法=程序

(1)

数据结构+算法=程序。

每个学计算机的人都听过这个公式。

这个公式是尼克劳斯沃斯在1976年出版《算法+数据结构:程序》一书中提出。尼克劳斯沃斯还是Pascal编程语言的发明人,而且他还在1973年出版《系统程序设计导论》一书中提出了“结构化程序设计”这一概念。尼克劳斯沃斯是瑞士人,在苏黎世工学院上完本科后又到加拿大莱维大学取得硕士学位,后又到美国加州伯克利大学取得博士学位,博士毕业后担任斯坦福大学计算机系教授。

(2)

可能是在中国,也可能是在中国企业应用软件业,这个公式得修订一下,应该是:

数据结构+业务逻辑=程序。

业务有多复杂,程序代码就有多复杂。程序就相当于现实业务的一个快照、电子翻版。现实业务变化了,程序就必须变化。所以中国定制化项目特别多,其实本质都是自己带球让球把自己给绊倒了。

我是一路从程序员-技术总监-CTO过来的。我过去做程序员时,我负责的那个系统算是核心系统,和很多其他系统有关联性,其他系统老需要更新我所属系统的数据表中的状态值,这样就导致了其他系统只要有业务逻辑变化,我的系统就必须要随之改代码,甚至我的系统会出现异常。


后来我觉得这样干不是个事,于是我就写了一个状态机,而且还把状态机的配置放在外面配置文件中。这样,遇到其他系统业务逻辑变化时,我就不需要改我的系统,我的系统也一直保证稳定不出异常了,而且只需要改一下配置文件即可,很灵活。

但是很不幸,我后来去做平台基础研发去了,接任维护的程序员打开我的代码一脸懵逼,现实业务他理解,但是他理解的现实业务,在我的代码中没有看到对应的程序逻辑,他在脑海里形不成这两者的映射关系,他没法下手修改代码。

我曾经甚至还想过用AOP模式和IOC模式来彻底解决问题,但是因为我转去做平台研发了所以我就没再动了。后来我想了想,绝大多数程序员都不知道啥叫AOP模式和IOC模式,我的代码倒是非常稳定了,但是他们也不会维护了。

我再说一个事,是去年发生的。我和一个下属过去讨论一个业务场景,我叨逼叨说了一大堆业务的介绍,我这个下属眨巴眨巴眼睛说:这不就是个偏导函数么?

对,在别人眼里那是业务逻辑,在他眼里就是偏导函数。

我们老提应用架构,其实应用架构重点包含两方面:一方面就是把业务抽象成模型,最好抽象到能用数学公式来推导、解释,这样就会保证严密完备、简单、稳定。另一方面就是设计好模块与模块、系统与系统之间的集成接口,让接口设计的稳定并可向下兼容。

(3)

从2015年以来,第三次人工智能热潮在中国兴起。

数据结构+算法=程序这个公式,又需要修订修订了,我提出的是:数据+模型=程序。

从数据结构升级到数据,从算法升级到模型。

数据结构和数据的分别,大家很好理解,相当于骨架和肉的关系。

而算法带有因果性,模型带有相关性。因果性和相关性这是两个完全不同的东西。

所以,从2018年以来,设计模型,越来越重要了。但啥叫模型,模型设计的常用方法有哪些,你知道吗?

(4)

从2018年Google提出Transformer和预训练模型以来,我感觉:数据结构+算法=程序这个公式又得改改,应该改成:预训练模型=程序。

也就是说:模型即程序。

大家看2019年Open AI Lab公布出来的GPT-3巨模型,你可以用它搞很多应用任务。

在人工智能时代,数据是隐私不能泄露,模型是核心也是要保密,但数据+模型被预训练后,就炼成了一个最终的巨模型,可能整个模型就是高达几十T的文件,你既看不到数据也看不到模型,你只能用它。而且由于部署这个巨模型、运行这个预训练巨模型,消耗的资源和算力太高,所以巨模型未来的商业模式就是公有云提供服务。Huggingface现在就在探索这条路。

所以以后的程序员在写算法呢,还是在写业务逻辑代码呢,还是在设计模型呢,还是在训练模型呢?你们说呢?

(5)

预训练模型这个套路现在还不好。因为海量数据一旦炼成知识,这个预训练模型就算版本化固定了。如果你还想加入新的知识,你还需要再预训练。

我理想中的套路应该是:海量数据随着业务的发生,通过万物互联IoT源源不断送进模型,这个模型持续不断地增量训练,利用各种学习模式(如对比学习、强化学习等等)持续不断地自我优化,这就成了活的模型和活的程序,这样就不用像现在中国的企业应用软件程序员,现实业务变就必须业务逻辑代码变。

数据结构+算法=程序_第1张图片

你可能感兴趣的:(算法,数据结构,人工智能,编程语言,java)