@thet
@wellsc
有一说一，C#和 net core 比起 Java 这种有历史包袱的语言内存占用是少了很多，但是比起 Go 这种直接编译出本地 AOT，压根就没有虚拟机拖累的语言，那就不够看了。net core 据说也在折腾编译成目标平台代码，不带虚拟机，就看啥时候能弄成了

这本质是两种思想的碰撞，JPA 的思维是 ORM，mybatis 则来自“sqlUtils”(sql 帮助工具)。

在关系数据库群雄争霸的那个时代，SQL 标准没有统一，在编程界的当时有一个迫切的需求：如果我半途要换关系数据库怎么办？不像现在这个 MySQL“称霸世界”(并没有)的时代，当时做到一半换数据库是真的常见的需求。而当时 SQL 作为一种 4GL 语言其实思想并没有广泛的被人接受，当时的业界还是面向对象的天下。于是就有人说：为什么不能用面向对象来映射关系数据库的表呢？这就是 ORM(Object Relational Mapping,对象关系映射)最初的思想来源。也是最主要的两个 ORM 库，Hibernate 和.Net Entity Framework 的指导思想。

时间飞速前进，新世纪后发生了两个非常主要的变化：

第 1 个变化是，关系数据库面对海量的互联网数据开始变的力不从心，为了解决海量数据的问题（当时大数据还没有像现在这么发达），不得不妥协，把单库拆分成多库，这么一拆之后，关系数据库之前以强约束，关联关系计算为卖点的特性，不再是优势(拆分之后的库无法使用这些特性，只能搞什么最终一致，Base 理论之类的聊以自慰)，这也是为啥 MySQL 这种在经典关系数据库理论看上去简直就是个残废的关系数据库大行其道的原因。同时，因为经典关系数据库的特性不再重要，关系数据库开始沦为数据仓库，选哪家的数据库就变的不再重要了，更换数据库变成了伪需求，不再存在，ORM 理论的重要来源：屏蔽各个关系数据库之间的不同点，以让用户更换数据库无忧，这一最初的重要需求，不再存在。


第 2 个变化是，进入新世纪后，SQL 作为一个 4GL 语言的价值终于被发现，大家纷纷表示这种“do not tell me how to do,tell me what you want(不要告诉我怎么干，告诉我你要什么)”的模式真是太香了；而且一众 NoSQL 的鼓吹者们高举大旗准备驱逐关系数据库，结果闹了很久后发现自己拿 SQL 居然毫无办法，只能捏着鼻子，纷纷又开始在自己的查询器上加上了 SQL 支持。传统关系数据库是没落了，但是 SQL 以及背后承载的关系运算的思维，在新时代反而是大行其道。复杂查询直接上 SQL 那感觉是真香，连新普的大数据从业者都自嘲自己说：后端是 CRUD Boy，我们就是 SQL Boy 。


总之，新世纪的竞争里，目前看是 SQL 赢了，ORM 的思维只比较适合无连表的 CRUD，对单表或多个单表执行 OLTP 业务，此时的 ORM 是比你写多个 insert，select 啥的方便的，但是一旦涉及到复杂的联表，group，having 查询，大家否纷纷直接上 SQL 更方便。

另外从业界的进化你也可以看得出来，纯正的 ORM，在 Hibernate 和.Net Entity Framework 之后几乎就没有再看到出名的了，JPA 则是从 Hibernate 发展来的，可以看做延续和强化，但本质不会变。但是各种"SQL 工具类"型的查询库，还在层出不穷的出，而且这些工具并非墨守成规，Ruby on Rails 开历史先河，吸收 ORM 对单表查询很友好这个优势，发展出了 Active Record 这种即可以从单表结构直接映射出对象，并可以在查询的时候以链式调用的方式注入查询条件；同时，都保留了能够方便自定义 SQL 的能力。其它 Sql 工具一看纷纷跟进，包括现在 Mybatis 的几个强化工具都是这个思路。

所以我觉得接下来一段比较长的时间，除非出现新的变革，占优势的应该还是各种更亲和 Sql，但是同时具备表映射对象能力的各种 SQL 帮助工具。

js 有啥难度？直接堆代码就行，发现不对再去搜特性就好。前端的天坑是 CSS 好吧，这玩意，真前端都没几个真的搞的很明白的

这分明是 bug

一点都不担心，早在人月神话时代，那时市面上一会就会冒出一款全新的语言或者“开发框架”，各个都宣称自己可以“降低成本”，“再也不用聘请昂贵的程序员了”。

所以，软件开发也最高的成本就是人力成本，资本想替代掉这昂贵的人力成本不是第一天的事情。用不着觉得不开心，想着降低成本是资本的本能。

现实的核心问题，不在于低代码无代码能否取代程序员。而在于本身的复杂度是来源于业务自身的，开发程序的难度确实是在下降，而且还会继续下降，2000 年的时候你搭个网站简直是黑科技，现在谁不会搭网站？但是 2000 年复杂的 ERP 业务，到现在仍然复杂。

程序开发本质是服务业，所以更多的时候，不要把眼光盯死在程序本身。程序说到底，只是个电脑工具，和 Office,photoshop，没有区别。盯紧业务更重要

云桌面这东西最大的问题是价格太贵，而且以目前的技术发展看，根本没有可能降下来。

多嘴问一句，你们都是从哪里翻到 gitbook 的，google 了一下没有找到途径

