首先主管是背锅的，你不能因为要坚持你的理念，就把责任扔给别人，坚持理念者要付出应该的代价。其次，你有离职的自由，强烈建议你换个地方，自己当主管

读书读傻了，遇到当面贬低的面试官不走人还打算干什么？

我一向有个观点，程序员应该精通的是计算机科学本身，为啥要去精通语言？语言就三种范式，还能变出什么花来？

@shayuvpn0001 F35 用 C++不是挖坑，是因为 F22 用的 Ada 语言已经没啥人学了，找不到程序员，没办法，其实美国军方一直看不起 C/C++，嫌弃它们内存不安全

@Nilyyy 没有，我最后研究来研究去，得出了结论是“富文本编辑器”其实是个超级难的东西。参见知乎：
有哪些产品经理认为很简单，实则开发很难的技术
https://www.zhihu.com/question/38825761
也就是说本身你想把 word 里的布局格式完美的搬到浏览器里就极其的困难，直接以位图的形式搬过去实际是最简单的处理方式。浏览器显示公式的方案有那么几个，但是目前没有一个是完美的

楼主你平时是多怂，老板居然敢说用鞭子。说句难听的，这是暴力人身威胁，怎么会跟这样的老板混

@topmati 你这个同学很牛逼只能说明他个人很牛逼，不能推而广之的说其他人都这样，更不能说什么本科生硕士一点关系都没有，能读那么高本身就是能力的一种，你的同学只能算个人意外失去了高等教育的机会。你推而广之的说大部分人都这样才是最大的不公平

计算机专业出来的还纠结语言？

谈性价比，那就是要谈回报了，python，没别的，一个语言的回报取决于它的生态圈，不取决于它的语法和性能，比生态圈，python 的生态圈，我觉得可以在脚本语言称霸了

@shayang888 有，多的是，你们见少了，中国不光只有北上广，大把二三线城市还是落后的

@passerbytiny
你已经把“民科”的帽子扣在我头上了，你已经立于不败之地了，呵呵，你高兴就好

@zwpaper 1995 年出版的经典作品《 Design Patterns 》中，建议优先考虑组合而不是继承

@passerbytiny 我没有一棍子打死类和继承，我只是强调类和继承不是 OOP 必须的而已。另外，基于哲学的抽象领域，类有很高的价值，这也是为啥类和继承这套体系在学术界仍然相当有地位的原因，但是绝大部分程序员，只是凡人，程序的本来目的，其实也是为了让大部分凡人能够利用计算机编程这一工具而已。曲太高，和就寡。我里面提到设计的更好的 Haskell 并没有被广而接受，而被设计的并不优秀的 C 语言成了历史的选择，就是例子

@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 也不是继承封装多态的代名词

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