@gowk 没有书可以推荐，因为绝大部分技术书籍基本不讲技术历史，其实我是个对技术历史脉络比技术本身还感兴趣的人，年轻时精力好，在那个博客发达的时代到处翻人家写的点滴记录，有了这么点积累而已。其实我也万分的想让别人给我推荐讲技术历史脉络的书籍，然而这类书真心罕见

@gowk

程序设计有一个范式（ paradigm ）问题。所谓范式，就是组织程序的基本思想，而这个基本思想，反映了程序设计者对程序的一个基本的哲学观，也就是说，他认为程序的本质是什么，他认为一个大的程序是由什么组成的。这和他对于现实世界的看法有关。显然，这样的看法不可能有很多种。编程作为一门行业，独立存在快 60 年了，但是所出现的范式不过三种——过程范式、函数范式、对象范式。其中函数范式与现实世界差距比较大——真的纯函数范式在目前的编程实践中其实很少有，绝大部分语言只是取了函数范式的一个子集，即可以把函数作为参数传递，不过这并不是函数范式的核心，在这里不多讨论，只谈一个历史趣闻，有兴趣的可以自行去进一步查资料：当年的大牛们认为，Haskell 是“美丽的，聪明的”设计，C 语言是“丑陋的，简陋的”设计，然而最后占据了世界主流的却是“丑陋的，简陋的”的设计。

而过程范式和对象范式可以视为对程序本质的两种根本不同的看法，而且能够分别在现实世界中找到相应的映射。

过程范式认为，程序是由一个又一个过程经过顺序、选择和循环的结构组合而成。反映在现实世界，过程范式体现了劳动分工之前“全能人”的工作特点——所有的事情都能干，所有的资源都是我的，只不过得具体的事情得一步步地来做。

对象范式则反映了劳动分工之后的团队协作的工作特点——每个人各有所长，各司其职，有各自的私有资源，工件和信息在人们之间彼此传递，最后完成工作。因此，对象范式也就形成了自己对程序的看法——程序是由一组对象组成，这些对象各有所能，通过消息传递实现协作。

对象范式与过程范式相比，有三个突出的优势，第一，由于实现了逻辑上的分工，降低了大规模程序的开发难度。第二，灵活性更好——若干对象在一起，可以灵活组合，可以以不同的方式协作，完成不同的任务，也可以灵活的替换和升级。第三，对象范式更加适应图形化、网络化、消息驱动的现代计算环境。

重复一遍对象范式的两个基本观念：

程序是由对象组成的；
对象之间互相发送消息，协作完成任务；

这就是对象范式的核心，并没有规定对象的标准，这里的对象只是一个抽象的概念，人为划定的，包含一定职责和功能的组件。对象之间互相“发消息”其实也只是一个抽象的概念，并没有规定“发消息”这一行为究竟该是什么样的，核心问题就在这里，这里埋下了一个大坑，为后来面向对象变成被扭曲成面向类编程留下了一个悬念。

历史没有假设，把 OOP 应用于编程语言实践并第一个“获得广泛成功”的语言是 C++，而上面说了，C++是基于 Simula 的思想，Simula 认为“发消息”是什么样的操作呢？向一个 Simula 对象中发送消息，就是调用这个对象的一个方法，或者称成员函数。那么你怎么知道能够在这个对象上调用这个成员函数呢？或者说，你怎么知道能够向这个对象发送某个消息呢？这就要求你必须确保这个对象具有合适的类型（方法），也就是说，你得先知道，哦这个对象是什么（类），才能向它发消息。而消息的实现方式被直接处理为成员函数调用，或虚函数调用。

而另外一边的 Smalltalk 在这一点上做了一个历史性的跨越，它实现了一个与目标对象无关的消息发送机制，不管那个对象是谁，也不管它是不是能正确的处理一个消息，作为发送消息的对象来说，可以毫无顾忌地抓住一个对象就发消息过去。接到消息的对象，要尝试理解这个消息，并最后调用自己的过程来处理消息。如果这个消息能被处理，那个对象自然会处理好，如果不能被处理，Smalltalk 系统会向消息的发送者回传一个 doesNotUnderstand 消息，予以通知。对象不用关心消息是如何传递给另一个对象的，传递过程被分离出来（而不是像 Simula 那样明确地被以成员函数调用的方式实现），可以是在内存中复制，也可以是进程间通讯。到了 Smalltalk-80 时，消息传递甚至可以跨越网络。所以各位，其实和消息队列类似的功能当年就已经存在了，消息队列 1 是为了解耦，2 是为了削峰错流，某种程度上消息队列不是实时的，然而 Smalltalk 的消息机制，某种程度上可以视为实时的。这也是它的先进性所在，我们希望解耦，但是我们不需要延迟。