@myCupOfTea 行呗，老板这不已经发话了，既然老板都不怕死，你怕什么，照着他说的弄。反正手上随时准备后路，老板要死就让他死好了。

spring cloud 这玩意这不是银弹，它的很多基础组件其实也仅仅是 [开发出来了] 而已，netflix 的那套其实是有点东西的，可是 netflix 后来直接说我不更新了，2.0 闭源，其实微服务的基础组件是有研发难度的。也是比较有价值的东西，真大路货的话 netflix 也不会突然就说不更新了

同事不是朋友，不要拿对朋友的要求，要求同事。只要干活的时候别人愿意配合，不故意使绊，那同事就是合格的。

@gBurnX
还是那句话送给你：

认为公报私仇是无所谓的管理者，希望你把你的理论推广给你所有的下属知道，并且明言的告诉他们：我不在乎有人在我团队里公报私仇，谁被公报私仇那是活该，谁让它被人抓住机会了呢。呵呵

不再回复，你继续口嗨好了

@gBurnX
巧了，我还真没听说过，避免有人利用点名进行公开处刑的的是什么 [复古管理观点] 。你既然说了这是复古管理观点，还有你那所谓的现代管理，是从哪里看来的好了？我管理的团队最多的时候有近百人，请问您管理多少人的团队？


体制内一样要靠实力，体制外也不是纯靠实力，我的亲戚朋友里不仅有正厅而且有好几个。人家可没觉得体制内就是靠关系，体制外就是实力包打一切，我是不知道你是怎么自信的。


你现在改口了，加了限定词，“合法合规合理”，刚才你不是很牛的说有实力想干啥就干啥的吗？ [合法合规合理] 就不是限制了？

告诉你不能随便点名就是为了 [合理] ，你觉得公报私仇是好的，还说题主给了他机会，你居然不觉得公报私仇是有问题的，这还有啥好讨论的。你自己都没意识到自己是错的，还在那吹嘘“专业化的团队管理知识”。


世道没变，是你自己弄错了。认为公报私仇是无所谓的管理者，希望你把你的理论推广给你所有的下属知道，并且明言的告诉他们：我不在乎有人在我团队里公报私仇，谁被公报私仇那是活该，谁让它被人抓住机会了呢。嗯嗯

@gBurnX
你懂啥规矩啊，你不仅一点不懂规矩，还不懂一个正常管理的团队到底是怎么运作的。

点名这事不能随便，除非是危及系统的大型错误，事故；由集体裁决之后，才有资格在公开会议上点名，个人没有资格做点名这种事情，如果任由点名这事发展下去。那就是人人自危的世界，你理解不了这件事情，显然是你缺乏经验，根本没见过用心险恶之人是怎么利用对个体的公开处刑打击同僚以向上爬的。

都 2021 年了，还在谈体制内体制外，认为体制内就是靠人与关系，而体制外一律靠实力说话的 [净土] 。这种认知真的太浅薄了。大型组织，管你什么体制内体制外，一旦体积膨胀到一定程度，必须会出现官僚化和阶层，认为体制外就可以凭实力为所欲为，这真的是一种错误的认知，人是政治动物，有人存在的地方必有关系。不是说你能力强就能想干啥就干啥。

把同级做过的错误，作为范例在公司公开演说，让其他人以此为戒，这毫无问题。但是这绝不意味着，在批判这件事的时候，你有资格直接把做这件事的同事的名字爆出来。你爆出来，这就是公开处刑。而禁止个人随意的对它人公开处刑，正是为了防止有恶意之人利用这点打击同僚，毒化团队氛围；这是一种对所有人的保护，你理解不了，说明你根本就没见过，你连这件事本身就是一种错误都认知不到，自然不会觉得点名是问题。

不点名不意味着不处理问题，不意味着人人都是老好人。你连这都理解不了吗？你还问我带过多少人？

你先好好想想你自己说的“体制内就是靠人与关系，而体制外一律靠实力说话”到底对不对吧。2021 年了，对社会的认知能不能不要这么二极管？

@Kingfree rust 在解决 c++痛点的同时又加了一堆自己的痛点上去了。。。

@gBurnX
你懂不懂规矩？提问是提问，提问点名干嘛？说问题非要把人名说出来，这是当众处刑。就算是有资格这么做的上级，这么干也得非常谨慎才行。更别说只是个同级。同级有个毛资格点名，点名一律可以认为是借事踩人！

一个明明就是 code view 的小问题，说事就算了，居然敢点名，不安好心！你居然意识不到这里面问题严重性，还说别人缺乏稳定性和自信，你才应该再历练历练知道一些人心险恶。

我的团队里如果有这种人，发生第一次我会立刻进行私下谈话开导，如果下一次再次发生那我就要准备把人弄走了。当众处刑个人可是非常严肃的事情，必须是非常大的问题，形成组织决议时才能以组织的名义进行。任何个人行为的当众处刑，这个人不是蠢就是坏

python 在 web 领域从来就没占据主流过啊，就算没有 node 的年代，也是 PHP 和 Java 各领风骚，python 在 web 领域从来就是 [能做] 而已，优势，谈不上

spring 比较庞大，所以初期看上去很难下手，其实绝大部分人用 spring，最多就用到了自动装配依赖，连 aop 都很少用。你把 spring 是怎么扫描你的依赖，怎么装配依赖的这个流程搞懂，就基本上手了