"算法+数据结构=程序"过时了吗？

liuiang

晕，看了一集喜洋洋回来，居然被骂了。这是皇帝不急太监急啊。你是不是还要骂弱智都看喜洋洋啊。都什么人啊~~~~

liuiang

回复 30# pmerofc


    没有论文讨论这个倒是。算法依旧重要，数据结构也一样，但目前各种针对各种领域和问题所开发的语言，

使得程序员已经不再将精力更多的投入到算法和数据结构，而算法和数据结构已经被封装成各种类库或模板。

事实上算法跟数据结构本身跟过程语言没有任何关系，即使面向对象的语言仍然需要算法和数据结构，

但算法+数据结构=程序则仍然不能摆脱过程到解决具体问题的映射。

正是因为人们已经意识到单纯的算法+数据结构不能快速解决软件工程中的问题，所以才开始引入面向对象等等后来的各种特性的语言。

时间看来

Goethe的著名格言是：“建筑是静止的音乐”；Jon Bentley“数据结构是静止的算法。”

我还在慢慢体会~

heavent2009

个人感觉重点在于对"程序"的理解
程序 != 软件
程序是一次性的,只考虑写出一个业务的逻辑.
软件是动态的,除了写出一个业务的逻辑之外,还要考虑很多,比如开发效率;后续的扩展和维护.这些都牵扯到设计模式,而且,这些模式最后的落脚点还是程序.

captivated

程序 = 数据结构 + 算法 是Dijkstra大师的公式.
至今, 我依旧认为 Dijkstra 大师从来没有错过。


写了几个快餐程序, 在层层抽象之上工作, 然后说程序不是数据结构 + 算法了.
OO了一下, 程序不是数据结构 + 算法了.
函数式了一下, 说程序不是数据结构 + 算法了.
只写业务, 不关注底下的数据存储, 程序不是数据结构 + 算法了.

...
那是因为这些程序不太要求自己写基础数据结构, 那是因为基础数据结构和容器, 和算法, 都被人抽象成工具来用了,
随手用了几个工具, 程序搭出来了, 嗯, 这程序不是数据结构加算法了, 它是拿几个模块搭起来的, 主要的智慧体现在怎么搭模块, 于是程序 = (数据结构 + 算法，现在这玩意就是积木了) + 搭积木的“智慧”了。

这点搭积木的“智慧”，好意思跟人家 Dijkstra比么？人家写编译器，人家发明最短路径算法，人家得图灵碗，这点搭积木的智慧，好意思去跟人家比么？ 人家 Dijkstra真要搭积木，怕是比你那点搭积木的技巧高多了，好意思跟人家比么？

何况，搭积木就不考虑数据结构和算法了？容器不用选了？算法不用选了？

如果程序稍微复杂，基础容器不能用了，还得自己实现核心数据结构不是？还得自己设计核心算法不是？
那这个程序仍然是围绕这个核心数据结构和核心算法来运转的不是？

分布式计算了不是？ Map and reduce是框架，而不是数据结构 + 算法？确定么？其核心不是数据结构 + 算法？

写shell脚本了是不？ 胶水粘几个程序就完成功能了是不？
用什么来粘东西的？ 流啊。
流不是抽象出来的容器？ 如何粘东西不是算法？

大师为什么是大师，是因为大师无论在哪一个时代，他的洞见都足以使他成为大师。
假使大师和大家仍在同一个时代，相信我，成为大师的那个人，仍然是大师，而不是你。

Dijkstra 的公式没有错。

captivated

动态数组可以抽象成容器vector,
链表可以抽象成容器list,
队列可以抽象成容器queue,
堆可以抽象成容器priority queue,
栈可以抽象成容器stack
不相交集可以抽象成容器map, set

见过哪种语言，哪种基础设施把图抽象出来过？

为了解决特定目的的问题，需要一个图抽象，好的，这个基础抽象先写出来。
然后在这个基础抽象上再搭东西。
然后东西实际围绕这个基础抽象运转。

如果用了某个基础容器list, 那么存放到这个容器里面的东西，算法，实际上在围绕这个list容器运转。

推而广之，别的东西是一样的。

captivated

而且 Dijkstra从来没说过程序就完全等于数据结构加算法。

人家的意思是，程序的灵魂，是数据结构加算法。