很可惜，历史没有假设，Smalltalk 的直系继承者 Object-C 被 Steve Jobs 收入苹果公司，很长一段时间没有和公众见面。后来有一个也利用了该思想的专门为电信级通讯设计的语言 erlang，Actor 模式由它定义，其实就是那套消息机制，然而 erlang 是少见的纯函数式编程的语言，接受的人不多，也没流行开来。

后来就和大家知道的那样，因为 C++的流行，导致“类”这个概念变的无比重要，毕竟你要先知道对象的“类”，你才能确定，我能不能发消息给这个对象。于是类的概念变成了第一要素，OOP 至此被扭曲为 COP （ Class Oriented Programming，面向类程序设计）。

客观地说，“面向类的设计”并不是没有意义。来源于实践又高于实践的抽象和概念，往往能更有力地把握住现实世界的本质，比如 MVC 架构，就是这样的有力的抽象。但是这种抽象，应该是来源于长期最佳实践的总结和提高，而不是面对问题时主要的解决思路。过于强调这种抽象，无异于假定程序员各个都是哲学家，具有对现实世界准确而深刻的抽象能力，当然是不符合实际情况的。结果呢，刚学习面向对象没几天的程序员，对眼前鲜活的对象世界视而不见，一个个都煞有介事地去搞哲学冥想，企图越过现实世界，去抽象出其背后本质，当然败得很惨。

但是学术界一向高傲，传统上学术界一直都是理论定义的先驱，负有“指导众生”的义务，所以学术界仍然坚持这套基于类的 OOP 概念，但是工程界自从发现基于类的抽象其实对程序员的心智负担过高后，组合优于继承的思想就开始深入人心了。对象才是第一要素，对象并不依赖于类，对象的组合方式是彼此发消息，彼此发消息的方式也可以不依赖类，就算是传承自 C++的 Java 也搞出了接口这种方式——其实这种方式距离抛弃类就只有一步之遥了，我要知道对象有没有方法让我发消息，我检查接口定义就行了，我为啥需要类，Java 需要类来制造对象是历史惯性，不是必须。

历史让 C++走上了舞台，历史也终将让 COP 重新回到 OOP 的本来面目

@yippees C#和 Java 一样的，不能多继承，多继承不是什么好设计

我来谈谈历史好了
大多数人所谓的 OOP，其实都是说的“继承封装多态”这一套，但是，最早的 OOP,叫对象范式，对象范式的两个基本观念：
*.程序是由对象组成的；
*.对象之间互相发送消息，协作完成任务
请问，有“继承封装多态”的定义吗？没有！！！这两个观念与后来我们熟知的面向对象三要素“封装、继承、多态”根本不在一个层面上。倒是与再后来的“组件、接口”神合。

世界上第一个面向对象语言是 Simula-67，第二个面向对象语言是 Smalltalk-71。Smalltalk 受到了 Simula-67 的启发，基本出发点相同，但也有重大的不同。先说相同之处，Simula 和 Smalltalk 都秉承上述对象范式的两个基本观念，为了方便对象的构造，也都引入了类、继承等概念。也就是说，类、继承这些机制是为了实现对象范式原则而构造出来的第二位的、工具性的机制。而 Simula 和 Smalltalk 最重大的不同，就是 Simula 用方法调用的方式向对象发送消息，而 Smalltalk 构造了更灵活和更纯粹的消息发送机制。

到了 1980 年代，C++出现了。Bjarne Stroustrup 在博士期间深入研究过 Simula，非常欣赏其思想，于是就在 C 语言语法的基础之上，几乎把 Simula 的思想照搬过来，形成了最初的 C++。C++问世以之初，主要用于解决规模稍大的传统类型的编程问题，迅速取得了巨大的成功，也证明了对象范式本身所具有的威力。

大约在同期，Brad Cox 根据 Smalltalk 的思想设计了 Objective-C，可是由于其语法怪异，没有流行起来。只有 Steve Jobs 这种具有禅宗美学鉴赏力的世外高人，把它奉为瑰宝，与 1988 年连锅把 Objective-C 的团队和产品一口气买了下来

形势使然，C++的广泛使用，大大的影响了学术界，学术界疯狂的热爱继承这套体系，希望利用继承来描述世间的真实类别系统，然而现实世界复杂多了，蝙蝠是鸟也是兽，水上飞机能飞也能游，它们该如何归类呢。这套继承体制遇到真实世界的时候破绽很大，但是学界已经刹不住车了，甚至搞出了多重继承。这股风潮影响了后续的 Java （虽然它没“继承”那套翔一样的多继承机制，引入了接口这个其实更接近 OOP 本质的东西），扭曲了人们对面向对象的理解。既然必须要先知道对象的类型，才能向对象发消息，那么“类”这个概念就特别重要了，而对象只不过是类这个模子里造出来的东西，反而不重要。渐渐的，“面向对象编程”变成了“面向类编程”，“面向类编程”变成了“构造类继承树”。放在眼前的鲜活的对象活动不重要了，反而是其背后的静态类型系统成为关键。“封装、继承”这些第二等的特性，喧宾夺主，俨然成了面向对象的要素。每个程序员似乎都要先成为领域专家，然后成为领域分类学专家，然后构造一个完整的继承树，然后才能 new 出对象，让程序跑起来。

