轻易破防的人，就不要点进这个贴了。blocked

@wingkwanli888 唉，呵呵。

配置不是云端同步的吗

dde 使用的 kde plasma-framework ，，去那研究下

否则。为啥面向接口和 dp 不在基础的 oop 层面就完成。因为 oop 不直接包含对抽象代码的支持。它只能靠 oo idioms ，oo 习惯用法，这些约定的东西才能继续。

基于数据抽象的工作。只能是无底洞。

oo 并不是大型复用的绝佳良方。只要代码本身没被抽象掉，企图用抽象数据的方式不断叠加，来代替一切编程动作和面向所有人。只能是自欺欺人，说到底，它只完成了数据层面的工作。而且这个抽象数据的方式也越来越复杂。

而良好简单的代码，除了数据，才是所有人用这语言第一时间要接确到的。

好多人在一件事的东西，学不会就事论事，扯一大堆。还整一堆反问总结以增加气势。
就是不会抓住中心问题。看得着急。

更别说 oop 后面的那些事了，为了解决 oop 的不足，不断继续 oop ，最后发现 oop 了一大堆要学的东西。

相信任何人都承认，用 oo ，
动不动要翻文档查一下，啥东西都藏在很深的层次下。
数据还分模板，动手就要 new 一大通。代码还要刻意多态
这是一眼看上去多么痛苦的事。

@546L5LiK6ZOt 本来不想再继续说了。但有些人受 oo 荼毒至深。

工程化的极致就是 uml 建模吗，这不正是 oo 导致的恶果和习惯思维吗？
把代码和数据当成一团，为其分层级和建立图联接。正是 oo evil 的开始。

库的设计者：
可以使用纯函语言，可以作为元语言，在这上面建立 class language ，可以 src to src 转译到纯函语言。避免直接在 class language 和 oop 层次建立一切。
但用户编程级：
必须严格控制到止仅作为数据抽象。不要现代 oop 三重机制后面的东西。
这样才可以避免巨大的复用结构作为代码，带来的巨大的成本。包括 uml 。

@libook 用函数式作为元可以写出上层 class 和 oo 的语言，如 scheme 。用对象式作为元能写出上层函数式语言，如 ruby
现在的语言都是混合语言（实际上这里至少存在过程式，oo ，函数，混合）。

@tyzandhr 现在的语言实现有太多范式，比如 pipeline based,trigger based,data flow,组件式，为啥除了 oo 就是 fp ？

现在的语言，运行时实现中除了 object based 就是 function based 这倒是真的。
语言层可以有很多具体范式。

@TWorldIsNButThis 冯氏语言代码结构中的数据是都 mutable 的，带来并发问题。现在的语言基本逃不出这个范畴，只有纯粹函数语言不同

@wangpugod2003 oo 绝不应该是对某种需求一比一的建模。没有哪种范式应该这么做。

最初的 oo 类似于 smalltalk 用于 gui 这样的场景和语言组合
如果 oo 仅用于抽象数据而不是代码结构，那么足够。
可是 oo 最后终于变成一种范式，W 物都 oo ，
面向对象必然会导致数据抽象的不断堆叠，形成数据的巨集，最后接口是一个个数据“层次子世界”背后透出的东西
容易让人数据接口和代码接口不分
巨大的抽象数据。带来的问题不大
巨大的抽象代码结构。光是这条设计，带来的问题就足够大

从此，
设计者，复用者，初学者，调试者，都要从分析那坨树形的层次开始。
不复以前命令行中像修改命令式代码那样改动几个字，一行下去就能看到变化的快感了

@ligiggy oo 毒害了以 c ，cpp 为教科书成长起来的一代专业和非专业程序员。后来的语言都是简化或参照它们。oo 它在简化问题的时候，制造了更多复杂的东西。，它的被使用方式与设计方式是割裂的，中间损耗太大，放在谁身上都是。
**对设计者是个挑战。甚至有人为了抽象而抽象，或过度抽象**
**对复用者也是个挑战，加大了使用门槛**
**对初学者更是致命的**

@kop1989smurf oo 绝对不是，oo 是一种滥用，oo 应该到面向 adt ，面向 class 就够了。然而，它却走向了“W 物 OO”的不归路

@tool2d 打包时转译到 js ，像 cf workers 一样，它只支持 js 然而转译支持语言有好几种

@deepdark blocked