到了 1990 年代中期，问题已经十分明显。UML 中有一个对象活动图，其描述的就是运行时对象之间相互传递消息的模型。1994 年 Robert C. Martin 在《 Object-Oriented C++ Design Using Booch Method 》中，曾建议面向对象设计从对象活动图入手，而不是从类图入手。而 1995 年出版的经典作品《 Design Patterns 》中，建议优先考虑组合而不是继承，这也是尽人皆知的事情。这些迹象表明，在那个时候，面向对象社区里的思想领袖们，已经意识到“面向类的设计”并不好用。只可惜他们的革命精神还不够，delphi 之父在创建.net 的时候，曾经不想要继承，在微软内部引起了很大的争议，最后是向市场低头，加上了继承。

2000 年后，工程界明确的提出：“组合比继承重要，而且更灵活”，Go 语言也许是第一个明确的对这种思路进行回应的语言，你认为 Go 不够 OOP，那是因为你观点里的 OOP 其实是被扭曲过的，时至今日，学术界仍然很关注继承，但是工程界的思路已经变了，OOP 本质是为了职责分离而设计的范式，核心的东西是对象，不一定需要类，OOP 也不是继承封装多态的代名词

你既然敢说自己能“精”了，那，有本事自己撸一个框架吗？如果你都能自己撸一个框架了，那我建议你跳出前端，去看看别的世界

人太多了，真的

@EscYezi 我也一样，只有在静态语言写过一段时间回见，跳到动态语言后，被动态语言的优点和缺陷都洗礼过，才知道 Java （静态语言有类型检查）的好。我现在基本不考虑任何没有类型检查的语言写项目

没办法，现在满坑满谷，各种培训出身的，一线城市退潮筛下来的，不愁挑，自然资本就高傲起来了

@cs8814336 别吹 Mongdb 的事务。那和 ACID 这个级别差的远了

@YardWill 又是这种鄙视“你水平比我烂所以写的代码烂，和技术 XXX 无关”的论调，我说，睁开眼睛看看其他领域好不好。技术是为现实服务的，不是为鄙视链服务的，如果你真的是一个有足够经验的程序员，首先应该学会的就是接受这个世界的技术人员水平是参差不齐的这个事实，然后想办法在这个事实的基础上，尽可能让一群水平不一的人，也能做出不错的产品，为现实服务。而不是一副“这技术很屌用不好是你们水平不行不会”。
前端之所以出现了大量的工具和框架，本质其实就是为了解决工程人员水平不一造成产品质量相差太大的问题，从这个出发点上说，前端目前的环境比 IE6 时代好到不知道哪里去了。但是从现实来讲，目前前端的技术发展存在很大的问题，核心问题就是解决程序员的心智负担没有减轻，反而加重了。这其实背离了本来目的。目前前端界还在不断的做加法。而现在是需要出现王者来做减法的时代了

@peneazy 现有前端那堆框架最大的问题是，解决了旧的痛点，却引入了新的问题，开发者其实并没有从繁重的重复体力劳动中得到解放。

@1423 https 不管域名解析，域名解析的 dns 协议可是明码的，怎么可能拿不到你的 url

另外各位，79 楼的是目前这个病毒的最权威描述，这个木马 hack 了大部分的系统命令，你直接用系统命令是看不到它的文件的，确实必须用 busybox

@lvxiang119 请问你是如何找到这张“图片”的？

@passerbytiny Redis 开了公网访问，但是设置了 32 位强密码。难道密码外泄了？但是 redis 到底是如何造成木马进入的？原理是什么？有没有方法避免，mysql 密码让人知道了也就是脱裤，这能上传木马破坏威力太大了

@zou2699 redis 有这样的漏洞？麻烦详细说一下

兄弟，我和你症状一模一样啊
https://www.v2ex.com/t/537457

@cpdyj0 我想实在没办法也只能重装了，我的系统设置的是强密码，防火墙一直开着，ssh 改了端口，没有运行过脚本语言，就跑着 java，mysql，redis，就这样还能被黑进来。头一次遇到

@casillasyi 极客的想法罢了，技术要服务于现实，你再先进，现实不接受又如何？不过就是孤芳自赏罢了，就像我前面说的，“设计良好”的 Haskwell 败给了“愚笨”的 C。说到底，生产力工具是要拿来用的，又不是光发论文，理论先进就行了