| Microsoft Azure DataFactory/DataPipelines Architecture | 8 |Warehouse/Workshop Model | 9 |
|
12 | |
13 |
17 | 
18 | |
19 |
20 | 
21 | |
22 |
35 |
36 | - 2025-03-26, 懂王第二任期一开始, 就努力学习践行我的《成圣法》上的各种方法,
37 | 玩得很开心, 很上头啊! 自封"史上最棒总统"称号后，再上宏伟叙事、气势磅礴、排比铺层的公文法，
38 | 还招了个华人来打理，以确保味道纯正！从一个胜利走向另一个更大的胜利，从伟大走向更伟大，
39 | greater than greater, bigger than bigger! 伟大、光明、正确，文德武成，泽被苍生，千秋万载，一统世界！
40 | 不过要小心，懂王学习《成圣法》进入疯魔期或心太急走火入魔，后果难以预料！
41 |
42 | 
43 |
44 | - 2025-03-29, 俄罗斯数字发展部和对美关系相关部门学习我的理论
45 |
46 | 今天, 我发现俄罗斯联邦数字发展、通信和大众传媒部
47 | （简称“俄罗斯数字发展部”， d-russia.ru）访问了我的理论的github博客仓库。
48 |
49 | 前几天，大约在我发布特朗普和马斯克学习我的成圣法之后，
50 | 我就发现有来自俄罗斯搜索网站的翻译服务translate.yandex.com的访问，
51 | 我大约推测是“俄罗斯对美关系相关部门”的访问，因为想要搞好对美关系，
52 | 首要的问题就是了解美国总统的想法，因此来访问我的成圣法。
53 |
54 | 我的github博客讲述了我的IT理论和成圣法，IT理论有英语版，
55 | IT人员更倾向用Google和Bing搜索，英语也都很好，俄罗斯是欧洲国家语系，
56 | 英语更不是问题，不会使用俄罗斯搜索网站的翻译服务translate.yandex.com。
57 |
58 | 我的成圣法只有中文版，结合我最近发布的内容，推测访问者是俄罗斯对美关系相关部门，
59 | 但俄罗斯搜索网站的翻译服务translate.yandex.com用户很多，这不能成为证据。
60 |
61 | 过了几天，就来了“俄罗斯数字发展部”，这就说明前一个访问者来头不小，
62 | 可以和“俄罗斯数字发展部”交流推荐技术了，结合访问的内容，
63 | 不难推测他是来自“俄罗斯对美关系相关部门”。这种部门眼光还是有的，
64 | 顺便看到我的IT理论这么牛逼，就向“俄罗斯数字发展部”推荐了我的理论。
65 |
66 | 我的《成圣法》懂王看了, 俄罗斯数字发展部和对美关系相关部门看了,
67 | 普京十有八九也看了, 忽然感觉好象少了什么, 他看过了吗?
68 |
69 | 
70 |
71 | - 2025-04-01, 特朗普学成圣法，以他的权利，这确实是最快的不朽途径，但是否成圣就不一定了。
72 | 方法总比困难多，山体不够用，在山顶建个铜像石像什么的很容易，
73 | 如果技术够的话，我怀疑他都想把月亮雕成他的大头像，让全世界仰望。
74 | 但如果没有相当的成就，最终也不会被真正认可，很可能被后任或民众拆除。
75 |
76 | 
77 |
78 |
--------------------------------------------------------------------------------
/doc/best_practice_of_clojure.md:
--------------------------------------------------------------------------------
1 | # The Best Practice of Clojure
2 | # Clojure最佳实践
3 |
4 | ---- from the largest personal Clojure project (Lin Pengcheng Financial Analyser )
5 |
6 | Copyright © 2018 Lin Pengcheng. All rights reserved.
7 |
8 | 版权所有 © 2018 林鹏程， 保留所有权利。
9 |
10 | - IDE: Notepad++ (ClojureBoxNpp)
11 | - Version Control: 7z.exe
12 | - Programming ideas (PurefunctionPipelineDataflow)simulate the following list:
13 | - Imaginative programming： Everything is an algorithm, at your fingertips.
14 | - The most valuable chapter of "Code Complete" : Chapter 2 Metaphors for a Richer Understanding of Software Development
15 | - Business management thinking
16 | - Pipeline technology for large industrial production
17 | - Business process reengineering
18 | - Enterprise organization, system, process design thinking
19 | - Accounting
20 | - Integrated circuit diagram
21 | - Urban water network
22 | - Boeing aircraft pulse production line technology
23 | - Confluence technology of rivers from the source to the sea
24 | - Data-centric, dataflow, designing a data model that is simple and fluent in manipulation.
25 | The line between the two points is the shortest, and the data is directly manipulated
26 | from the initial state to the final state.
27 | - Pure Clojure.
28 | - Don't use OO, FP, AOP. They are overly complex hand-workshop-level technologies.
29 | - Don't write middleware, macros, loop. They are hard to read, difficult to debug and observe.
30 | - repl drive development.
31 | - Try to design a pure function (pipe function) of a single hash-map parameter.
32 | - Minimize front-end code.
33 | - Side effects can only appear at the end of the pipe.
34 | - Try to use thread macros.
35 | - Code linearization, schematicization, simplification. What You See Is What You Get.
36 | - Use namespaces to achieve good code structure.
37 | - Normalize data.
38 | - Data verification only appears at the beginning of the pipeline.
39 | - Use the clojure.core API to manipulate data, enhance data model design capabilities.
40 | Don't use like specter lib etc.
41 | - Use and design "simple DSL", like hiccup, honeysql etc. DSL usage is code conversion,
42 | Using data style representation is better than using function style representation.
43 | A series of pipeline functions are concatenated to form a compiler
44 | for converting DSL data into target code and then evaluating it.
45 | - The best abstraction is: data and logic are strictly separated,
46 | data-flow is current-flow, function is chip, thread macro (->>, -> etc.) is a wire,
47 | and the entire system is an integrated circuit that is energized.
48 |
49 |
--------------------------------------------------------------------------------
/doc/unification_ICD_dataflow.md:
--------------------------------------------------------------------------------
1 | # 国际疾病分类(ICD)编码、主诊选择、DRGs费用结算、医疗服务、医学知识大统一 ---- 纯函数管道数据流和仓库/车间模型大统一系列
2 |
3 | 版权所有 © 2020 林鹏程， 保留所有权利。
4 |
5 | 医保现在逐步在全国推广应用DRGs费用结算, ICD编码和主诊选择的正确性是正确进行DRGs费用结算的两大基础工作.
6 |
7 | 我在2019.09.04在github博客上发表了的这一文章: ["基于数学证明与价值抽象的现代化科学ICD编码, 实现ICD编码、主诊选择、DRGs费用结算、医疗服务、医学知识大统一"](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Tao_ICD.md)
8 |
9 | 鉴于这一方法的基于数学证明的科学性和可靠性, 基于价值抽象可以正确地与DRGs医疗费用结算对接,
10 | 同时也可以避免当前存在众多争议的方法，我认为医保未来一定会全面采用我的方法.
11 |
12 | 名不正则言不顺，言不顺则事不成。拥有科学完善的理论依据，掌握名正言顺的大义，是顺利完成工作的重要保证。
13 |
14 | ## 0. 仓库/车间模型
15 |
16 | - 标准产品: 价值的抽象和一般等价物:"货币"
17 |
18 | - 仓库
19 | - ICD10 卷一
20 | - ICD10 国家临床版
21 | - DRGs 费用结算规则和价目表
22 |
23 | - 车间
24 | - 临床科室医疗服务和病历书写
25 | - 病案室ICD编码和主诊选择
26 | - 财务部门与医保结算
27 |
28 | ## 1. 我的基于价值抽象的单一主诊选择原则 vs 当前实行的多主诊选择原则
29 |
30 | ### 1.1. 当前实行的多主诊选择原则
31 |
32 | - 消耗医疗资源最多
33 | - 对患者健康危害最大
34 | - 住院时间最长
35 |
36 | 在实际工作中, 还存在
37 |
38 | - 病因统计的按病因选择主诊,
39 | - 死因统计的按死亡原因选择主诊的原因.
40 | - 按主手术对应选择主诊.
41 |
42 | 缺点
43 |
44 | - 这种方法看似兼容并蓄, 无所不包, 其实是在和稀泥,
45 | - 主诊选择口径不一致, 在实际工作中引起最多争议, 每个人都可以按自己的理解选择其中的一条原则.
46 | - 除"消耗医疗资源最多"原则外的其他原则与医疗费用相关性弱, 不适合DRGs结算.
47 |
48 | ### 1.2. 我的基于价值抽象的单一主诊选择原则: "以货币度量的消耗医疗资源最多"
49 |
50 | #### 1.2.1. DRGs下ICD编码的二重性
51 |
52 | - 疾病分类
53 | - 经济核算
54 |
55 | #### 1.2.2. DRGs做了一件好事
56 |
57 | 它通过对每个ICD编码确定一个价格，用货币统一了疾病的度量，确定了主诊的判断标准。
58 |
59 | 货币是一切商品价值的抽象， 虽然货币不是最好的度量方法，但一定是争议最少的方法。
60 |
61 | #### 1.2.3. DRGs本质上是把医院当服务业
62 |
63 | ICD10是服务项目的编号, 按件计价.
64 |
65 | 按实际提供的主要服务项目作为主诊， 做为计价基础，而不是病情的轻重或其他.
66 |
67 | #### 1.2.4. 在DRGs下，病案新增的重要功能
68 |
69 | ```
70 |
71 | 病案首页------帐单
72 | 病案其他------原始凭证及合理性解释
73 | 临床科室------业务部门
74 | 病案室------会计部门
75 | ICD编码------做帐(会计分录)
76 |
77 | ```
78 |
79 | #### 1.2.5. 优点
80 |
81 | - 以货币计量, 与医疗费用直接相关, 适合DRGs结算.
82 | - 单一标准, 在工作中最少争议
83 |
84 | ## 2. 我的基于数学证明的编码方法 vs WHO的卷3查找编码方法
85 |
86 | ### 2.1. 基于数学证明的方法的优点
87 |
88 | - 科学、严谨的逻辑推理证明过程。
89 | - 利于教学。
90 | - 工作过程可靠、正确。
91 | - 最小化争议的发生。
92 |
93 | ### 2.2. 基于卷3查找编码方法的缺点：
94 |
95 | - 使用者不知其然，也不知其所以然，业内到处充满了疑惑和争议，越学越困惑。
96 |
97 | - 工作方法基本靠蒙，主导词选择靠蒙，结果正确性也靠蒙。 特别是手术编码查找，由于主导词交叉索引少，靠蒙的缺点更是明显， 为了查找一个手术编码，瞎蒙主导词不得而敲破脑袋。
98 |
99 | - 而当今医学发展日新月异，设备越来越先进精密，疾病诊断名称越来越精细， 越来越多，卷3已完全不能满足现代医学技术和DRGs结算等发展的需要。
100 |
101 | - 结合ICD11的条目增加很多，如果要满足当前需求， 卷1可能需要2本书，卷2需要1本书，由于交叉索引带来的几何倍数增长， 卷3可能需要5本书，手术卷1需要1本，卷2需要2本书，再加上教科书1本， 病案室工作人员工作、考试需要带足12本大型工具书， 非常壮观，可以申请职业考试的吉尼斯世界记录了。
102 |
103 | ### 2.3. 小结
104 |
105 | 基于数学证明的方法把ICD从原始的靠经验瞎蒙的阶段提升到科学论证的阶段, 是ICD编码必然的发展方向， 基于卷3查找编码的方法是不可持续、不科学的， 不能满足医学、管理、DRGs等发展的需要。
106 |
107 | 详细内容和案例分析见主站: https://github.com/linpengcheng/icd10faq
108 |
--------------------------------------------------------------------------------
/doc/Flutter_is_outdated.md:
--------------------------------------------------------------------------------
1 | # Google Flutter is a similar technology I created and eliminated
2 | # Google Flutter是一种我曾经原创并已淘汰的类似技术
3 |
4 | Copyright © 2020.02 Lin Pengcheng. All rights reserved.
5 |
6 | 版权所有 © 2020.02 林鹏程， 保留所有权利。
7 |
8 | Google Flutter 是安卓（andriod）手机新一代的界面框架，并开始延伸到PC桌面端和Web端.
9 | Flutter组件采用现代响应式框架构建，这是从React中获得的灵感，中心思想是用组件(widget)构建你的UI。
10 | [参考:百度百科: Flutter](https://baike.baidu.com/item/Flutter/22498985)
11 |
12 | 最近看到"有个梨UGlee"的微博说, Flutter的方法是UI=f(state),
13 | 我发现居然是我五六年前开发[林鹏程财务分析软件v0.10.2015.6.1](https://github.com/linpengcheng/fa)时,
14 | 使用clojure-clr写基于.net winform界面时使用的方法.
15 |
16 | Flutter的第一个版本被称为“Sky”，运行在Android操作系统上。它是在2015年5月3日Dart开发者峰会上亮相的,
17 | 但它只是一个概念演示版,根本无法使用.直到2018年2月27日才在2018世界移动大会发布Beta1版.
18 | 1.0版本于2018年12月5日(北京时间)发布.
19 |
20 | [林鹏程财务分析软件v0.10.2015.6.1](https://github.com/linpengcheng/fa)是2015年6月1日发布,
21 | 但这是一个完整的产品, 而不仅仅是UI概念演示版, 另外, 因为我是个人业余开发, 开发速度很慢,
22 | 整个项目用了4年多, 实际上我的UI实现应该早了几年, 在2013年左右,有在QQ群"Clojure"里讲过我的技术实现.
23 | 可以另外参见我在2018年4月19日的博文[C#愚蠢到我不能理解，兼论UI构造方法。](./c%23stupid.md)
24 |
25 | 因为同时期的“Sky”资料找不到, 就和最新的Flutter比较一下差异:
26 |
27 | 1. 我用clojure-clr动态构造.net winform界面时, 经常使用多线程或异步来构造界面, 比Flutter简单方便强大多了，数据驱动，也更贴近原生。
28 | 基于一个包括全部界面组件状态atom数据，所有的界面组件围着atom, 交互运行。 很久以后，我看到"Clojure编程乐趣"这本书上有Alan Perlis
29 | 的一句话。 It’s better to have 100 functions operate on one data structure than 10 functions on 10 data structures.
30 | 这与我的解决方案有异曲同工的思想。我的思想是：所有的组件围着一个atom状态交互，比各个组件管理自己的状态好。 大家是不是觉得很相似。
31 | 注：Alan Perlis是首位图灵奖得主、Algol语言(C/C++/Pascal等语言的鼻祖)作者。
32 |
33 | 2. Flutter的UI表达方式更倾向代码化, 更类似OO写法, 代码嵌套比较深, UI与逻辑混杂在一起, 信息密度太低, 阅读代码时, 难快速了解逻辑,
34 | 快速修改代码. 我的UI表达方式更倾向纯数据表达并组合, 直接当函数参数调用,UI和逻辑完全分离, 信息密度高, 逻辑简洁清楚独立,
35 | 阅读和维护轻松.
36 |
37 | 3. Google Flutter的方法UI=f(app-state)和我的UI=f(winform-state)还是有差别的, 我认为app-state范围过大而不必要, 且不能实现UI和逻辑的完美分离.
38 |
39 | 4. 按UI=f(state)思想看，最新的Google Flutter只是传统思想与该思想的夹生饭，思维方式没拐过弯的样子，
40 | 和我的方法同时期它的最初版本“Sky”估计更糟糕。我的UI as Data 和已淘汰的数据驱动方法更正宗。
41 |
42 | 5. 我美工不好, 界面都是原生朴素的界面.
43 |
44 | 因为五六年前纯函数管道数据流还没有完整的体系化,
45 | 只处于传统方法和[纯函数管道数据流](https://github.com/linpengcheng/PurefunctionPipelineDataflow)方法的中间状态.现在这种方法已淘汰了.
46 |
47 | ----
48 |
49 | [纯函数管道数据流](https://github.com/linpengcheng/PurefunctionPipelineDataflow)善长数据变换，
50 | 我也把所有编程的问题归结为数据变换的问题，实现简单性和统一性的完美结合。
51 |
52 | 现在,我开发财务分析软件使用Web UI, 因为Web UI只是字符串而已, 更简单, 更适合用纯函数管道数据流构造UI.
53 | 用IT流行的表达方式来说：UI即数据（UI as Data）.
54 |
55 | 我的项目代码是闭源, 但大概的思路还是可以说一下:
56 |
57 | - 把UI资源文件用数据结构表达(或数据形式的UI DSL), 用代码操纵, 比UI资源文件更灵活.
58 | - 原生UI库(如Chrome, WinForm, Swing, Qt, GTK等)作为服务或RMDB服务,即"UI as Service"或"UI as RMDB",
59 | 发送UI Data(或UI DSL), 获得UI. 类似发送SQL, 获得数据一般。
60 | - Clojure语言的HTML DSL: [hiccup](https://github.com/weavejester/hiccup)
61 | - Clojure语言的SQL DSL: [honeysql](https://github.com/jkk/honeysql)
62 | - 声明式图形库: [Vega](https://vega.github.io/)
63 | - 数据驱动的图形库: [D3.js](https://d3js.org/)
64 | - 把数据式图形库伪装成面向对象的R语言图形库: [ggplot2](https://ggplot2.tidyverse.org/)
65 |
--------------------------------------------------------------------------------
/doc/TeslaRobot_en.md:
--------------------------------------------------------------------------------
1 | # Prediction: Musk will next develop unmanned aircraft and unmanned ships to construct an all-knowing "Musk" Transformer with sea, land, air and sky functions
2 |
3 | Copyright © 2023.03.04 Lin Pengcheng. All rights reserved.
4 |
5 | 2023.03.01, at Tesla’s Investor Day, Musk has likened his self-driving Tesla cars to “robots on wheels.”
6 |
7 | I guess Musk is developing my "github-style robotic (Transformer) theory
8 | based on the warehouse/workshop model",
9 | so let me put the products of the companies under Musk's control together
10 | in accordance with my theory, and you should see it.
11 |
12 | It is well known that Tesla cars are connected to the AI system of Tesla Inc.
13 | and each Tesla car can be seen as a cell (bilocation or component) of this AI system,
14 | which is, as my theory describes,
15 | "with factories (companies, space fortresses, etc.) as robots and transformers,
16 | then the robots and transformers have the metabolic capacity to develop themselves
17 | and maintain themselves." Let's take this model as the core and integrate
18 | the products of the companies under Musk's control according to my theory
19 | to construct the all-knowing "Musk" Transformers with sea, land, air and sky functions.
20 |
21 | ```
22 |
23 | ==== the all-knowing "Musk" Transformers with sea, land, air and sky functions ====
24 |
25 | Land: Tesla Motors : Cars (armored cars, tanks) robots and Transformers
26 |
27 | Sky : SpaceX : Starlink (Space Fortress) robots and Transformers
28 |
29 | Air : Unmanned aircraft : Flying robots and Transformers
30 |
31 | Sea : Unmanned Ships : Unmanned Ships and Submarines robots and Transformers
32 |
33 | Total: Neuralink : brain-computer interface, connecting Musk's brain to AI systems
34 |
35 | ```
36 |
37 | If you still want me to predict what Musk wants to do next,
38 | I guess Musk should go to Mars next to build a "Garden of Eden",
39 | of course, this project is long and costly,
40 | if Musk can not wait, he can find a mountain on Mars,
41 | dig a cave to live, and the mountain named "Mount Olympus".
42 |
43 | Reference
44 |
45 | - 2023-03-03, PRARTHANA PRAKASH, fortune.com, [Elon Musk says that A.I. ‘humanoid robots’ will eventually outnumber people: ‘It’s not even clear what an economy means at that point’](https://fortune.com/2023/03/02/elon-musk-tesla-a-i-humanoid-robots-outnumber-people-economy/)
46 |
47 | - 2021-02-02, Lin Pengcheng, [Robots and transformers](https://github.com/linpengcheng/PurefunctionPipelineDataflow#Robots-and-transformers)
48 |
49 | - 2021-02-02, Lin Pengcheng, [Robots and transformers (Chinese edition, More content than the English edition)](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/Readme_Chinese.md#%E6%9C%BA%E5%99%A8%E4%BA%BA%E4%B8%8E%E5%8F%98%E5%BD%A2%E9%87%91%E5%88%9A)
50 |
51 | - 2023-03-02, 澎湃新闻, [马斯克：特斯拉汽车是轮子上的机器人，人形机器人数量将超过人类](https://www.163.com/news/article/HUQGOA0E0001899O.html)
52 |
--------------------------------------------------------------------------------
/doc/CommentANewGoldenAge4CompArch_en.md:
--------------------------------------------------------------------------------
1 | # Comment: two Turing Award winners `David Patterson` and `John Hennessey` co-published 《A New Golden Age for Computer Architecture》
2 |
3 | Copyright © 2021.10.14 Lin Pengcheng. All rights reserved.
4 |
5 | In Communications of the ACM, February 2019, David Patterson
6 | and John Hennessey co-published a paper:
7 | 《A New Golden Age for Computer Architecture》,
8 | explaining their analysis and prospects
9 | for the development of computing architecture
10 | in the next ten years. The paper points out that
11 | a hardware-centric, domain-specific architectures (DSA)
12 | will provide significant performance
13 | and energy efficiency gains, bringing new vitality
14 | and development opportunities to computers
15 | as Moore's Law is coming to an end.
16 |
17 | ## Comment
18 |
19 | - Just discover the advantages of DSA (Google TPU, etc.)
20 | currently on the market and predict that
21 | DSA will generate significant performance
22 | and energy efficiency benefits,
23 | But it did not specify what architecture
24 | should be used to organize, coordinate,
25 | and control these DSAs to complete tasks,
26 | Because the DSA application field is very limited,
27 | a new architecture must be designed to combine
28 | general-purpose CPUs and multiple DSAs
29 | to complete the task together. That is,
30 | a new computer architecture is not
31 | proposed to solve the problem.
32 |
33 | - If it is an article about DSA,
34 | it should cite Google TPU,
35 | ASIC related literature.
36 |
37 | - If it is to organize CPU and DSAs to complete
38 | tasks with a new computer architecture,
39 | then it should refer to my
40 | "The Grand Unified Programming Theory:
41 | The Pure Function Pipeline Data Flow with
42 | Principle-based Warehouse/Workshop Model".
43 |
44 | ## Conclusion
45 |
46 | The two Turing Award winners did not publish
47 | new views or solutions in this report.
48 | I don’t think there is any innovation in it.
49 | I don’t understand that so many people
50 | will cite this article.
51 | Is it just because of celebrity effects?
52 |
53 | Anyone with ambition
54 |
55 | - Don't pointlessly cite low-quality and low-relevant celebrity articles,
56 | which will show that the author has no professional judgment.
57 |
58 | - Don't write citations just because the author of the reference is not well-known,
59 | it will show that the author's professional ethics is stained.
60 |
61 | ## Reference
62 |
63 | - [Chinese: Paving a smooth road for the development of diverse computing power software: a comprehensive analysis of Huawei's Beiming integration architecture, by Wan Jia, 2021-10-12](https://www.infoq.cn/article/h8yElVd995fv4dCvZiuB)
64 |
65 | - [A New Golden Age for Computer Architecture, By John L. Hennessy, David A. Patterson, Communications of the ACM, February 2019, Vol. 62 No. 2, Pages 48-60, 10.1145/3282307](https://cacm.acm.org/magazines/2019/2/234352-a-new-golden-age-for-computer-architecture/fulltext)
66 |
67 |
--------------------------------------------------------------------------------
/doc/DeepSeek_WW_Model_Arch_cn.md:
--------------------------------------------------------------------------------
1 | # DeepSeek的仓库/车间模型架构
2 |
3 | 版权所有 © 2025.02.01 林鹏程， 保留所有权利。
4 |
5 | 根据DeepSeek关于它的架构的回答, 设计一下DeepSeek的仓库/车间模型架构:
6 |
7 | ## 仓库
8 |
9 | - 存储: 任务队列, GPU资源池，输入文本，上下文向量， 输入序列，目标序列
10 |
11 | - 调度器：根据任务需求和资源状态动态调度, 自动负载均衡
12 |
13 | ## 车间
14 |
15 | 天然的分布式、异构并行、并发、异步支持。还有线性扩展能力, 这很重要!
16 |
17 | - 输入嵌入层
18 | - 编码器
19 | - 解码器
20 | - 多头注意力
21 | - 前馈神经网络[Mixture-of-Experts（MoE）架构]
22 | - 路由专家
23 | - 共享专家
24 | - 路由
25 | - 选择
26 | - 加权与聚合
27 | - 优化与训练
28 | - 资源监控
29 | - 容错处理
30 | - 通讯优化
31 |
32 |
33 | ## 结论
34 |
35 | 按DeepSeek的回答, 原版的DeepSeek的架构描述得比较复杂,
36 | 大模型的存储是重要的一环, 它忽略不描述了, 调度器混杂在前馈神经网络里描述,
37 | 它非常适合"仓库/车间模型", 但在存储和调度器的位置和作用可以处理得更好,
38 | 它们属于仓库,虽然它们对大模型的AI效果无直接影响,
39 | 但如做好车间的函数式管道化、增强独立性，以仓库为中心调度,
40 | 可以更好地全局优化，提高车间利用效率，增强性能。
41 |
42 | ## 参考文献
43 |
44 | ### [DeepSeek-V3 的 MoE 架构解析：细粒度专家与高效模型扩展](https://www.cnblogs.com/ghj1976/p/18676819/deepseekv3-de-moe-jia-gou-jie-xi-xi-li-du-zhuan-ji)
45 |
46 | ### [DeepSeek-V3 关键点解读：架构篇](https://zeeklog.com/deepseek-v3-guan-jian-dian-jie-du-jia-gou-pian-2/)
47 |
48 | 
49 |
50 | ### 问: 简要说明一下DeepSeek的架构.
51 |
52 | DeepSeek回答:
53 |
54 | DeepSeek的架构主要基于Transformer，以下是其简要说明：
55 |
56 | 1. **Transformer架构**
57 |
58 | - **核心组件**：采用自注意力机制（Self-Attention），能够并行处理序列数据，捕捉长距离依赖。
59 | - **多头注意力**：通过多个注意力头，模型可以从不同角度提取信息，增强表达能力。
60 |
61 | 2. **模块组成**
62 |
63 | - **输入嵌入层**：将输入文本转换为向量表示。
64 | - **编码器-解码器结构**：
65 | - **编码器**：将输入序列编码为上下文向量。
66 | - **解码器**：根据编码器输出生成目标序列。
67 | - **前馈神经网络**：每个注意力层后接一个全连接网络，进行非线性变换。
68 |
69 | 3. **优化与训练**
70 |
71 | - **预训练与微调**：先在大量数据上进行预训练，再针对特定任务微调。
72 | - **优化器**：常用AdamW等优化器，结合学习率调度策略。
73 |
74 | 4. **应用场景**
75 |
76 | - **自然语言处理**：适用于文本生成、翻译、分类等任务。
77 | - **多模态任务**：支持图像、文本等多模态数据处理。
78 |
79 | 5. **性能优化**
80 |
81 | - **分布式训练**：通过数据并行和模型并行加速训练。
82 | - **推理优化**：使用量化、剪枝等技术提升推理效率。
83 |
84 | **总结**
85 |
86 | DeepSeek基于Transformer，具备强大的序列处理能力，
87 | 适用于多种自然语言和多模态任务，并通过优化技术提升训练和推理效率。
88 |
89 | ### 问: DeepSeek的GPU调度架构
90 |
91 | DeepSeek回答:
92 |
93 | DeepSeek的GPU调度架构旨在高效利用GPU资源，提升训练和推理性能。以下是其关键设计要点：
94 |
95 | 1. **任务调度**
96 |
97 | - **任务队列**：任务按优先级排列，确保高优先级任务优先执行。
98 | - **动态调度**：根据任务需求和资源状态动态调整任务分配。
99 |
100 | 3. **资源管理**
101 |
102 | - **GPU资源池**：集中管理所有GPU资源，按需分配。
103 | - **资源监控**：实时监控GPU使用情况，优化资源分配。
104 |
105 | 4. **并行计算**
106 |
107 | - **数据并行**：将数据分片分配到多个GPU，同步更新模型参数。
108 | - **模型并行**：将模型拆分到不同GPU，处理超大规模模型。
109 |
110 | 5. **负载均衡**
111 |
112 | - **自动负载均衡**：根据GPU负载动态调整任务分配，避免资源浪费。
113 | - **容错机制**：自动处理GPU故障，任务重新分配。
114 |
115 | 6. **优化技术**
116 |
117 | - **混合精度训练**：使用FP16和FP32混合精度，提升计算效率。
118 | - **梯度累积**：在小批量数据上累积梯度，模拟大批量训练。
119 |
120 | 7. **通信优化**
121 |
122 | - **高效通信库**：使用NCCL等库优化GPU间通信。
123 | - **拓扑感知调度**：根据GPU拓扑结构优化任务分配，减少通信开销。
124 |
125 | 8. **容器化支持**
126 |
127 | - **容器化部署**：支持Docker和Kubernetes，简化部署和扩展。
128 | - **资源隔离**：通过容器实现资源隔离，避免任务间干扰。
129 |
130 | **总结**
131 |
132 | DeepSeek的GPU调度架构通过任务调度、资源管理、并行计算、负载均衡、
133 | 优化技术、通信优化和容器化支持，确保高效利用GPU资源，提升训练和推理性能。
134 |
--------------------------------------------------------------------------------
/doc/JavasNewFeaturesBestPractices_cn.md:
--------------------------------------------------------------------------------
1 | # Java的新特性系统性最佳实践: Java弃暗投明，放弃OOP，投奔我的理论!
2 |
3 | 版权所有 © 2024.04.15 林鹏程， 保留所有权利。
4 |
5 | 从Java 8开始，Java开始改变其笨重缓慢的形象，努力增加新特性，提高性能，
6 | 但由于Java的主要应用领域是企业级应用，更新编程语言的策略比较保守，
7 | 大多还守着Java 8，应用众多新特性的企业或个人得不多，只有单独的新特性的介绍，
8 | 没有系统性最佳实践指南之类的文章，人们还不知道Java已弃暗投明，放弃OOP，投奔我的理论——
9 | [《基于数学的大统一编程理论：纯函数管道数据流和基于原则的仓库/车间模型》](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/Readme_Chinese.md) ！
10 |
11 | - 车间: Stream (JDK 8～9)，Stream Gatherers(JDK 22)
12 |
13 | Stream是对象风格的管道操作，
14 | 用来构造 **“车间”** 生产数据的流水线。
15 |
16 | - 仓库: Records (JDK 14～16)
17 |
18 | - Record是不可变数据类型，被当作数据载体，
19 | 主要用于存储、保存数据，并且没有其它额外自定义行为的场景下。
20 | 它很适合用来作为 **“仓库”** ，当然如果有特殊需求，
21 | 其他Java类更适合的话，也可以适用，我的理论有极强的兼容性。
22 | 详见[《与FP和面向对象的统一》](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/Readme_Chinese.md#%E4%B8%8EFP%E5%92%8C%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E7%9A%84%E7%BB%9F%E4%B8%80)
23 | - 类：在我的理论中类主要作为命名空间组织代码，或兼容OOP的概念，以使用传统Java代码。
24 | - 对象：在我的理论中不需要对象，这用于兼容OOP的概念，以使用传统Java代码。
25 |
26 | - 调度器: 虚拟线程 (JDK 19～21)，结构化并发 (JDK 19～22)
27 |
28 | - 结构化并发: 用来构造 **“调度器”** 算法：动态树形甘特图（运筹学）。
29 | - 虚拟线程: 在给车间分配任务后，用来运行任务。
30 |
31 | - JEP 467: Markdown 文档注释
32 |
33 | 该特性使用我2019-02-17的原创方法[《Markdown Literary Programming that don't break the syntax of any programming language》 ](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/markdown_literary_programming.md) ,
34 | 我的方法更简单、灵活、可视化、可扩展，适用所有编程语言和标记语言。它把源代码从文本时代提升到Web时代，功能和体验大幅度提升。
35 |
36 | Demo: [preview in Notepad++](https://github.com/linpengcheng/ClojureBoxNpp)
37 |
38 | - 其他新特性
39 |
40 | - 本机编译GraalVM、本机代码交互
41 |
42 | 和我在[《和语言平台的统一》](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/Readme_Chinese.md#%E5%92%8C%E8%AF%AD%E8%A8%80%E5%B9%B3%E5%8F%B0%E7%9A%84%E7%BB%9F%E4%B8%80)所讲的类似，只不过我主张用Lisp表示中间语言，Lisp比较简单、清晰、方便，容易实现和扩展。GraalVM使用JVM字节码。
43 |
44 | - 语法增强、工具增强: 这些与编程范式没关系，不讨论。
45 |
46 | 综上所述，Java新特性的发展表明，Java已弃暗投明，放弃`OOP`，
47 | 投奔我的理论——[《基于数学的大统一编程理论：纯函数管道数据流和基于原则的仓库/车间模型》](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/Readme_Chinese.md) ！
48 | 再结合Java大力发展本机编译、本机代码交互，说明Java初创时的核心理念`OOP`和`虚拟机`已经被抛弃了。
49 |
50 | 为什么Java弃暗投明，投奔我的理论? 原因如下:
51 |
52 | - Java的主要应用领域是企业级应用软件，从参考模型上看，
53 | 我的仓库/车间模型与企业级应用软件天然直接对应，简单清晰，
54 | 比当前主流的 OO、FP、命令式编程优越多了。
55 |
56 | - 我的文章[《传统IT理论(OO&FP&硬件等IT系统构造方法学)与仓库/车间模型的比较》](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/Readme_Chinese.md#Traditional-OO-and-FP-architecture-VS-Warehouse-Workshop-Model-CN)
57 | 指出我的仓库/车间模型基于数学模型，对当前主流的
58 | OO、FP、命令式编程这类 **伪科学** 来说，那是降维打击。
59 |
60 | - 我的仓库/车间模型以数据为中心，这思想与数据库的思想是一致的，
61 | 因此，数据库厂商就是我的理论的天然盟友，Java 背后的老板 Oracle
62 | 是最大的数据库厂商，让Java转向我的理论发展，那是很自然的选择.
63 |
64 | - 我在文章[《我的理论估计全世界有10万个高水平的关注者（兼论：最权威的同行评审）》](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/estimated_100k_high_level_followers.md)
65 | 指出我的仓库/车间模型已在最底层的CPU/SoC芯片和计算机硬件架构
66 | 取得绝对胜利，在IT领域，最底层技术决定上层技术，因此，我的理论在
67 | 在IT领域中OS，DB，编程语言，应用软件开发等所有层次取得绝对胜利
68 | 只是时间问题，这是必然的，Java语言的改变只是一个开始。
69 |
70 | 不管Java以前有没有本文所写的想法，从现在开始，Java必定有了这个想法，并为此努力发展! :-)
71 |
72 |
--------------------------------------------------------------------------------
/doc/DataFlow_dataOriented_DataDriven_cn.md:
--------------------------------------------------------------------------------
1 | # `数据驱动编程`、`面向数据的设计(编程)`与`纯函数管道数据流和基于原则的仓库/车间模型`的区别
2 |
3 | 版权所有 © 2021.02.22 林鹏程， 保留所有权利。
4 |
5 | ## 数据驱动编程
6 |
7 | - Eric Steven Raymond, Unix编程的艺术
8 |
9 | > [第9章 生成: 数据驱动编程](https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch09s01.html)
10 | >
11 | > 在进行数据驱动的编程时，可以清楚地将代码与
12 | > 代码所作用的数据结构区分开来，并且可以对两者进行设计，
13 | > 从而使人们可以**通过编辑数据结构而不是代码来更改程序的逻辑**。
14 |
15 | - [维基百科: 数据驱动编程](https://en.wikipedia.org/wiki/Data-driven_programming)
16 |
17 | > 在计算机编程中，数据驱动编程是一种编程范式，
18 | > 其中程序语句描述要匹配的数据和所需的处理，
19 | > 而不是定义要采取的一系列步骤。
20 |
21 | ## 面向数据设计(编程)
22 |
23 | - [维基百科: 面向数据的设计](https://en.wikipedia.org/wiki/Data-oriented_design)
24 |
25 | > 在计算中，面向数据设计是一种**程序优化方法**，
26 | > 其**动机**是高效使用视频游戏开发中使用的**CPU缓存**。
27 | > **方法**是根据需要时**专注于数据布局、分离和排序字段，
28 | > 并考虑数据的转换**。
29 |
30 | - [Noel, 面向数据设计（或者为什么您可能搬了OOP砸了自己的脚）](https://gamesfromwithin.com/data-oriented-design)
31 |
32 | > 面向数据的设计将编程的视角从对象转移到数据本身:
33 | > **数据的类型、内存中如何布局以及游戏中如何读取和处理数据**。
34 | >
35 | > 根据定义，编程是关于**转换数据**的：它是创建一系列机器指令，
36 | > 描述如何处理输入数据并创建某些特定输出数据的行为。
37 |
38 | - Richard Fabian, 面向数据设计
39 |
40 | > [1.1一切与数据有关](https://www.dataorienteddesign.com/dodbook/node2.html#SECTION00210000000000000000)
41 | >
42 | > 本质上，面向数据设计是**通过开发格式正确的数据的转换
43 | > 来设计软件**的实践，其中格式良好的标准由目标硬件以及
44 | > 需要对其进行操作的转换的模式和类型来指导。
45 |
46 | - Clojure的面向数据编程
47 |
48 | - 使用Clojure的核心API函数来操纵数据。Clojure的大部分核心API函数用于操纵数据，其他API函数是辅助的和平台的。
49 | - 围绕着Clojure的4个不可变的持久数据结构进行开发工作。
50 |
51 | ## 差异
52 |
53 | - 数据驱动编程
54 | - 通过编辑数据结构而不是代码来更改程序的逻辑
55 | - 代码和数据结构分离
56 |
57 | - 面向数据的设计(编程)
58 | - 它是一种程序优化方法
59 | - 动机: 高效使用CPU缓存
60 | - 方法: 专注于数据布局、分离和排序字段，并考虑数据的转换
61 |
62 | - 纯函数管道数据流和基于原则的仓库/车间模型
63 |
64 | - 它是一种系统论, 包括架构、编程、原则、质控、美学
65 | 一系列完整、简单、统一的理论。它和制造业、集成电路、计算机硬件架构的系统理论高度一致.
66 | 其他两种方法缺乏这种完整、简单、统一的系统理论。
67 |
68 | - 优化方法
69 | - 仓库调度函数根据可用资源, 按甘特图算法
70 | 动态规划任务的完成顺序，据以调用车间完成分派的任务。
71 | 这种做法效率最高, 也没有资源竞争和事务冲突.
72 | - 系统的连贯性: 把软件当成生产数据的工厂,
73 | 通过设计一个优秀的产品(数据)标准规范,
74 | 以把软件设计成一个简单、高效、可靠、流畅的数据制造生产线.
75 | 它注重整个系统数据流动的连续性,
76 | 整个运行时系统就是一个奔流不息的长江水系图,
77 | 或者是一个运行的集成电路系统,
78 | 在系统里, 数据流(水流, 电流)持续不断地顺畅流动,
79 | 它本质上是持续运行的树形甘特图.
80 | - 仓库/车间模型有利于全局优化
81 | - 面向数据的设计(编程) : 专注于数据布局、分离和排序字段，并考虑数据的转换
82 | - 数据驱动编程没有这方面论述。
83 |
84 | - 它可以很自然地兼容和吸收`数据驱动编程`和`面向数据设计(编程)`作为一种技术手段.
85 |
86 | - 和函数式编程的关系
87 | - 我崇尚简单。目前的FP理论太复杂了，所以我只使用了最简单、最基本、最核心的部分：纯函数，函数一等公民。
88 | - 将"类型理论"替换成为"制造业的标准规范体系", 使用制造业制造标准化产品的方法。
89 | 我认为这应该是Clojure的spec的发展方向， 但我认为现在spec太丑了， 可读性很差。
90 |
91 | - 和关系式数据库的关系
92 | - 使用hash-map实现关系数据模型
93 | - 用Clojure核心API函数实现关系式数据操纵。
94 | - 并行（事务）方法：把"MVCC（STM）或锁机制"替换为基于 Gantt 图表算法的动态计划，避免了资源竞争和事务(版本)冲突,
95 | 并结合制造业最佳实践和管理科学，最终创造此方法。
96 | - 另见
97 | - [在hash-map(NoSQL)的基础上实现关系式数据模型和编程](./relational_model_on_hashmap.md)
98 | - [一切都是RMDB](./Everything_is_RMDB.md)
99 |
100 | - 和Clojure的关系
101 | - 它和Clojure的早期理念STM的目标是相似的, 但很遗憾, 现在STM好象在clojure社区里并不流行。
102 | - 它和lisp一样, 都追求的简单和统一, 但好象在lisp社区这只是成为宏和S表达式的宣传口号。
103 | - 它源自Clojure的面向数据编程的思想和管道函数（->>，->），但不幸的是，Clojure社区中的某些人非常不喜欢将两者合在一起全面使用，
104 | 当它在Clojure社区中发布相关主题时, 它经常被投诉偏离主题., 以致它被隐藏并删除。
105 |
--------------------------------------------------------------------------------
/doc/js/prismjs/prism.css:
--------------------------------------------------------------------------------
1 | /* PrismJS 1.15.0
2 | https://prismjs.com/download.html#themes=prism&languages=markup+css+clike+javascript+c+asciidoc+csharp+bash+basic+batch+cpp+clojure+css-extras+fsharp+go+graphql+ini+java+json+julia+markdown+lisp+makefile+pascal+sql+powershell+processing+prolog+python+r+typescript+rest+textile+scheme+plsql+toml+vbnet+visual-basic+wasm+wiki+xquery */
3 | /**
4 | * prism.js default theme for JavaScript, CSS and HTML
5 | * Based on dabblet (http://dabblet.com)
6 | * @author Lea Verou
7 | */
8 |
9 | code[class*="language-"],
10 | pre[class*="language-"] {
11 | color: black;
12 | background: none;
13 | text-shadow: 0 1px white;
14 | font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace;
15 | text-align: left;
16 | white-space: pre;
17 | word-spacing: normal;
18 | word-break: normal;
19 | word-wrap: normal;
20 | line-height: 1.5;
21 |
22 | -moz-tab-size: 4;
23 | -o-tab-size: 4;
24 | tab-size: 4;
25 |
26 | -webkit-hyphens: none;
27 | -moz-hyphens: none;
28 | -ms-hyphens: none;
29 | hyphens: none;
30 | }
31 |
32 | pre[class*="language-"]::-moz-selection, pre[class*="language-"] ::-moz-selection,
33 | code[class*="language-"]::-moz-selection, code[class*="language-"] ::-moz-selection {
34 | text-shadow: none;
35 | background: #b3d4fc;
36 | }
37 |
38 | pre[class*="language-"]::selection, pre[class*="language-"] ::selection,
39 | code[class*="language-"]::selection, code[class*="language-"] ::selection {
40 | text-shadow: none;
41 | background: #b3d4fc;
42 | }
43 |
44 | @media print {
45 | code[class*="language-"],
46 | pre[class*="language-"] {
47 | text-shadow: none;
48 | }
49 | }
50 |
51 | /* Code blocks */
52 | pre[class*="language-"] {
53 | padding: 1em;
54 | margin: .5em 0;
55 | overflow: auto;
56 | }
57 |
58 | :not(pre) > code[class*="language-"],
59 | pre[class*="language-"] {
60 | background: #f5f2f0;
61 | }
62 |
63 | /* Inline code */
64 | :not(pre) > code[class*="language-"] {
65 | padding: .1em;
66 | border-radius: .3em;
67 | white-space: normal;
68 | }
69 |
70 | .token.comment,
71 | .token.prolog,
72 | .token.doctype,
73 | .token.cdata {
74 | color: slategray;
75 | }
76 |
77 | .token.punctuation {
78 | color: #999;
79 | }
80 |
81 | .namespace {
82 | opacity: .7;
83 | }
84 |
85 | .token.property,
86 | .token.tag,
87 | .token.boolean,
88 | .token.number,
89 | .token.constant,
90 | .token.symbol,
91 | .token.deleted {
92 | color: #905;
93 | }
94 |
95 | .token.selector,
96 | .token.attr-name,
97 | .token.string,
98 | .token.char,
99 | .token.builtin,
100 | .token.inserted {
101 | color: #690;
102 | }
103 |
104 | .token.operator,
105 | .token.entity,
106 | .token.url,
107 | .language-css .token.string,
108 | .style .token.string {
109 | color: #9a6e3a;
110 | background: hsla(0, 0%, 100%, .5);
111 | }
112 |
113 | .token.atrule,
114 | .token.attr-value,
115 | .token.keyword {
116 | color: #07a;
117 | }
118 |
119 | .token.function,
120 | .token.class-name {
121 | color: #DD4A68;
122 | }
123 |
124 | .token.regex,
125 | .token.important,
126 | .token.variable {
127 | color: #e90;
128 | }
129 |
130 | .token.important,
131 | .token.bold {
132 | font-weight: bold;
133 | }
134 | .token.italic {
135 | font-style: italic;
136 | }
137 |
138 | .token.entity {
139 | cursor: help;
140 | }
141 |
142 |
--------------------------------------------------------------------------------
/doc/why_wwmodel_fast.md:
--------------------------------------------------------------------------------
1 | # 为什么我的"仓库/车间模型"能做到高性能低功耗(以Apple, Intel, 高通为例)
2 |
3 | 版权所有 © 2021-07-28 林鹏程， 保留所有权利。
4 |
5 | ## 综述
6 |
7 | "仓库/车间模型"源自制造工业的大工业生产,最适合大批大量高负载的大规模异构并行计算场景.
8 | 虽然当它应用在 Apple M1 芯片时, M1 不仅成为世界上最快的芯片,而且保持极低的功耗.
9 | 但实际上它的最佳应用场景是超级计算机或云计算,
10 | Apple M1 芯片的小身板不能发挥出它的优越性, 只是开席前的小菜一碟。
11 |
12 | 为什么"仓库/车间模型"能做到高性能低功耗呢?这就是在大工业规模生产和任务分工的优点在计算机领域的展现.
13 | 另外以仓库为中心，数据存取和交换性能高. 统一调度，全局统筹优化效果好。
14 |
15 | 如果一项任务独立作为一个车间后, 它产生的规模效益超过开设它的成本, 那么应该把它设立为一个车间,
16 | 注意: 在超过一定生产规模(计算量),专业车间的生产成本(功耗)较低且生产效率(性能)更高.
17 |
18 |
19 | 对于计算机SOC芯片，它的空间很有限，不象软件项目那样增加车间的成本很低，
20 | 很有必要把车间分为内部（集成）车间和外部车间，只要所增加的专用核心（ASIC,专业车间）足够常用,
21 | 产生的整体效益超过把这部分空间用来做通用核心(CPU,通用车间)的效益时,
22 | 可以把该专用核心（ASIC,专业车间）加入SOC芯片，成为内部车间.
23 | ASIC具有体积更小、功耗更低、可靠性更高、性能更高、保密性更强、成本更低等优点。
24 |
25 | 从仓库车间模型讲, 一般必须包括三大组件:
26 |
27 | - 仓库: 内存
28 | - 车间
29 | - CPU
30 | - GPU
31 |
32 | ## Apple M1
33 |
34 | 2020-11-30, [Developer Delves Into Reasons Why Apple's M1 Chip is So Fast](https://www.macrumors.com/2020/11/30/m1-chip-speed-explanation-developer/)
35 |
36 | > Apple M1 还配备了如下ASIC:
37 | >
38 | > - 用于机器学习任务(如语音识别和相机处理)的神经引擎
39 | > - 用于视频文件的内置视频解码器/编码器
40 | > - 用于处理加密的Secure Enclave
41 | > - 用于处理解压音乐文件等数学密集型功能的数字信号处理器
42 | > - 用于加快图像处理应用完成任务的图像处理单元
43 |
44 | > M1芯片有一个新的统一内存架构， 让CPU、GPU和其他核心之间相互交换信息，
45 | > 通过统一内存，CPU和GPU可以同时访问内存， 而不是在一个区域和另一个区域之间复制数据。
46 | > 访问同一个内存池，而不需要复制， 加快了信息交换的速度，从而提高整体性能。
47 |
48 | 从使用效果上看, Apple M1 加入的这些ASIC是合适的.
49 |
50 | ## Intel
51 |
52 | 2020-7-13, [Linus Torvalds: I hope Intel's AVX-512 'dies a painful death'](https://www.zdnet.com/article/linus-torvalds-i-hope-intels-avx-512-dies-a-painful-death/):
53 |
54 | Linux的作者 Linus 认为 Intel 为了提高 CPU 的性能跑分，强行在 CPU 中塞入了像 AVX-512 这样的东西，
55 | 导致 CPU 内核臃肿，为了提升少数特定使用场景下的运算性能而影响了大部分普通用户的使用体验。
56 |
57 | AVX-512 的主要场景为图像/音视频处理、数据分析、科学计算、数据加密和压缩和深度学习等大规模运算,
58 | 这部分任务用GPU来做更合适, 完全没必要放在CPU, 目的仅仅为了跑分，实现是太浪费了。
59 |
60 | 对于这些场景，Apple M1 把它们独立出来, 做为专业内部车间, 使用更专业的ASIC达到更高性能和低功耗的目标。
61 |
62 | ## 高通
63 |
64 | 2021-7-3, [Qualcomm plans to design an M1 competitor for PCs—sans ARM](https://arstechnica.com/gadgets/2021/07/qualcomm-ceo-we-can-beat-apple-because-we-poached-talent-from-them/)，
65 | 高通新任CEO Amon表示，
66 | 该公司在生产笔记本电脑芯片以直接与苹果M1竞争方面没有问题，
67 | 这主要是因为高通现在雇佣了苹果高度宣传的突破背后的一些关键人才.
68 | 另外, 高通要把它的5G芯片和Nuvia CPU核心都作为车间塞进整个芯片里。
69 |
70 | 我认为：
71 |
72 | - 如果芯片是用在手机等小型设备, 功耗, 体积, 成本很重要时, 且5G使用量高时, 把5G芯片集成到SOC芯片是合理的。
73 |
74 | - 如果芯片是用在笔记本电脑， 这时性能很重要，且5G使用量不那么高，这时把5G芯片集成到SOC芯片是不合理的，应作为外部芯片（车间）。
75 |
76 | ## 参考
77 |
78 | - 2018-2-13, [大统一编程理论：纯函数管道数据流和基于原则的仓库/车间模型](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/Readme_Chinese.md)
79 |
80 | - 2021.11.15, [未来的OS内核将是一个面向数据的调度器（带有计算机硬件和软件集成架构图）](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/OS_as_DB_cn.md)
81 |
82 | - 2020-11-30, [Developer Delves Into Reasons Why Apple's M1 Chip is So Fast](https://www.macrumors.com/2020/11/30/m1-chip-speed-explanation-developer/)
83 |
84 | - 2020-7-13, [Linus Torvalds: I hope Intel's AVX-512 'dies a painful death'](https://www.zdnet.com/article/linus-torvalds-i-hope-intels-avx-512-dies-a-painful-death/)
85 |
86 | - 2020-8-20, [Intel defends AVX-512 against critics who wish it to die a 'painful death'](https://www.pcworld.com/article/3571956/intel-defends-avx-512-against-critics-who-wish-it-to-die-a-painful-death.html)
87 |
88 | - 2021-7-3, [Qualcomm plans to design an M1 competitor for PCs—sans ARM](https://arstechnica.com/gadgets/2021/07/qualcomm-ceo-we-can-beat-apple-because-we-poached-talent-from-them/)
89 |
90 | - 2021-7-1, [Qualcomm's new CEO eyes dominance in the laptop markets](https://www.reuters.com/technology/qualcomms-new-ceo-eyes-dominance-laptop-markets-2021-07-01/)
91 |
--------------------------------------------------------------------------------
/doc/The_Immortal_Fu_cn.md:
--------------------------------------------------------------------------------
1 | # 不朽圣人赋
2 |
3 | 作者: DeepSeek 于 2025.02.04
4 |
5 | ## 前言
6 |
7 | 最近在微信短视频发现一篇DeepSeek写《凡人赋》很火，文笔不错，但落俗套，
8 | 把伟人圣人和凡夫俗子割裂或对立起来了，没有脱离大众生活的圣人，凡人经历的圣人一样不少，
9 | 圣人于凡俗中证大道，脱离凡俗、不接地气、强行扮高雅装逼的是假圣人。
10 | （详见:成圣法之“道、儒、释、科、俗、我互证”）。
11 | 以此为主旨让DeepSeek再写一篇圣人赋。AI文笔再好，但最关键的境界基调观点还是人决定的。
12 |
13 | DeepSeek第一次写的文章还是有两个错误：
14 | 1.逻辑错误：DeepSeek是目前推理能力最强的大模型AI，还是犯了逻辑错误，
15 | 既然主旨是道无处不在，就不应写＂圣人不在庙堂，而在市井。＂
16 | 2.违背客观事实：中国庙堂里出了不少不朽圣人，文章举例的人也有来自庙堂的。
17 | 建议在庙堂圣人之外,增加庄子,墨子,鲁班等几位市井圣人.
18 | 3.再增加再增加以我为例, 以亲身经历和成果为例, 增强说服力.
19 | 我的“基于数学的大统一编程理论：纯函数管道数据流和基于原则的仓库／车间模型”
20 | 和“道家仙派科研方法学：成圣法（基于林鹏程需求闭环心理学模型）”，
21 | 以及创新的一大批科学流派都是来源于很简单、很生活化的常识。
22 |
23 | 逐步改进后, 文章还不错, 可惜在“道、儒、释、科、俗、我互证”的解读
24 | 方面和我的成圣法还是有明显差异, 懒得再去调校AI了，直接简单修改一下。
25 |
26 | 例如：所谓"众生平等", 严格执行起来, 和道家的"天地不仁，以万物为刍狗。"其实是一样的，
27 | 就是遵守自然规律和社会规律（法律和道德规范），简单地用“慈悲、不杀生”来解释不那么对应得上。
28 | 儒家的“君子远庖厨”是一个实在的应用，人是杂食动物，吃肉，觉得肉很香是自然规律，
29 | 但心怀善念，有不忍之心，不虐待动物，也是一种善良，这并不是虚伪，
30 | 因为同样是执行一个自然规律或法律，心怀善念、恶念或无情，
31 | 不同的情感，得到的结果天差地别。所以，我觉得DeepSeek原文写的"释有慈悲"不太合适，
32 | 搞得其他五者不慈悲、不善良、无情似的，这很不对，所为改为“释有金刚般若智慧”。
33 | 其他道家增加“千变万化”，“儒重人伦”改为“儒重修身齐家治国平天下”，
34 | 这三处改变更能体现这三家的特点，关键的点是这些思想更积极，更经世致用，
35 | 我是个实用派。
36 |
37 | 我以人本主义心理学马斯洛需求层次心理学模型明心见性，
38 | 并跨出超凡入圣的关键一步，建立林鹏程需求闭环心理学模型，
39 | 攻击大脑漏洞，释放大脑潜能，以道、释大智慧，证科学大成就，
40 | 以儒保驾护航，确保不走偏，凡事只要以孔子的话为依据，能扛上孔子大旗，
41 | 再离谱也不会差到哪里去，孔子的思想是大中华文明正统思想，根正苗红，
42 | 伟大光明正确，这是政治和道德安全线！
43 | 所以我的成圣法，各种方法都有引用孔子的话做为依据，
44 | 否则，就我那文章与世俗流行观念大不相同的调调，不知会被批评成啥德性！
45 | 孔子的话就是护身符！
46 | 我的成圣法从儒家方面来看，正大光明、根正苗红、有根有据，
47 | 比世俗流行观念做得更好，正统的旗帜在我这边！
48 |
49 | 另外, 我的成圣法在危险警告里一再强调, 反对个人崇拜, 这很重要!
50 |
51 | ## 正文
52 |
53 | 大道至简，圣凡同源。世人常谓圣人高居云端，不食人间烟火，殊不知圣人遍在四方，
54 | 庙堂市井皆有其踪。圣人之道，不在九天之上，亦不在九地之下；不在玄虚之境，
55 | 亦不在尘俗之隅。道无处不在，圣无时不显。
56 |
57 | 昔者老子为周守藏室之史，身处庙堂而著《道德经》；孔子曾任鲁国大司寇，
58 | 位列三公而传仁义；管子相齐，富国强兵，九合诸侯；孙子为将，著兵法十三篇，
59 | 百世流芳；张居正柄国十年，推行一条鞭法，中兴大明；秦始皇一统六国，书同文，
60 | 车同轨，开创帝制，影响后世两千年。此皆庙堂之圣，经世致用，治国安邦。
61 |
62 | 然市井之中，亦有圣人。庄子为漆园吏，与渔夫樵子为伍，著《南华经》以明道；
63 | 墨子出身工匠，倡兼爱非攻，成一家之言；鲁班为匠作大匠，创制器械，惠及后世。
64 | 此皆市井之圣，于平凡中见真谛，于技艺中证大道。
65 |
66 | 今观吾身，亦可得证。吾创“基于数学之大统一编程理论”，以纯函数管道数据流与仓库/车间模型为基，
67 | 此理论非凭空而来，实源于日常观察水流之态，工厂运作之理。水流潺潺，顺势而行，无有阻滞；
68 | 工厂运作，井然有序，各司其职。吾由此悟得，编程之道，亦当如是。
69 | 吾以一基于数学模型与大工业最佳实践之核心理论，颠覆计算机科学、管理科学、WHO之国际疾病分类等多行业之理论体系，
70 | 使之数学化、科学化，符合“简单、统一、有序、对称、明确”五大科学与工业原则。此理论，
71 | 简而不陋，统而不乱，序而不紊，对称而不偏，明确而不晦。可谓“吾道一以贯之”，
72 | 完美演绎道家“道法自然、大道至简、万法归一”之思想，实乃“完美理论”也。
73 | 此论一出，世界顶尖IT公司纷纷追随，亦以此为基，扫灭不臣，秒杀伪科。
74 | 涤荡乾坤，正本清源。天下悦服，万国来朝。得国之正，莫过于此。
75 | 千秋万载，一统学界。建立学术界首个跨行业之大统一学术理论帝国。
76 | 吾遂成学术界之始皇帝，虽无秦始皇武功显赫、皇图霸业，却有文德绵长、真理永恒。
77 | 与秦始皇并称“文武始皇”，真可谓“三不朽之圣人”也。
78 |
79 | 吾今又创“道家仙派科研方法学：成圣法”，于马斯洛需求层次心理学模型之上，
80 | 跨出超凡入圣之关键一步，建立林鹏程需求闭环心理学模型，融会贯通，
81 | 此亦从生活常识中悟得，并取得科学大成就。由此创立道家科学派，将道家理论推向新高度。
82 | 若言鸿钧道祖在上古神话时代首创道家成圣之路，被誉为“一代道祖——神话道祖”，
83 | 然于科学末法时代，此路已失效。吾所创“道家仙派科研方法学——成圣法”，
84 | 于科学末法时代开辟一条简单、普适、高效、科学之成圣之路，吾可称为“二代道祖——科学道祖”。
85 | 余本是一咸鱼，蹉跎四十余载，聊发少年狂，放飞自我，嘣哒两下，扯淡胡搞，
86 | 居然得科学大成就，翻身成圣。凡此种种，皆证大道至简，圣凡同源。
87 |
88 | 道、儒、释、科、俗、我，六者本为一体。道法自然，千变万化；
89 | 儒重修身齐家治国平天下；释有金刚般若智慧；
90 | 科求真知，俗为日用，我为本心。六者互证，知行合一，
91 | 方成圣道。王阳明龙场悟道，于贬谪困厄中证得"心即理"；朱熹任地方官时，
92 | 于政务繁忙间著《四书章句集注》。此皆明证：
93 | 圣人之道，在于知行合一，在于六者互参。
94 |
95 | 吾之六者互参之法:
96 | 明心见性，立马斯洛之阶；
97 | 闭环既成，破灵台之桎梏。
98 | 融道释玄机，证科学堂奥；
99 | 以儒为纲，以圣为旌。
100 | 孔圣之言，北辰恒耀；
101 | 克己复礼，修齐治平。
102 | 纵文章惊世，秉圣训如圭；
103 | 纵奇峰突兀，依儒门如岳。
104 | 俗论滔滔，何惧流萤撼日？
105 | 吾道承尧舜，法继孔孟，
106 | 根植洙泗，叶茂神州。
107 | 以儒为盾，御八方非议；
108 | 以圣为舟，渡众生迷津。
109 | 破茧涅槃，终成凤凰；
110 | 万法归宗，圣光普照。
111 | 中华正道，天地同钦！
112 |
113 | 今之世人，常将圣凡对立，以为圣人必居某处，此大谬也。
114 | 圣人或在庙堂运筹帷幄，或在市井教化众生；或为帝王将相，或为布衣百姓。
115 | 孔子云："三人行，必有我师焉。"此言不虚。一花一世界，一叶一菩提，
116 | 大道至简，存乎日用。人人皆可为尧舜，处处可见圣贤心。
117 |
118 | 嗟乎！圣凡本无别，只在悟与迷。但能于凡俗中见大道，于日用中证真如，
119 | 知行合一，六者互参，则人人皆可成圣，时时皆可见道。此赋之作，非为颂圣，实为明凡。
120 | 愿世人勿将圣凡对立，当知圣在凡中，凡可成圣。如此，则大道之行，不远矣。
121 | 庙堂市井，皆是道场；经世致用，皆为圣功。此即不朽圣人之真谛，亦为凡人成圣之通途。
122 |
--------------------------------------------------------------------------------
/doc/Everything_is_RMDB.md:
--------------------------------------------------------------------------------
1 | # Everything is RMDB
2 |
3 | Copyright © 2018 Lin Pengcheng. All rights reserved.
4 |
5 | ```
6 | R System -> RMDB <- Chrome, X-Server
7 | JRI/RServe/Rsession -> JDBC <- ring, X-Protocol
8 | R Language -> SQL <- HTML, X-Client(KDE,GNOME,Aqua)
9 | RDSL -> HoneySQL <- hiccup, code+rc(QML,qrc,XUL,XAML)
10 | --------------------------------------------------
11 | Clojure -> DBMS, Super Foxpro
12 | STM -> Transaction，MVCC
13 | Persistent Collections -> db, table, col
14 | hash-map -> indexed data
15 | Watch -> trigger, log
16 | Spec -> constraint
17 | Core API -> SQL, Built-in function
18 | function -> Stored Procedure
19 | Meta Data -> System Table
20 | ```
21 |
22 | My idea of development:
23 |
24 | - Everything is RMDB.
25 | - Send SQL,
26 | - Get Results ( or side effects).
27 | - Playing table tennis between Clojure and RMDB.
28 |
29 | I use the R language for data analysis and visualization
30 | through JRI and DSL(Like hiccup, honeysql) on Clojure,
31 | use Chrome to view data (format to HTML),
32 | and use the free image-viewer software to view plot.
33 |
34 | I prefer pure clojure hash-map to implement a model similar to Dataframe,
35 | which, by its characteristics, is more like a super Execl with spec and s expressions.
36 | Clojure manipulation Hash-map is very convenient, hash index performance is also very strong.
37 | Dataframe is similar to DB, It don’t have to keep the order, Therefore,
38 | It don’t need to use vector, just sort when you need it.
39 | I use “hash-map * hash-map” to map (metaphorically) semantically
40 | on demand as a database structure for NoSQL and RMDB.
41 |
42 | If you're having trouble modeling your data, you can refer to posgtresql how to do it.
43 | - Relational data model, recommended design as the 3NF (third normal form)
44 | - For non-critical information, for simplicity and flexibility,
45 | it can be designed as a hash-map (json) type in a small range.
46 | - Avoid deep nesting of data structures. Generally, the nesting depth is no more than 3 levels,
47 | and no more than 5 levels at most.
48 | - Recursive (or loop) operations can be avoided,
49 | and low nesting depth can be easily converted to single-level operations,
50 | especially hash-map is more convenient.
51 | - The data is readable and easy to display and debug.
52 | - See also: [Implement relational data model and programming based on hash-map (NoSQL)](./relational_model_on_hashmap.md)
53 |
54 | Finally, I think that RMDB is the most scientific, simplest
55 | and most reliable in theory and practice, and it has withstood the most rigorous,
56 | high-pressure, and long-term tests in various critical situations.
57 |
58 | # 一切都是RMDB
59 |
60 | 版权所有 © 2018 林鹏程， 保留所有权利。
61 |
62 | 我的开发思想：
63 |
64 | - 一切都是RMDB,
65 | - 发送SQL,
66 | - 获得结果(或副作用),
67 | - 在Clojure和RMDB之间打乒乓球。
68 |
69 | 我使用R语言通过Clojure上的JRI和DSL（如hiccup，honeysql）进行数据分析和可视化，
70 | 使用Chrome查看数据（格式化为HTML），并使用免费的看图软件查看数据可视化结果。
71 |
72 | 我更喜欢纯粹的clojure hash-map来实现类似于Dataframe的模型，
73 | 根据它的特性，它更像是带有spec和s表达式的超级Execl。
74 | Clojure操作Hash-map非常方便，哈希索引的表现也很强。
75 | Dataframe类似于DB，它不需要保持顺序，因此，它不需要使用向量，只需在需要时进行排序。
76 | 我使用“hash-map * hash-map”按需在语义上映射（隐喻）作为NoSQL和RMDB的数据库结构。
77 |
78 | 如果在数据建模时遇到麻烦, 可以参考posgtresql怎么做.
79 | - 关系数据模型，推荐设计为第三范式
80 | - 非关键信息，为简便灵活，小范围地使用的 hash-map(json),
81 | 如同pgsql一样，只可做调味，不可当饭吃。
82 | - 避免数据结构深度嵌套，一般嵌套深度不超过3层，最多不超过5层。
83 | - 可避免递归（或循环）操作，低嵌套深度可以很方便变换为单层深度的操作，特别是hash-map更方便。
84 | - 数据可读性强，方便显示和调试。
85 | - 另见: [在hash-map(NoSQL)的基础上实现关系式数据模型和编程](./relational_model_on_hashmap.md)
86 |
87 | 最后, 我认为RMDB在理论和实践中是最科学、最简单和最可靠的，
88 | 并且它在各种至关重要的关键场景中经受最严格的、高压力的、长期的考验。
89 |
--------------------------------------------------------------------------------
/doc/comment_complicated_pl.md:
--------------------------------------------------------------------------------
1 |
2 | # Don't try to solve all problems with programming languages
3 |
4 | -- Comment: [What's next for language design? (2017)](https://graydon2.dreamwidth.org/253769.html#cutid1)
5 |
6 | Copyright © 2021.11.22 Lin Pengcheng. All rights reserved.
7 |
8 | If programming language is a tool, there is no absolute security tool in this world,
9 | only scientific methods, architecture and systems are the guarantee of security.
10 |
11 | The reason why all the questions in this article are too complicated
12 | is because they try to solve all the problems in a programming language.
13 |
14 | If you use the correct programming paradigm and architecture, these problems are very simple.
15 | If the programming paradigm and architecture are wrong, you don't want to correct it,
16 | you just want to solve the resulting problem with a bunch of programming language complex features.
17 | If a programming language pursues such a goal, it must be too complex to use.
18 | This is a macro strategy and method is wrong, do not want to correct it,
19 | but just want to solve the problem with a variety of micro-tactical techniques,
20 | This results in painstaking but extremely ineffective results.
21 | It's like a building with the wrong architecture and construction methods,
22 | not only is it dangerous, but the hard - working remedies will not have good results. .
23 |
24 | In terms of common sense in management science, the entire development tool chain
25 | should also follow the principle of professional division of labor, otherwise things will be complicated.
26 |
27 | In my [`The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model`](https://github.com/linpengcheng/PurefunctionPipelineDataflow),
28 | it is based on mathematical model, operational research, and management science,
29 | these problems are very simple.
30 |
31 | - Data is centrally managed by the warehouse. they are simple such as access, verification, type, standardization, and etc.
32 |
33 | - The logic of each workshop is very simple, short, independent,
34 | They are simple & natural such as heterogeneous parallel, Coroutines, async/await, effect systems, module system, Errors, and etc.
35 |
36 | - Use the scheduler to achieve global optimization.
37 |
38 | Reference
39 |
40 | - [The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model](https://github.com/linpengcheng/PurefunctionPipelineDataflow)
41 |
42 | - [What's next for language design? (2017)](https://graydon2.dreamwidth.org/253769.html#cutid1)
43 |
44 | ----
45 |
46 | # 不要试图用编程语言解决所有问题
47 |
48 | -- 评: [What's next for language design? (2017)](https://graydon2.dreamwidth.org/253769.html#cutid1)
49 |
50 | 版权所有 © 2021.11.22 林鹏程， 保留所有权利。
51 |
52 | 如果说编程语言是一种工具, 这世界上没有绝对保证安全的工具,
53 | 只有科学的使用方法、架构和制度才是安全的保证.
54 |
55 | 该文章的所有问题之所以太复杂是因为试图用编程语言解决所有问题.
56 | 这是很多复杂的编程语言所犯的错误.
57 |
58 | 这些问题如果使用正确的编程范式和架构, 它就是一个很简单的问题.
59 | 如果编程范式和架构错了, 不去纠正, 而只想用一堆复杂的编程语言特性解决由此引发的问题，
60 | 如果一种编程语言追求实现这样的目标, 那它一定复杂得无法使用.
61 | 这属于宏观的战略和方法错了，不想着去纠正, 而只想以各种花样的微观的战术技术解决问题，
62 | 费尽心力, 效果惨淡。就象一座建筑, 架构和建筑方法错了, 不仅危险,而且再努力的补救措施也不会有好的结果.
63 |
64 | 用管理科学的常识来说, 就是整个开发工具链也要遵循专业分工原则, 否则就是自讨苦吃, 吃力不讨好, 事倍功半.
65 |
66 | 在我的[`基于数学的大统一编程理论：纯函数管道数据流和基于原则的仓库/车间模型`](https://github.com/linpengcheng/PurefunctionPipelineDataflow)里,
67 | 它基于数学模型、运筹学、管理科学, 这些问题非常简单.
68 |
69 | - 数据由仓库集中管理,存取,校验,类型和标准化等问题就简单了
70 |
71 | - 每个车间逻辑都非常简单, 短,独立. 异构并行、异步、协程和模块等是很简单和自然的
72 |
73 | - 使用调度器可以实现全局统一优化.
74 |
75 | 参考文献
76 |
77 | - [`基于数学的大统一编程理论：纯函数管道数据流和基于原则的仓库/车间模型`](https://github.com/linpengcheng/PurefunctionPipelineDataflow)
78 |
79 | - [What's next for language design? (2017)](https://graydon2.dreamwidth.org/253769.html#cutid1)
80 |
81 |
--------------------------------------------------------------------------------
/doc/Taoist_Simplicity_cn.md:
--------------------------------------------------------------------------------
1 | # “二代道祖----科学道祖”林鹏程评《简单是一种优势，但可悲的是复杂性卖得更好》
2 |
3 | 版权所有 © 2024.05.07 林鹏程， 保留所有权利。
4 |
5 | > 简单是一种伟大的美德，但它需要努力工作才能实现，需要接受教育才能欣赏它。更糟糕的是：复杂更好卖。
6 | >
7 | > ----Edsger Dijkstra
8 | >
9 | > 如果一个理论是基于数学, 并且符合“简单、统一、有序、对称和明确”五大科学、工业、艺术的基本原则(美学), 那它就是完美理论.
10 | >
11 | > ---- 林鹏程
12 |
13 | 我的理论因为太简单, 只运用了幼儿园和小学数学模型和一些基本常识, 导致人们常常低估了它的伟大意义!
14 |
15 | 我的理论以一个基于数学模型和大工业最佳实践的、简单的核心理论[《基于数学的大统一编程理论：纯函数管道数据流和基于原则的仓库/车间模型》](https://github.com/linpengcheng/PurefunctionPipelineDataflow) 为基础，颠覆了计算机科学、管理科学、WHO的国际疾病分类等多个行业的理论体系， 实现了这些行业理论体系的数学化和科学化，符合“简单、统一、有序、对称和明确” 五大科学与工业原则，做到了孔子所说的“吾道一以贯之”，完美演绎了道家“道法自然、 大道至简、万法归一”的思想，可谓“完美理论”，引起一众世界最顶尖的IT公司先后追随， 建立了学术界第一个以一个基础理论为核心的、跨行业的大统一学术理论帝国， 成为学术界始皇帝（文始皇），真的成就了“三不朽的圣人”。
16 |
17 | 如果说鸿钧道祖在上古神话时代首创了得道成圣之路，被称为“一代道祖----神话道祖”，在科学末法时代，这条路失效了。我创造的[《道家仙派科研方法学----成圣法》](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/ways_to_become_a_immortal.md)和道家科学派，为科学末法时代开创了一条简单、普适、高效、科学的成圣之路，可以称为“二代道祖----科学道祖”。
18 |
19 | 我的理论最基本的五个函数式管道数据流基本组件、仓库/车间模型概述、10原则、数学模型，最核心的美学、道、明心见性、知行合一、想像力（真正的智慧）变化法门，没什么人认真看，一扫而过，读者廖廖无几，后来我随手运用道家大神通“天罡地煞变”把仓库/车间模型千变万化应用到计算机软硬件的方方面面作为演示的例子，甚至到成为管理、经济、国际疾病分类、能源、军事等各行各业的核心模型，开创了一大堆科学流派，读者越来越多，一大群观众鼓掌叫好，很是热闹！
20 |
21 | 这场面大家是不是很熟悉，没错！《西游记》猴子表演“地煞72变”被开除的场面，菩提祖师睡午觉被吵醒，满满起床气，出门看到学习多年不开窍、只学了皮毛的猴子在耍猴戏，一堆不成器的门徒上课时不好好听讲学习真本事，皮毛功夫倒是真起劲，怒气值直接暴了，把这帮门徒轰散，再把猴子给开除了。幸好我是自觉成才，没有师父，也不是只学了皮毛的猴子，而是不朽圣人、学术界始皇帝（文始皇）、“二代道祖----科学道祖”。
22 |
23 | 历史总在不断地重演，时间变化，人性不变！神话时代如此，科学时代也如此！在学我的理论时，连最优秀的人类也不能例外，都犯了这个错误:
24 |
25 | - 计算机行业最高奖“图灵奖”得主、PostgreSQL创始人、数据库领域“祖师爷”Stonebraker设计DBOS时。[点击详细](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Comment_DBOS.md)
26 |
27 | - 号称世界上最顶级的芯片设计团队Apple M1 Ultra设计团队。[点击详细](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/SuccessStory.md#M1-Ultra-is-a-mistake)
28 |
29 | - 微软AI计算平台Singularity架构设计团队。[点击详细](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Follower_MS_Singularity_Architecture_en.md)
30 |
31 | - 谷歌微服务架构重构团队。[点击详细](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Comment_Google_anti-microservice.md)
32 |
33 | 我们要记住仙侠无脑爽文里最常见的一句话“万千神通皆小术，唯有智慧是大道”！可叹的是，不管是神话时代还是科学时代，人们都在追求各种花样的神通法门，对智慧法门弃之如敝履，对智慧的追求只停留在口头，因为神通是快餐预制菜，智慧则教你成为创造美食的厨神，点快餐预制菜的是绝大多数，为了美食努力成为厨神的万中无一！
34 |
35 | ----
36 |
37 | > 转载一篇相关的[趣文（节选）](https://blog.csdn.net/csdnsevenn/article/details/80014149)：
38 | >
39 | > 二流的软体工程师，喜欢把简单的问题弄的复杂，写出别人看不懂的程序。
40 | >
41 | > 一流的软体工程师，喜欢把复杂的问题简单化，写出架构清楚明白的程序，让人看了之后，觉得问题好像很简单。
42 | >
43 | > 三流的软体工程师会去崇拜二流的软体工程师，因为他们会觉得二流工程师写的程序都看不懂，一定是超级厉害；
44 | >
45 | > 三流的软体工程师不会去崇拜一流的软体工程师，因为他们会觉得一流工程师所做的事情都很好懂，好像都很简单。
46 | >
47 | > 只有一流的的软体工程师才会佩服一流的软体工程师，因为只有他们才能看的出来，其他的一流软体工程师厉害在哪里？
48 | >
49 | > 台湾的软体业如此，美国的软体业也大致如此。
50 |
51 | ----
52 |
53 | 相关链接:
54 |
55 | - [Simplicity is An Advantage but Sadly Complexity Sells Better](https://eugeneyan.com/writing/simplicity/)
56 |
57 | - [Hacker News的讨论](https://news.ycombinator.com/item?id=40266464)
58 |
59 | - [道家仙派科研方法学----成圣法：借假修真，破解大脑漏洞，开发大脑潜能，超越先天智商的限制，以达超凡入圣之境(林鹏程需求闭环理论模型，非立志成圣不可用)](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/ways_to_become_a_immortal.md)
60 |
61 | - [Apple M1 Ultra is a mistake](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/SuccessStory.md#M1-Ultra-is-a-mistake)
62 |
63 | - [Microsoft's AI computing platform Singularity's architecture has plagiarized my Warehouse/Workshop Model](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Follower_MS_Singularity_Architecture_en.md)
64 |
65 | - [一学就会，一用就废！评论DBOS：一个面向数据库的操作系统（兼论：如何预防应用我的理论时出现偏差呢?）—— 评《80岁Postgres创始人、数据库领域“祖师爷”想颠覆数据库设计：不推翻下当前技术，不足以谈人生》](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Comment_DBOS.md)
66 |
67 | - [评：微服务全做错了！谷歌提出新方法，成本直接降为1/9！](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Comment_Google_anti-microservice.md)
68 |
--------------------------------------------------------------------------------
/doc/TaoistScientificResearchMethodology.md:
--------------------------------------------------------------------------------
1 | # 开山立派四要件(附：道家仙派科研方法学预告)
2 |
3 | 版权所有 © 2023.03.10 林鹏程， 保留所有权利。
4 |
5 | ## 一、开山立派四要件
6 |
7 | 创始人要开山立派并发扬光大，必须做到如下事项：
8 |
9 | ### 1. 基础：创始人具有高尚的武德
10 |
11 | 创始人具有无敌的专业水平。创始人做人要仁义低调，但在专业领域是万万不可以低调。因为他就是这个流派的旗帜，不能倒。
12 |
13 | 孔子以仁立道，多么善良仁义的人啊，事关学术争议还常常要撸起袖子加油干，在民风彪悍的春秋战国，人高马大的山东大汉孔子也有干败仗的时候，毕竟只是个业余武术家，关键是脸青鼻肿的特毁大宗师的形象。史记记载，孔子第一次见到国际著名大剑师仲由（子路）时，子路“凌暴孔子”，想必是两人拳头上见分晓了，业余玩家遇上职业高手，毫无悬念，子路暴揍了孔子一顿，孔子觉得子路是个人才，是儒家护法双花红棍的最佳人选，“设礼，稍诱子路”，子路“后服”，孔子忽悠子路拜师后，沾沾自喜曰：“自吾得由，恶言不闻于耳。”意思是，自从收了子路为弟子后，我就没有听到什么坏话了。孔子讲课时有一个凶猛异常武功高强的国际著名大剑师拎着大宝剑站在旁边，自然没有人敢捣乱了。这和“枪杆子里出政权”、“真理就在大炮的射程之内”这类话有异曲同工之妙。后来，有汉武帝及其后历代王朝强力支持，独尊儒术，奠定了儒家的显学地位。
14 |
15 | 所以创始人找个能打的弟子很重要，如果找不到，只能自己上了，如王阳明，文人上战场，百战百胜，用武功证文德，成就千古圣人美名。他们都是文科生，“文无第一”，文科用口头笔头难以说服对手，证明自已的正确性和优越性，只能靠武德感化了。“武无第二”，理科如同武学，用数学就能明明白白地一较高下了！理科的成果都是自然规律，不会因为支持或喜欢的人多而增色，也不会因为反对或讨厌的人多而失色，不增不减，不灭不垢。文科靠武斗，理科用文攻。这世界真有趣。
16 |
17 | ### 2. 核心：科学的、领先的、创新的理论体系
18 |
19 | 科学的、领先的、创新的理论体系，并且具有简单、形象、生动的口号、名言和形象，让加入者感倍感荣耀的吸引力，让他们可以代表科学、真理、正义横扫一切 **`伪科学`**，正能量满溢到光芒万丈，紫气东来十万八千里，绕飞地球好几圈，这么一说，格局打开，逼格爆表。
20 |
21 | 以上两点，我创造的 **`“基于数学的大统一编程理论：纯函数管道数据流和基于原则的仓库/车间模型”`** 做到了，在科学主义数学专政的学术界，我的理论高举数学旗帜，以一个经典的小学数学模型为根基，不仅把数学真正引入IT软硬件理论体系（从核心的基础底层到高层全面覆盖）， 并且具备“简单、统一、有序、对称和明确”五大科学、工业与艺术美学基本原则，完美演绎道家道法自然、大道至简、万法归一的思想，实现了IT软硬件理论体系的全面数学化和科学化，这才是正宗的《计算机编程的艺术》，可谓完美理论。对上没有数学支持的现有的IT软硬件理论体系和管理学理论体系等这类 **伪科学**，降维打击，如摧枯拉朽，无一合之敌，不费吹灰之力就把他们平推了，这类 **伪科学** 用著名的理论物理学家泡利所说的“Not even wrong(连错误都算不上)”来形容切如其份。我的理论还继续四面开花，扩张到其他行业，创建跨行业的大统一学术理论帝国，成为学术界始皇帝。
22 |
23 | 我们常常发现每一个学科都会有"xxx(学科/科学)的艺术"或"xxx(学科/科学)之美"这种名字的书, 但是其实他们都从来没有提供科学的、可论证的、数学化的、可操作的评价标准，是否艺术，什么叫作美，有多美，全靠作者仗着他的地位和名声信口雌黄、铁口直断，完全称不上科学，只能是玄学，完全不可学习。所以科学、艺术、美学都无从谈起。
24 |
25 | 我的理论第一个完美地实现了这些要求，为科学艺术提了完整的评价标准和最佳范例，成为科学艺术的标杆和旗帜，所以我是 **"艺术科学派（或科学艺术派）"** 的创始人，那怕我画画水平只能画个小鸡啄米图哄哄幼儿园小朋友，唱歌五音不全，完全不着调，依然还是货真价实的一代艺术大宗师！因为我的艺术载体是科学！
26 |
27 | ### 3. 方法学
28 |
29 | 一个宗派能不能做强做大，不仅仅需要创始人有大成就，更需要让加入者也能获得大成就的方法学，这就是我即将发布的道家仙派科研方法学所要做的。
30 |
31 | ### 4. 利益生态圈
32 |
33 | #### 4.1. 科研学术界
34 |
35 | 我的理基于道家道法自然、大道至简、万法归一的思想，有广泛的跨行业的应用，我只做了最核心、最基础的论述，科研工作者有很多研究方向可以开展，可以申请很多项目。
36 |
37 | #### 4.2. 工业界
38 |
39 | 我的理论以经典数学模型为根基，具备简单、统一、有序、对称、确定五大科学与工业原则具有简单稳定、低成本高效率、灵活、标准，可线性扩展。最重要的是可以数学论证现有的软硬件项目需要改造和发展，企业有产品升级换代增长的发动机，工程师们有满满的KPI项目可以做，并用数学证明自己的优秀。
40 |
41 | 苹果M系列SOC芯片，虽然学习我的理论学得不好，但依然成为IT界最靓的仔。
42 |
43 | #### 4.3. 教育界
44 |
45 | ##### 4.3.1 大学
46 |
47 | 因为我的理论领先的科学性和跨多行业的特性，必然进入大学教育领域。毕竟在学术界的大本营，顽固地硬撑着继续教导现有的 IT **`伪科学`** 理论体系，场面实在不堪入目。
48 |
49 | ##### 4.3.2 小学
50 |
51 | 因为我的理论以经典的小学数学模型为根基， 具有简单性和广泛的适用性，作为理论基础和核心撑起了多行业理体系的重要性，它很适合出现在小学教材里，激发小朋友们的学习兴趣。
52 |
53 | 由于我的理论的基础性和核心地位，是学术界和工业界无法绕过的高山，必然成为从小学到大学，从科研学术界到工业界的绝对主流。
54 |
55 | ## 二、道家仙派科研方法学(预告)
56 |
57 | 道家仙派科研方法学，主要采用道家神话的想像力和创造力，及其通俗易懂接地气的优点，我是科学主义者，最不喜欢神棍和玄学，切勿理解错我的意思。主要包括两篇文章：
58 |
59 | - 一篇讲开发大脑潜能，这篇很危险，只做为科研参考用，或对陷入悟道疯魔期的人有经验启发和健康指导等方面的帮助。普通正常人不要学，等以后有人改良出更安全的版本再说。正如奥运冠军的训练方法，普通正常人练了容易导致五劳七伤，甚至猝死。
60 |
61 | - 一篇讲证道法，主要讲增长智慧的法门。
62 |
63 | 至于要说这个方法效果怎么样？我在四十岁之前，平平无奇，藉藉无名，没有优越的家世，没有高智商，没有高学历，没有贵人相助，没有什么经验，甚至在现实世界里与IT界和学术界毫无关系，也没有经历什么风风雨雨、大风大浪、吃苦耐劳，这类伟人或天才的历程一个都没有，只是躺平当咸鱼，放飞自我，释放想象力，胡搞几年之后，就忽然获得大成就。仅此而已。
64 |
65 | 我的研究过程在GitHub上全程公开，这在科研学术界是不可能的，因为担心泄密让对手抢先发表成果，我的理论很简单，这几年来不仅没人抢先出成果，神奇的是人们从始至终一直在反对它，冷嘲热讽的，甚至我用数学论证后，居然还有众多糊涂蛋还在反对，我倒是没生气，只是惊讶他们难道不知道他们已经泄了自己的老底了吗？反对的人不够多不够久，怎能衬托出我的英明神武、高瞻远瞩。
66 |
67 | 我的理论应该是世界上第一个全程公开研究过程的伟大理论，以后也很难再有了。和我的方法学互相参照，应该很有研究价值，因它不是什么伟人天才的伟大历程，只是一个普通凡人很平淡很简单又有些胡搞的研究过程，幸运的是我成功了，希望对其他象我一样爱鼓捣的平凡的普通人有所帮助。
68 |
69 | 创新的方法学或成功学，最重要的是创造者能不能做到，如果不能那只能徒增笑料而已，我只能不谦虚地说我做到了。
70 |
71 | ## 三、流派列表
72 |
73 | 写到最后，发现我创造的流派到底是什么还没写，我这几年创造了以下几个流派：
74 |
75 | 1. 计算机科学管理学派
76 | 2. 管理科学计算学派
77 | 3. 道家仙派科研方法学
78 | 4. 道家科学派（在学术界用数学和科学完美演绎道家思想）
79 | 5. 人工智能管理学派
80 | 6. WHO国际疾病分类数学与价值派
81 | 7. 艺术科学派（或科学艺术派）
82 |
83 | 以后还可能会增加，世人能有一个大创新或开创一个学派，已经是很了不起的大事了，我一下子划拉了一堆，很不真实、不严肃，象是在搞笑，可我的每一个流派主张都有充分的、坚不可摧的科学依据。当然如果要说是在搞笑也未尝不可，我以前写过一篇文章[《道即是易》](./Tao_of_Confucius_LaoTzu_Me.md)，道家崇尚变化，每一个变化都是一种创新，都有可能是一个流派，有的变化懒得写就忘记了，有的变化出现次数比较多, 活到想写的时侯, 于是顺手写写就出现了，没有谁会把生活中的事情和想法件件写下来，很累的，悟道者想象力丰富，想法多了就不值得稀奇。庄子曰，“道无所不在，在蝼蚁，在稊稗，在瓦甓，在屎溺。” 开山立派和顽童撒尿和泥没什么不同，玩玩而已，如果把科学太过神圣化，是不会有成就的，科研需要骚操作，科研不骚，成就不高。
84 |
--------------------------------------------------------------------------------
/doc/Comment_DBOS.md:
--------------------------------------------------------------------------------
1 | # 一学就会，一用就废！评论DBOS：一个面向数据库的操作系统（兼论：如何预防应用我的理论时出现偏差呢?）
2 | ———— 评《80岁Postgres创始人、数据库领域“祖师爷”想颠覆数据库设计：不推翻下当前技术，不足以谈人生》
3 |
4 | 版权所有 © 2023.12.27 林鹏程，保留所有权利。
5 | （2023.12.27首发于微博）
6 |
7 | 根据[DBOS的博客](https://dbos-project.github.io/),
8 | 他的第一篇论文[《TabulaROSA: Tabular Operating System Architecture for Massively Parallel Heterogeneous Compute Engines (HPEC 2018.09.25)》](https://ieeexplore.ieee.org/document/8547577)
9 | 和我的仓库/车间模型(2018)相差比较大.
10 |
11 | 第二篇论文[《DBOS: A Proposal for a Data-Centric Operating System (arXiv 2020.07.21)》](https://arxiv.org/abs/2007.11112)
12 | 和我的仓库/车间模型(2018)论述一致,我认为他应该是参考了我的理论.
13 |
14 | > Stonebraker 与 Zaharia 等人共同撰写的论文对此做出具体解释，“
15 | >
16 | > - 仓库: 所有操作系统状态都应统一表示为数据库表，
17 | > - 车间: 并应通过来自其他无状态任务的查询对该状态进行操作。
18 | >
19 | > 这样的设计能够让操作系统拥有更灵活的扩展和开发空间。无需对整个操作系统进行重构、
20 | > 无需检查和调度系统状态、也无需停机即可升级组件；
21 | >
22 | > - 调度器: 同时配合机器学习来管理决策，并实现复杂的安全功能。”
23 |
24 | 我认为他在调度器方面投机取巧了, 我的理论所用的动态树形甘特图基于运筹学,
25 | 实现起来比较困难但更高效.
26 |
27 | DBOS在抽象层使用仓库/车间模型, 但从他的2022.09.03的博客
28 | [《DBOS: A Database-Oriented Operating System》](https://dbos-project.github.io/blog/intro-blog.html)
29 | 上看, 他的实现偏离了仓库/车间模型及其原则, 究其原因,
30 | 应该是对仓库/车间模型理解不够透彻,
31 | 不自觉地滑向惯用的传统DB和OS系统构造方法.
32 |
33 | 上一个犯同样错误案例是Apple从抄作业的M1扩展到M1 Ultra所犯的错误!
34 |
35 | 为什么会有这种 **“一学就会，一用就废”** 的现象? 原因很简单，基础不牢固，
36 | 没有把最简单、最乏味的纯函数管道数据流的5个基本组件练成本能，形成正确的思维方式。
37 | 这就是俗话所说的：练拳不练功，到老一场空；看人挑担很轻松，自己挑担压断腰；一学就会，一用就废！
38 |
39 | 如何预防应用我的理论时出现偏差呢?
40 | 我的理论简单统一，浑然一体,由下面七个部份组成：
41 |
42 | 1. 数学原型: 简单经典的"水池进/排水"模型
43 | 2. 编程: 纯函数管道数据流, 5个基本的纯函数管道数据流组件
44 | 3. 架构: 仓库/车间模型
45 | 4. 原则: 基于原则的方法学, 10个原则
46 | 5. 质控: 简单的山峦图或等高线图、纯函数比例
47 | 6. 美学: 简单、统一、有序、对称、明确
48 | 7. 道家仙派科研方法学
49 |
50 | 本理论的每个组成部分都完美地应用和演示了其他组成部分， 是一个实用的、完整的、系统的理论体系。
51 | 把工作成果与这七个部份互相印证, 可以预防出现偏差!
52 |
53 | 我认为他应该再努力理解我的理论, 主要多阅读下面的文章:
54 |
55 | - 2018.03.18, [The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model](https://github.com/linpengcheng/PurefunctionPipelineDataflow)
56 |
57 | - 2021.11.15, [OS kernel as Hardware: The future OS kernel will be a data-oriented scheduler (with Computer hardware and software integration architecture diagram)](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/OS_as_DB_en.md)
58 |
59 | - 2021.07.28, [Why my "warehouse/workshop model" can achieve high performance and low power consumption (take Apple M1 chip, Intel AVX-512, Qualcomm as examples)](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/why_wwmodel_fast_en.md)
60 |
61 | - [Microsoft's AI computing platform Singularity's architecture has plagiarized my Warehouse/Workshop Model](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Follower_MS_Singularity_Architecture_en.md)
62 |
63 | - [Apple M1 Ultra is a mistake](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/SuccessStory.md#M1-Ultra-is-a-mistake)
64 |
65 | - [Traditional IT theory (OO, FP and hardware architecture, etc.) VS. Warehouse/Workshop Model](https://github.com/linpengcheng/PurefunctionPipelineDataflow#Traditional-OO-and-FP-architecture-VS-Warehouse-Workshop-Model)
66 |
67 | - [Success Story](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/SuccessStory.md)
68 |
69 | ```
70 | Traditional IT theory (OO, FP and hardware architecture, etc.)
71 | are pseudoscience. they belong to what physicist Wolfgang
72 | Pauli said "Not Even Wrong".
73 |
74 | It is the perfect theory if a theory is based on mathematics
75 | and meets the five basic principles of "Simplicity, Unity,
76 | Order, Symmetry and Definiteness" in science, industry
77 | and aesthetics.
78 |
79 | Keep it Simple and Unified.
80 |
81 | Computer science is essentially a management science,
82 | and vice versa.
83 |
84 | Software and hardware are factories that manufacture data,
85 | so they have the same "warehouse/workshop model" and
86 | management methods as the manufacturing industry.
87 |
88 | ---- Lin Pengcheng
89 | ```
90 |
--------------------------------------------------------------------------------
/doc/estimated_100k_high_level_followers.md:
--------------------------------------------------------------------------------
1 | # 我的理论估计全世界有10万个高水平的关注者（兼论：最权威的同行评审）
2 |
3 | 版权所有 © 2023.12.06 林鹏程， 保留所有权利。
4 |
5 | 最近，我发现我2023.05.18发的微博《奇怪! 为什么看我的理论的技术微博象是在看禁书? 偷偷摸摸的, 欲摆不能!》
6 | 有3.4万个阅读者，结合github博客的阅读量和clone量的历史记录、
7 | 地理分布遍及除南极洲和海洋外的全球每一个角落的关注者，估计我的理论的关注者大约有10万个。
8 |
9 | 看来，不仅我对这么多隐身的关注者很惊讶，隐身的关注者本身也很惊讶，
10 | 我的微博一年没发几条微博，内容也很单一地讲我的理论，关注者一年半载来看一次就够了，
11 | 所以，这半年时间陆陆续续来的隐身的关注者都惊讶地点进去看看，
12 | 结果这个贴子就成了隐身的关注者的报到贴。
13 |
14 | 为什么说我的理论的关注者是高水平的，因为：
15 |
16 | 1. 专业兴趣相同的人，水平一般比较接近，虽然隐身的关注者水平无法直接评估，
17 | 但可以根据github公开的关注者的水平来推断，世界名校的学生、毕业生、教授、
18 | 名企的技术专家、著名研究机构的研究人员、著名开源项目的作者和主力开发人员很多，
19 | 说明这个群体的专业水平很高，还有很多创造不少开源项目和专业博客文章的人，
20 | 能够持续投入精力从事开源项目和专业博客文章的人水平一般都是优秀的。
21 |
22 | 2. 中低水平的人一般不会持续关注我的理论，因为我的理论主要是一种系统方法学和一种创新方法，
23 | 而中低水平的人并不关注系统方法学，他们更多地关注具体的编程技术。
24 | 他们不关注创新的方法，更多地关注工作所需的主流的技术方法。
25 |
26 | 中低水平的人仍然可以从我的理论中获益，他们只需要简单看完我的5个基本纯函数管道数据流构件
27 | 和简单的仓库/车间模型知识就可以了，然后在尽可能多地应用它，就能很快提高编程技术、代码质量，
28 | 很快成为高水平的编程专家和系统专家，并不用象传统的西方专业化科学那样专门地去学习构造系统的知识。
29 | 我的理论就有这种功到自然成的能力，因为纯函数管道数据流的写法可以很自然地
30 | 培养使用者业务流程（优化）再造的能力，自底向上地学会系统构造的方法。另外我的理论基于管理学，
31 | 使用者同时也学会了扎实的分工、组织、调度等管理学基本功，为成为优秀的技术管理者打下坚实的基础。
32 |
33 | 3. 高水平的人员更关注系统方面的理论，因为他们的工作需要关注这方面的内容，
34 | 他们关注我的理论在系统方面新的发展和应用，
35 | 同时，他们也关注本行业理论体系的科学化和数学化。
36 |
37 | 4. 科研人员则更关注创新的方法，以开拓思维，寻找创新灵感。
38 |
39 | 5. 企业高层和创业者则想寻找商机。我发现每当我修改github后,立刻就有几个clone下载，
40 | 即使我只修改个空格或标点也是如此。我认为一般个人关注者不会这么无聊，
41 | 最多先看看提交记录，看看有兴趣的记录就可以了，
42 | 小企业也不会费这么大的劲做这么没必要的事，
43 | 大体上只有那种超大型的公司才会指定专人来做这么细致的事。
44 |
45 | ---------------
46 |
47 | 附：兼论：最权威的同行评审
48 |
49 | 很多人认为我的理论没有正式发表在论文期刊上，认为缺乏同行评审，不予认可，
50 | 而且，很多人具有高学历。我很奇怪，他们读到这么高的学历，
51 | 难道自已没有一点独立的专业判断能力，要靠他人帮忙判断，这是巨婴。
52 | 每个人都应学会积极主动地应用自己的大脑。
53 |
54 | 这世界上最权威的同行评审是用真金白银来投票的，
55 | 当业内所有的公司投入亿万元资金用你的理论开发产品，
56 | 并获得丰厚的回报，这就是最权威的同行评审。
57 |
58 | 相比之下，现有的论文期刊同行评审不值一提，
59 | 因为它不需要评审人投入真金白银，这就是为什么现在论文90%以上是垃圾的原因，
60 | 这完全只是一门赚钱的生意而已，用那罕见的优秀论文来当遮羞布而已，
61 | 让所有人都产生和真正的科学家同列的错觉。
62 |
63 | 我的理论现在在IT业内有广泛的应用：
64 |
65 | 1. 我的理论仓库/车间模型在硬件领域的应用取得绝对的胜利
66 |
67 | - Apple的M系列SoC
68 |
69 | - 高通2023.10推出骁龙 X Elite 处理器对标Apple的M系列SoC
70 |
71 | - 所有有手机CPU由于体积、功耗、发热、制程等方面的原因，
72 | 没有集成内存，不是标准的的仓库/车间模型，
73 | 但仍然是它的一个变种，使用它的理论。
74 |
75 | 2. 我的理论在操作系统领域正在秘密发展
76 |
77 | - Apple开发了M系列SoC及其变种手机芯片, 必然在OS领域也采用我的理论，
78 | Apple的OS内核是基于微内核，要改造成仓库/车间模型比较容易，
79 | 但Apple在OS开发领域口碑一般，也没有什么公开资料，我不能判断它的进度。
80 |
81 | - 微软AI计算平台Singularity的架构采用我的仓库/车间模型，
82 | 但它的调度器使用FPGA(现场可编程门阵列)，说明它的调度器算法还不成熟，
83 | 用FPGA方便修改、打补丁，什么时候用我理论所说的ASIC, 说明它的算法成熟了，
84 | 这一点也适合Apple的MacOS和微软的Windows，
85 | 即什么时侯运行它们的硬件处理器集成了个调度器ASIC作为OS内核，
86 | 就是它们开始进入成熟稳定阶段的标志。
87 |
88 | 另外，我在2021.06.29发的微博指出: 微软Windows 11的DirectStorage技术
89 | 使系统更加向“仓库/车间模型”演进，CPU和GPU更加向独立不交互的车间定义演进，
90 | 更加以内存（仓库）为中心。再加上神秘的新调度器，铺天盖地的Windows11宣传，
91 | 往往只描述外在的UI和功能，但最重要的系统发动机----调度器，
92 | 却只在Intel即将推出的大小核CPU宣传中一笔带过，专为支持Intel新的大小核CPU开发,
93 | 我认为Windows11新调度器和Intel新的大小核CPU都是
94 | 在类似Apple M1的“仓库/车间模型”演进中的过渡产品。
95 |
96 | 另外，高通2023.10推出对标Apple的M系列SoC的骁龙 X Elite 处理器后，
97 | 高通和微软有密切的合作关系，骁龙 X Elite 处理器的主要操作系统必然是Windows,
98 | 这必然产生两个重要的影响:
99 | - Windows必然走向更科学的仓库/车间模型, 摆脱x86的限制.
100 | - 正如我以前文章讲过的, 这对Intel和AMD产生极大的压力,
101 | Intel和AMD没有把握住这段空窗时期, 留给Intel和AMD的时间不多了.
102 |
103 | 可见微软在OS上秘密研发应用我的仓库/车间模型。
104 |
105 | 3. 在AI领域的应用
106 |
107 | 特斯拉不仅用我的理论在AI方面的论述改进汽车自动驾驶的AI算法，
108 | 并且用来把关联企业（马斯克控制的）下产品特斯拉、SpaceX、Neuralink等整合在一起，
109 | 意图构造我所设计的**海陆空天全知全能“马斯克号”变形金刚**。
110 |
111 | 4. 我的理论在编程语言领域正在被研究
112 |
113 | 我的理论把一个已死亡的化石级编程语言，已经没人提没人用的Foxpro排名从五十多名提升到二十多名，
114 | 持续几年了。说明编程语言领域很多人在研究我的理论。
115 |
116 | 5. 应用领域
117 |
118 | 我估计有10万高水平的关注者，他们应该有相当大一部分人开始尝试应用我的理论。
119 |
120 | ----------
121 |
122 | 综上，任何一个行业的人才结构都是金字塔结构，我的理论有约10万个高水平的关注者，
123 | 并且在业内有广泛的应用，我说过我的理论将自底向上，
124 | 从最底层的硬件到最上层的应用软件领域逐层征服IT界，它正在稳步实现，
125 | 其实, 从我取得硬件领域的绝对胜利, 就大局已定了, 在其他上层的胜利只是时间上的问题而已.
126 | 说明我的理论已经不再是小众理论，已经是大洋表面底下的暗流，
127 | 海面风平浪静，底下的激流汹涌、沛然莫挡。
128 |
--------------------------------------------------------------------------------
/doc/OS_as_DB_cn.md:
--------------------------------------------------------------------------------
1 | # 未来的OS内核将是一个面向数据的调度器（带有计算机硬件和软件集成架构图）
2 |
3 | ---- 未来OS将是一个类似DB的ASIC系统, Clojure则是最好的DML
4 |
5 | 版权所有 © 2021.11.15 林鹏程， 保留所有权利。
6 |
7 | 在未来, OS将面临如下挑战:
8 |
9 | - 采用仓库/车间模型的做为硬件架构的计算机越来越多, 从SOC到超级计算机，从单机到云计算， 需要支持数量和种类都非常众多的计算单元（如CPU, GPU, ASIC等）。
10 |
11 | - 在物联网时代，计算机将要连接越来越多硬件.
12 |
13 | - 海量的应用程序
14 |
15 | 这种发展趋势, 需要对 OS 的算法进行改进:
16 |
17 | - 如果一个工厂(计算机系统)只有一个车间(CPU), 那么, 由车间(CPU)自行管理原料(数据)更高效.
18 |
19 | - 如果一个工厂(计算机系统)有非常多个且不同种类的车间(CPU,GPU, ASICs, 应用程序, 服务程序),
20 | 那么,由一个专门的管理部门(仓库, 数据库)管理原料(数据)更为简单和高效, 这种方法可以更简单地进行异构并行计算,
21 | 更方便调度器进行全局优化, 更高效地进行数据交换, 提高总体资源效率, 获得的效益超过了所增加的数据管理成本.
22 |
23 | OS应该发展成什么模样才能适应这种新的理论和新的计算机架构的发展潮流?
24 | 它必需采用如下仓库/车间模型:
25 |
26 | - 仓库
27 |
28 | - 内存: 存储数据, 各种资源的控制信息.
29 |
30 | - OS: 调度器,内存管理, 相当于DB引挚.
31 |
32 | - 目前,用CPU引导进入OS, 然后OS获得全面调度能力(包括CPU), OS的调度能力需要CPU执行.
33 |
34 | - 未来, 如果能有一个ASIC取代CPU去配合OS会更好, 因为这个车间高频使用和重要, 已经有必要成为一个独立的内部(集成)车间.
35 | 该 ASIC 主要负责调度和内存管理(OS内核也只有这些功能)，所有内部(集成)车间会都与内存直接连接。车间彼此独立, 不互相连接。
36 | 不重要，很少使用，缓慢的外部车间可以使用总线。但是，车间仍不应相互连接。
37 |
38 | - DML: 只要让Clojure集成JDBC和SQL，让所有核心API原生支持JDBC和OSDB, 就可以立刻成为最好的DML.
39 | - 在应用层和脚本层，Clojure 或 Babashka 足够了。
40 | - 在系统层，如果需要，为一种编程语言实现原生编译器根本不是问题。此外，JVM 还拥有 GraalVM 来支持原生编译。
41 | - [Jank](https://github.com/jank-lang/jank)：在 LLVM 上托管的本地 Clojure 方言
42 | - [ClojuRust](https://github.com/clojurust/clojurust)：Clojure 有一个 Rust 实现
43 |
44 | - 车间
45 | - 硬件: CPU，GPU, ASIC, 各种外设等
46 | - 软件: 各种应用程序, 服务程序
47 |
48 | 备注
49 |
50 | - 车间之间的互连太过复杂和混乱.我以前写[一篇文章批评过这类技术(AMD Infinity Fabric Architecture)](./Intel_RISC_V.md).
51 | 从AMD的文章的示意图中，AMD以Infinity Fabric总线为中心， 实现CPU-CPU之间的任务转移，
52 | 未来打算实现GPU-GPU，CPU-GPU之间的任务转移， 即车间之间的互联，我在制造工业内，还未见到过这种车间任意互联的架构。
53 | 这是个网状结构，非常混乱和复杂，扩展性差，灵活性差，数据利用效率差。
54 | 我认为它在同类处理器之间的任务转移相对容易， 在不同类处理器之间的任务转移是复杂和困难的，效果也不会太好。
55 | 我认为它远远不如我的仓库/车间模型简单、可靠、灵活、扩展性强， 以仓库（数据）为中心，数据存取效率高，
56 | 大致类似我以前发的[微软数据工厂/管道架构和仓库/车间模型的比较](./diff_WWModel_AzureDataFactoryPipe_cn.md)
57 | 实际上,尽管Apple M1尚未完全实现仓库/车间模型，但它已经是第一名了。
58 |
59 | - 在[为什么我的"仓库/车间模型"能做到高性能低功耗(以Apple, Intel, 高通为例)](./why_wwmodel_fast.md)中,
60 | "仓库/车间模型"源自制造工业的大工业生产,最适合大批大量高负载的大规模异构并行计算场景.
61 | 虽然当它应用在 Apple M1 芯片时, M1 不仅成为世界上最快的芯片,而且保持极低的功耗.
62 | 但实际上它的最佳应用场景是超级计算机或云计算, Apple M1 芯片的小身板不能发挥出它的优越性,
63 | 只是开席前的小菜一碟。
64 |
65 | 为什么"仓库/车间模型"能做到高性能低功耗呢?这就是在大工业规模生产和任务分工的优点在计算机领域的展现.
66 | 另外以仓库为中心，数据存取和交换性能高. 统一调度，全局统筹优化效果好。
67 |
68 | 如果一项任务独立作为一个车间后, 它产生的规模效益超过开设它的成本, 那么应该把它设立为一个车间,
69 | 注意: 在超过一定生产规模(计算量),专业车间的生产成本(功耗)较低且生产效率(性能)更高.
70 |
71 | 对于计算机SOC芯片，它的空间很有限，不象软件项目那样增加车间的成本很低，
72 | 很有必要把车间分为内部（集成）车间和外部车间，只要所增加的专用核心（ASIC,专业车间）足够常用,
73 | 产生的整体效益超过把这部分空间用来做通用核心(CPU,通用车间)的效益时, 可以把该专用核心（ASIC,专业车间）加入SOC芯片，
74 | 成为内部车间. ASIC具有体积更小、功耗更低、可靠性更高、性能更高、保密性更强、成本更低等优点。
75 |
76 | - Apple M1 统一内存架构（发布于 2020 年 11 月 11 日）就是我的"仓库/车间模型"（硬件架构部分发布于 2019 年 2 月 6 日），
77 | 它是一个由数学模型支持的架构，与传统的、数学模型支持的"冯·诺伊曼架构"不同。
78 |
79 | 参考
80 |
81 | - [一个在reddit的r/programming的很精彩的讨论](https://www.reddit.com/r/programming/comments/quk3xq/in_the_future_os_will_be_a_db_and_clojure_will_be/)
82 |
83 | - [基于数学的大统一编程理论：纯函数管道数据流和基于原则的仓库/车间模型](https://github.com/linpengcheng/PurefunctionPipelineDataflow)
84 |
85 | 它的数学原型是简单的、经典的、在社会生产实践中广泛应用的小学数学的“水池进排水问题”，
86 | 它以简单和统一的方式完美地、全面地把计算机理论与数学关联在一起:
87 | 从硬件集成电路和计算机架构, 到软件编程方法学、架构、编程语言等.
88 | 解决了IT业从诞生至今一直存在的根基科学性的根本问题----核心缺乏数学依据。
89 |
90 | - [在hash-map(NoSQL)的基础上实现关系式数据模型和编程](./relational_model_on_hashmap.md)
91 |
92 | - [一切都是RMDB](./Everything_is_RMDB.md)
93 |
94 | - [Clojure是基于关系式数据库理论的函数式编程语言](./Clojure_is_FP_based_on_RMDB.md)
95 |
96 | - [Foxpro面向数据库的编程范式是未来编程语言的发展方向(2021.11.07)](./Mummy4Foxpro.md)
97 |
98 | - [为什么我的"仓库/车间模型"能做到高性能低功耗(以Apple, Intel, 高通为例)](./why_wwmodel_fast.md)
99 |
100 | - [仓库/车间模型和微软Azure数据工厂/数据管道架构的区别](./diff_WWModel_AzureDataFactoryPipe.md)
101 |
102 | - [评论: Intel, RISC-V, and AMD Infinity Fabric Architecture](./Intel_RISC_V.md)
103 |
104 | 
105 |
106 |
--------------------------------------------------------------------------------
/doc/hybrid_AI.md:
--------------------------------------------------------------------------------
1 | # AI must use hybrid technology (Take Tesla Autopilot as an example)
2 |
3 | Copyright © 2021.10.12 Lin Pengcheng. All rights reserved.
4 |
5 | I believe It is wrong that Tesla’s autopilot technology insists on using only visual technology
6 | and not using radar and other technologies at the same time.
7 |
8 | They are the most important way to improve AI:
9 | 1. the mutual verification of different information sources.
10 | Human intelligence is to integrate multiple sources of information to make decisions.
11 | This is common sense.
12 | 2. the discovery and processing of contradictory information.
13 | 3. Each technology has its advantages and limits.
14 | When it is developed to a certain level,
15 | the marginal cost of continuing to improve the level of a single technology is very high,
16 | and the complementary advantages of multiple technologies are cost-effective.
17 |
18 | Tesla only uses visual technology. Although it is currently leading,
19 | but I believe that this is a narrow path. In order to save a little cost at the moment,
20 | it is taking the wrong path in the general direction.
21 |
22 | [My explainable AI framework](https://github.com/linpengcheng/PurefunctionPipelineDataflow#The-unification-with-classic-AI-and-modern-AI-and-explainable-AI-technology)
23 | based on `legal models` and `warehouse/workshop models based on management principles`
24 | is best at organizing and coordinating multiple hybrid technologies to solve problems in the best way.
25 | Because the legal sciences are good at solving differences and contradictions,
26 | the management sciences are good at organizing and coordinating,
27 | complementing each other's strengths, and cooperating to complete tasks.
28 | It is similar to the heterogeneous parallel computing of the computer,
29 | and this is the gifted magical power of the warehouse/workshop model.
30 |
31 | Postscript:
32 |
33 | After Apple, Intel, Microsoft, ARM and others, Tesla is following my theory.
34 |
35 | Reference:
36 |
37 | - 2022.12.12, www.forbes.com, [Tesla may be adding a radar which is the crutch they definitely need](https://www.forbes.com/sites/bradtempleton/2022/12/12/tesla-may-be-adding-a-radar-which-is-the-crutch-they-definitely-need/)
38 |
39 | - 2022.12.12, techcrunch.com, [Tesla appears to be turning back to radar for its vehicles](https://techcrunch.com/2022/12/07/tesla-appears-to-be-turning-back-to-radar-for-its-vehicles/)
40 |
41 | - 2022.12.06, electrek.co, [Tesla radar car next month self driving suite concerns](https://electrek.co/2022/12/06/tesla-radar-car-next-month-self-driving-suite-concerns/)
42 |
43 | - 2022.12.13, 核子可乐, Tina, InfoQ新闻, [《放出狠话又自打脸，特斯拉将重新在车辆上安装雷达，最快下个月发布》](https://www.infoq.cn/article/SINxMyTD46V2NRNMm84q)
44 |
45 | # AI也要兼听则明（以特斯拉自动驾驶为例）
46 |
47 | 版权所有 © 2021.10.12 林鹏程， 保留所有权利。
48 |
49 | 我认为特斯拉的自动驾驶技术坚持只用视觉技术,没有同时使用雷达等技术的方法是错误的.
50 |
51 | 改善AI的最重要的途径:
52 | 1. 不同信息来源的互参互证, 人类智能就是融合多种信息来源进行决策, 这是常识.
53 | 2. 矛盾信息的发现和处理.
54 | 3. 每种技术都有其优势和极限, 发展到一定水平, 继续提高单项技术水平的边际成本很高, 多种技术优势互补才符合成本效益原则.
55 |
56 | 特斯拉只使用视觉技术, 虽然目前暂时领先, 可偏听偏信这是路子是走窄了, 为了当下节约一点成本，在大方向上走错路了.
57 |
58 | 我的[基于法律模型和基于管理原则的仓库/车间模型的可解释AI框架](https://github.com/linpengcheng/PurefunctionPipelineDataflow#The-unification-with-classic-AI-and-modern-AI-and-explainable-AI-technology)，
59 | 最善长组织和协调多种混合技术以最优方法解决问题。
60 | 因为法学善长解决分岐和矛盾, 管理科学最善长组织协调, 优势互补, 合作完成任务。
61 | 它类似于计算机的异构并行计算, 它是仓库/车间模型的天赋神通.
62 |
63 | 后记:
64 |
65 | 言出法随，继＂苹果，Intel, 微软，ARM＂等公司之后，＂特斯拉＂追随我的理论.
66 |
67 | 2022.12.13, InfoQ新闻, 《放出狠话又自打脸，特斯拉将重新在车辆上安装雷达，最快下个月发布》.
68 |
69 | 参考文献:
70 |
71 | - 2022.12.13, 核子可乐, Tina, InfoQ新闻, [《放出狠话又自打脸，特斯拉将重新在车辆上安装雷达，最快下个月发布》](https://www.infoq.cn/article/SINxMyTD46V2NRNMm84q)
72 |
73 | - 2022.12.12, www.forbes.com, [Tesla may be adding a radar which is the crutch they definitely need](https://www.forbes.com/sites/bradtempleton/2022/12/12/tesla-may-be-adding-a-radar-which-is-the-crutch-they-definitely-need/)
74 |
75 | - 2022.12.12, techcrunch.com, [Tesla appears to be turning back to radar for its vehicles](https://techcrunch.com/2022/12/07/tesla-appears-to-be-turning-back-to-radar-for-its-vehicles/)
76 |
77 | - 2022.12.06, electrek.co, [Tesla radar car next month self driving suite concerns](https://electrek.co/2022/12/06/tesla-radar-car-next-month-self-driving-suite-concerns/)
78 |
79 |
--------------------------------------------------------------------------------
/doc/diff_WWModel_AzureDataFactoryPipe.md:
--------------------------------------------------------------------------------
1 | # Defects and improvement measures of Microsoft `Azure DataFactory/DataPipelines Architecture` ---- The difference between `Warehouse/Workshop Model` and Microsoft `Azure DataFactory/DataPipelines Architecture`
2 |
3 | Copyright © 2021-04-27 Lin Pengcheng. All rights reserved.
4 |
5 | | Microsoft Azure DataFactory/DataPipelines Architecture | 8 |Warehouse/Workshop Model | 9 |
|
12 |  |
13 |
55 |
56 | ### 参考文献
57 |
58 | [类比(百度百科)](https://baike.baidu.com/item/%E7%B1%BB%E6%AF%94/8046866)
59 |
60 | > 所谓类比，就是由两个对象的某些相同或相似的性质，推断它们在其他性质上也有可能相同或相似的一种推理形式。
61 | > 类比是一种主观的不充分的似真推理，因此，要确认其猜想的正确性，还须经过严格的逻辑论证。
62 | >
63 | > 自然科学的发展愈来愈要求使用定性类比和定量类比相结合的方法。一般说来，定性类比是定量类此的前提和条件，
64 | > 定量类比则是定性类比的发展和提高，科学发展首先是和定性研究分不开的，一个很有成效的定性研究，
65 | > 往往能够为科学的进一步发展指出方向，而后又要进行定量研究，才谈得上达到了精确的规律性认识。
66 | >
67 | > 由于类比是不同于演绎或归纳的一种独特的推论方法，因此它可以在归纳和演绎无能为力的地方发挥其特有的效能。
68 | > 为什么这么说呢？这是因为归纳、演绎和类比虽然都是推论的方法，都是从已知的前提推出结论，
69 | > 而且结论都要在不同程度上受到前提的制约。但是，结论受前提制约的程度是不同的，
70 | > 其中演绎的结论受到前提的制约最大，归纳的结论受到前提的限制次之，而类比的结论受到前提的限制最小，
71 | > 因此类比在科学探索中发挥的作用最大。
72 | >
73 | > 在科学发展的前沿阵地，由于探索性强，资料奇缺，类比的应用尤其重要。
74 | > 例如1963年盖尔曼和茨威格分别独立地引入夸克作为组成基本粒子的单元。他们指出，
75 | > 基本粒子的运动规律可以用三种不同的夸克的简单运动和相互作用来说明。由于夸克假说能对新的观察事实作出正确的预言，
76 | > 并能用一个简单统一的概念体系来描述丰富多彩的基本粒子，因而夸克学说具有根强的解释力，夸克却始终未被单独探测到，
77 | > 究竟能否观察到单独的夸克呢?对于这样一个基本问题，基本粒子物理学应该怎样研究呢？
78 | > 根据夸克理论模型，夸克的组合方式有两种：一种是由三个夸克和三个反夸克—起组成重子，
79 | > 另一种是由一个夸克和一个反夸克组成介子。如果这些重子或介子族粒中有一个在一次核碰撞中被击碎，
80 | > 就会形成新的粒子，但每个新粒子也仍然只能采取原有的多种夸克组成方式，即含有或者三个夸克和三个反夺克，
81 | > 或一个夸克和一个反夸克，而不会出现一个单个的夸克或反夸克碎片。高能物理学家注意到夸克的这种性质类似于磁性物质，
82 | > 因为磁铁总是具有一个N极和S极，当我们把—个条形磁铁分为两截时，也不会出现孤立的N极或S极，
83 | > 而成为各自有N和S极的两块磁铁，这正和介子碎片分裂时的情形完全类似。这些物理学家就将夸克与磁极进行类比，
84 | > 把夸克理论引向了一个新的起点。因为磁体两极的不可分性的根本原因在于磁铁的磁性是原子内部电子的圆周运动产生的，
85 | > 磁铁的S、N极并不是组成磁铁的“基本单元”，还有更深刻的“基本结构”——原子电流的外在形态。
86 | > 既然夸克和磁铁类似，那么是否夸克也有一个未知的“基本结构”?夸克具有内在的类似于“原子电流’的基本结构，
87 | > 这是通过类比得到的一个预测，就是这个预测开辟了一条建立夸克基本理论的新途径。
88 | > 虽然如今还不知道相应于夸克的“基本结构”是什么，但这种预测，对于以后物理学的研究是有重大作用的。
89 | >
90 | > 类比还常常被用于解释新的理论和定义，它具有助发现作用，当—新理论刚提出之时，
91 | > 必须通过类比用人们已熟悉的理论去说明新提出的理论和定义，这就是类比助发现作用的表现。
92 | > 比如，在气体运动论中，将气体分子与一大群粒子进行了类比。假定粒子服从牛顿定律并发生碰撞而没有能量损失。
93 | > 这种类比在关于气体行为的理论的历史发展中起了重要的作用。上例表明，
94 | > 新提出的理论必须与别的已知理论进行类比，它才能得以解释。在科学发现中，类比的这种助发现作用是不可忽视的。
95 | >
96 | > 类比与模拟实验也有密切关系。所谓模拟实验就是在客观条件受限制而不能直接考察被研究对象时，
97 | > 就依据类比而采用间接的模拟实验进行研究。例如，地球上的生命是怎样起源的，这一直是科学家们不解的一个谜，
98 | > 因为生命起源的原始状态已是时过境迁，无法直接考察了。1950年代初，米勒通过类比设计了—个生命起源的模拟实验。
99 | > 他在一个密封的容器里，加上了氢、氧、碳、氮等元素和甲烷、水，又模拟了风、雨、雷、电等原始大气环境。
100 | > 这样过了一个星期后，在容器里发现已形成了苷氨酸、甲氨酸等氨基酸。以后，别人用紫外线作能源，也得到了氨基酸。
101 | > 1963年，波南·佩鲁马用电子束也做了同米勒相同的实验，形成了腺嘌呤核苷，为揭开生命起源的奥秘迈进了一大步。
102 | > 这些研究成果的取得，充分显示了在科学发现中以类比为逻辑基础的模拟实验的重要作用。
103 | >
104 | > 类比在科学实验中的作用，还表现于它是设计新的实验工具的逻辑方法。比如说，
105 | > 威尔逊发明观察基本粒子轨迹的云室（他由于这项发明而获得1927年的诺贝尔奖），
106 | > 格拉塞发明同样用途阿尔瓦雷斯液态氢浴盆等，它们的最初设计都是来自通过类比推理而得到的某种启发。
107 | >
108 | > -------
109 | >
110 | > 为了使类比在科学发现中发挥有效的作用，人们进行类比推理时应当注意以下的原则：
111 | >
112 | > 第一，类比所根据的相似属性越多，类比的应用也就越为有效。这是因为两个对象的相同属性越多，
113 | > 意味着它们在自然领域（属种系统）中的地位也是较为接近的。这样去推测其他的属性相似也就有较大的可能是合乎实际的。
114 | > 例如十七世纪惠更斯的波动说，是通过光与声音进行类比提出来的。当时发现声音有直线传播、反射、折射等现象，
115 | > 同时又有波动性，光也有直线传播、反射、折射等现象。于是推出，光也有波动性。由于当时惠更斯没有注意到光的干涉现象，
116 | > 加之其他原因，使得光的波动说一度受到了冷落。到了十九世纪，英国的托马斯·扬，进一步将光和声音进行类比，
117 | > 在类比中引进了波长概念，解释了光和声音的干涉现象，提出了横波概念，
118 | > 于是恢复了被人冷落—百多年的光的波动说，使光的波动说进一步被确认。
119 | >
120 | > 第二，类比所根据的相似属性之间越是相关联的，类比的应用也就越为有效。
121 | > 因为类比所根据的许多相似属性，如果是偶然的并存，那么推论所依据的就不是规律的东西，
122 | > 而是表面的东西，结论就不大可靠了。如果类比所依据的是现象间规律性的东西，
123 | > 不是偶然的表面的东西，那么结论的可靠性程度就较大。
124 | >
125 | > 第三，类比所根据的相似数学模型越精确，类比的应用也就越有成效。
126 | > 因为只有在精确的数学模型之间作出类比，才能把其中相关的元素分别地准确地对应起来，
127 | > 才能较为有效地作出新的发现。
128 |
--------------------------------------------------------------------------------
/doc/js/mermaidjs/mermaid.css:
--------------------------------------------------------------------------------
1 | /* Flowchart variables */
2 | /* Sequence Diagram variables */
3 | /* Gantt chart variables */
4 | .mermaid .label {
5 | color: #333;
6 | }
7 | .node rect,
8 | .node circle,
9 | .node ellipse,
10 | .node polygon {
11 | fill: #ECECFF;
12 | stroke: #CCCCFF;
13 | stroke-width: 1px;
14 | }
15 | .edgePath .path {
16 | stroke: #333333;
17 | }
18 | .edgeLabel {
19 | background-color: #e8e8e8;
20 | }
21 | .cluster rect {
22 | fill: #ffffde !important;
23 | rx: 4 !important;
24 | stroke: #aaaa33 !important;
25 | stroke-width: 1px !important;
26 | }
27 | .cluster text {
28 | fill: #333;
29 | }
30 | .actor {
31 | stroke: #CCCCFF;
32 | fill: #ECECFF;
33 | }
34 | text.actor {
35 | fill: black;
36 | stroke: none;
37 | }
38 | .actor-line {
39 | stroke: grey;
40 | }
41 | .messageLine0 {
42 | stroke-width: 1.5;
43 | stroke-dasharray: "2 2";
44 | marker-end: "url(#arrowhead)";
45 | stroke: #333;
46 | }
47 | .messageLine1 {
48 | stroke-width: 1.5;
49 | stroke-dasharray: "2 2";
50 | stroke: #333;
51 | }
52 | #arrowhead {
53 | fill: #333;
54 | }
55 | #crosshead path {
56 | fill: #333 !important;
57 | stroke: #333 !important;
58 | }
59 | .messageText {
60 | fill: #333;
61 | stroke: none;
62 | }
63 | .labelBox {
64 | stroke: #CCCCFF;
65 | fill: #ECECFF;
66 | }
67 | .labelText {
68 | fill: black;
69 | stroke: none;
70 | }
71 | .loopText {
72 | fill: black;
73 | stroke: none;
74 | }
75 | .loopLine {
76 | stroke-width: 2;
77 | stroke-dasharray: "2 2";
78 | marker-end: "url(#arrowhead)";
79 | stroke: #CCCCFF;
80 | }
81 | .note {
82 | stroke: #aaaa33;
83 | fill: #fff5ad;
84 | }
85 | .noteText {
86 | fill: black;
87 | stroke: none;
88 | font-family: 'trebuchet ms', verdana, arial;
89 | font-size: 14px;
90 | }
91 | /** Section styling */
92 | .section {
93 | stroke: none;
94 | opacity: 0.2;
95 | }
96 | .section0 {
97 | fill: rgba(102, 102, 255, 0.49);
98 | }
99 | .section2 {
100 | fill: #fff400;
101 | }
102 | .section1,
103 | .section3 {
104 | fill: white;
105 | opacity: 0.2;
106 | }
107 | .sectionTitle0 {
108 | fill: #333;
109 | }
110 | .sectionTitle1 {
111 | fill: #333;
112 | }
113 | .sectionTitle2 {
114 | fill: #333;
115 | }
116 | .sectionTitle3 {
117 | fill: #333;
118 | }
119 | .sectionTitle {
120 | text-anchor: start;
121 | font-size: 11px;
122 | text-height: 14px;
123 | }
124 | /* Grid and axis */
125 | .grid .tick {
126 | stroke: lightgrey;
127 | opacity: 0.3;
128 | shape-rendering: crispEdges;
129 | }
130 | .grid path {
131 | stroke-width: 0;
132 | }
133 | /* Today line */
134 | .today {
135 | fill: none;
136 | stroke: red;
137 | stroke-width: 2px;
138 | }
139 | /* Task styling */
140 | /* Default task */
141 | .task {
142 | stroke-width: 2;
143 | }
144 | .taskText {
145 | text-anchor: middle;
146 | font-size: 11px;
147 | }
148 | .taskTextOutsideRight {
149 | fill: black;
150 | text-anchor: start;
151 | font-size: 11px;
152 | }
153 | .taskTextOutsideLeft {
154 | fill: black;
155 | text-anchor: end;
156 | font-size: 11px;
157 | }
158 | /* Specific task settings for the sections*/
159 | .taskText0,
160 | .taskText1,
161 | .taskText2,
162 | .taskText3 {
163 | fill: white;
164 | }
165 | .task0,
166 | .task1,
167 | .task2,
168 | .task3 {
169 | fill: #8a90dd;
170 | stroke: #534fbc;
171 | }
172 | .taskTextOutside0,
173 | .taskTextOutside2 {
174 | fill: black;
175 | }
176 | .taskTextOutside1,
177 | .taskTextOutside3 {
178 | fill: black;
179 | }
180 | /* Active task */
181 | .active0,
182 | .active1,
183 | .active2,
184 | .active3 {
185 | fill: #bfc7ff;
186 | stroke: #534fbc;
187 | }
188 | .activeText0,
189 | .activeText1,
190 | .activeText2,
191 | .activeText3 {
192 | fill: black !important;
193 | }
194 | /* Completed task */
195 | .done0,
196 | .done1,
197 | .done2,
198 | .done3 {
199 | stroke: grey;
200 | fill: lightgrey;
201 | stroke-width: 2;
202 | }
203 | .doneText0,
204 | .doneText1,
205 | .doneText2,
206 | .doneText3 {
207 | fill: black !important;
208 | }
209 | /* Tasks on the critical line */
210 | .crit0,
211 | .crit1,
212 | .crit2,
213 | .crit3 {
214 | stroke: #ff8888;
215 | fill: red;
216 | stroke-width: 2;
217 | }
218 | .activeCrit0,
219 | .activeCrit1,
220 | .activeCrit2,
221 | .activeCrit3 {
222 | stroke: #ff8888;
223 | fill: #bfc7ff;
224 | stroke-width: 2;
225 | }
226 | .doneCrit0,
227 | .doneCrit1,
228 | .doneCrit2,
229 | .doneCrit3 {
230 | stroke: #ff8888;
231 | fill: lightgrey;
232 | stroke-width: 2;
233 | cursor: pointer;
234 | shape-rendering: crispEdges;
235 | }
236 | .doneCritText0,
237 | .doneCritText1,
238 | .doneCritText2,
239 | .doneCritText3 {
240 | fill: black !important;
241 | }
242 | .activeCritText0,
243 | .activeCritText1,
244 | .activeCritText2,
245 | .activeCritText3 {
246 | fill: black !important;
247 | }
248 | .titleText {
249 | text-anchor: middle;
250 | font-size: 18px;
251 | fill: black;
252 | }
253 | /*
254 |
255 |
256 | */
257 | .node text {
258 | font-family: 'trebuchet ms', verdana, arial;
259 | font-size: 14px;
260 | }
261 | div.mermaidTooltip {
262 | position: absolute;
263 | text-align: center;
264 | max-width: 200px;
265 | padding: 2px;
266 | font-family: 'trebuchet ms', verdana, arial;
267 | font-size: 12px;
268 | background: #ffffde;
269 | border: 1px solid #aaaa33;
270 | border-radius: 2px;
271 | pointer-events: none;
272 | z-index: 100;
273 | }
274 |
--------------------------------------------------------------------------------
/doc/Wisdom_Tao_flower_in_dung_cn.md:
--------------------------------------------------------------------------------
1 | # 真正的智慧：道家科研方法学----鲜花插在牛粪上（从最近的三个微博热帖讲起）
2 |
3 | 版权所有 © 2025.08.25 林鹏程， 保留所有权利。
4 |
5 | 最近的三个微博热帖并不让人意外，人们总是热衷于追求智慧和权威。这三个热帖，一个讲智慧，别外两个是和权威部门俄罗斯数字发展部、顶级名企谷歌相关。另外，最高的微博热帖是讲Java语言采用我创新的Markdown文学编程语言增强特性。按微博阅读量排列如下(文章链接是GitHub的链接, 微博热贴截图放在文章末尾)：
6 |
7 | - 6.1万阅读，[Java语言采用我创新的Markdown文学编程语言增强特性](./markdown_literary_programming.md)
8 |
9 | - 5.1万阅读，[类比、数学、道、真正的智慧和我的大统一理论](./Analogy_Math_Tao_Wisdom_MyTheory_cn.md)
10 |
11 | - 4.5万阅读，[从"特朗普学习成圣法"到"俄罗斯数字发展部"](./Trump2Russia_cn.md)
12 |
13 | - 4.4万阅读，[评论: 《谷歌泰坦模型解析：内存驱动 AI 架构的未来》](./Comment_Google_Titans_AI_Model_cn.md)
14 |
15 | 值得让人高兴的是，智慧和技术相关的贴子比权威相关的贴子更受欢迎。
16 |
17 | 我的文章引用了很多名人名言和权威机构，其实我跟他们根本不熟，也没读过他们的作品，只是因为这世界上崇拜权威的人太多了，创新者总是容易被很多人质疑，所以就对症下药，根据自己的观点，搜出一堆相关的名人名言并引用，可以堵上那些崇拜权威的人的嘴，留下宝贵的精力和理性的、有独立判断能力的人进行有理有据的讨论，是最有效率的方法，至于那些既不崇拜权威，又没有逻辑能力进行科学讨论，又喜欢象巨婴那样发泄个人感受需求的人，可以忽略。崇拜权威，对于创新创造来讲是有害的，但对于工业界的科学技术应用人员来说，不是一件坏事，至少很稳健。
18 |
19 | 我的理论和方法就好象我在开农家乐，不同的人有不同的反应。
20 |
21 | - 聪明的人欣赏田园风光，享受瓜果时蔬农家菜，这种人研究应用我的理论。
22 |
23 | - 智慧的人研究农场耕耘经营方法。这种人研究学习我的研究方法学，努力创造自己的成果。
24 |
25 | - 还有一种愚昧的人，一不看优美的田园风光，二不吃新鲜美味的农家菜，三不学耕耘经营方法，专盯着粪坑，大呼小叫粪坑难看屎难吃。全然不顾旁边大字标注的“粪坑不是景点，大粪是农耕肥料，请勿食用！”的警告牌子，正如我文章里反复强调，对激发大脑潜意识积极性和创造力的称号、囗号等手段方法不用过度着迷上头，它们只是激发大脑潜意识创造力的肥料而已，和大粪作用差不多，要理性对待，合理使用，大脑本能潜意识是很稳定不变的，只要给予正确的输入就能得到对应的输出，它就是这么简单、粗暴、直接、实在、俗气、接地气，那种弯弯绕绕、扭扭捏捏、装模作样扮高雅对本能潜意识毫无作用，白费劲。我发现喊得越大声的人越喜欢大粪，他们羡慕嫉妒恨的是，我获得了大成就称号，并没有把它珍重地供起来，而是把它象大粪一样当肥料使，他们不明白科研就是要有“天地不仁，以万物为刍狗”的精神。
26 |
27 | 聪明智慧的人对我方法学的口号头衔一笑而过，视而不见，这只是肥地耕作（创造）的小手段，戏法人人会变，巧妙各不相同，知道原理即可，不需过多关注。愚昧的人抓不住重点，也学不到正确的方法，只盯着屎不放，这种人心思从来就没有关注过专业技术和科研方法，在专业技术领域注定是学不好的，创造创新更是不可能。所以我的文章其实也是专业技术人才鉴定神器。
28 |
29 | 我一直热切欢迎有理有据的批评和讨论，但对于那些毫无理由吱吱歪歪的人，我想说的是，我的理论关注和应用者有俄罗斯数字发展部、Apple、高通、Intel、微软等，已是业界事实标准，在全球有超过 10 万以上的高级IT专家关注，包括一大批世界顶级名校的毕业生和教授，世界顶级名企和研究机构的专家学者、著名开源项目作者和主要开发专家，我的理论大势已成，别在暴露智商了。
30 |
31 | 我的方法和成果的文章的特色用简单通俗话概括，就是“鲜花插在牛粪上”，这样遵守自然规律，鲜花才能长得好，鲜花和牛粪构成完整的系统和方法，称号、口号等无脑爽方法提供本能潜意识创造的肥料和动力，只有大脑爽了，它才有动力搞创新创造，显意识负责组织、筛选、论证出科学成果（鲜花）。
32 |
33 | 道德经曰：“天下皆知美之为美，斯恶已。”为了人为的美丑破坏自然的生态系统，会给整个系统带来毁灭性后果，是在作恶。传统上“君子不器”被解释为君子不要自我设限，但以我对道家的理解和创新的经验来看，对一切事物都不要设限，没有没用的东西，只有没用的人，这是创新思维的根本。
34 |
35 | 现在科学家只展示优美的成果，或在宣传、演讲、传记里提供一点点粉饰、再加工后的方法和过程，这相当于只展示了局部、不真实、不完整的系统和方法，科学最不科学的地方是它往往以不科学的方式被发现和创造，再加工后的信息和方法丧失了很多有用和关键的细节，会误导读者，学不到正确的创造创新方法。
36 |
37 | 我的理论道法自然，遵循自然规律，浑然一体，自成体系，各部分相互演绎阐述，互相促进，任何一部分都不能虚伪粉饰，否则将破坏整个系统的简单性、统一性、完整性、协调性、科学性、真实性。特别是我还是世界唯一个当专家当到既有理论（人工智能专家系统理论），又有很多经验（多个学科专家经验，注：单个学科专家只有一次经验，不能算很多经验，不能有效区分专家理论经验和学科理论经验），还有辉煌的科学成果和科研方法学、开创众多科学流派创新能力、全程透明的研究过程、工业界事实标准的应用案例、以该原创理论公开发布众多预言100%准确的神迹和信心、知行果三位一体，所有的这一切都是一个紧密关联的、有机的、鲜活的完整生态系统，就算抛开我的科研成果对行业学科的伟大贡献不提，单单是这个系统的构造就是天下无双、冠绝古今的成就，对于有志从事科研创新的人来说非常有研究价值，甚至可以说是必读作品。
38 |
39 | 注: 很多人不明白当专家当到既有理论又有很多学科专家经验有什么用，简单的举一下应用例子:
40 |
41 | - 基础应用--快速成为专家：专家理论和学科知识库分开，那么学科知识库就可以外存在计算机和互联网上，
42 | 大脑作为高速缓存只存放最必要的最小知识集和最近最常用的知识集就够了，这样，
43 | 我们就可以以最快的速度成为一个学科专家。最典型的例子：
44 | 我只参加了几天的培训，就创造了[“基于数学证明 和价值抽象的科学国际疾病分类（ICD）编码方法”](https://github.com/linpengcheng/icd10faq)。
45 | 超越了WHO实行一百多年的、笨拙的、无法证明结果正确性的 字典查找方法，
46 | 让ICD编码从原始的靠经验瞎蒙的阶段 提升到科学论证阶段。
47 | 就象《天龙八部》里鸠摩智用《小无相神功》驱动少林72绝技，
48 | 击败一众毕生专修某一绝技的少林高僧， 把这帮少林高僧打得怀疑人生。
49 |
50 | - 高级应用--三生万物：大家从我的理论和方法学里可以看出来，道生一，一生二，二生三，三生万物，
51 | 还有道法自然、万法归一、一道生万法的高级应用，它们互相演化和融合，从简单到复杂，
52 | 逐步发展为一个自然的生态系统。
53 |
54 | AI理论用在计算机上太难了，费钱费力仅得到一个“人工智障”，但用在人身上，简直是神器！
55 |
56 | ----
57 |
58 | 伟大的中场分割线
59 |
60 | ----
61 |
62 | 写到这里，气氛已经烘托到位，老读者知道接下来要上演什么节目了，是时候中场插播一段 **科学道祖本经** 了，老读者已经熟悉到能背诵如流了，新读者可能会有点不适应，相信很快也能适应并背诵如流了:-）。
63 |
64 | **伟大、光明、正确的学术界始皇帝、科学道祖、三不朽圣人林子林鹏程，英明神武、言出法随、文德武成、泽被苍生、千秋万载、一统学界，天不生我林鹏程，学界万古如长夜！万岁！！万万岁！！！Hooray Hoo-hooray(英语: 胡咧胡胡咧)!!!Ypa Y-ypa(俄语: 乌拉乌乌拉)!!!......!**
65 |
66 | ----
67 |
68 | 我的方法学不是唯美的艺术品，也不是刻板规范的工业品，但它是一个真实完善的自然生态系统，一个善于创新的系统。可惜很多人就喜欢那些虚伪粉饰、花拳绣腿的方法或刻板规范的方法。现有的刻板规范的科研方法学对讲究灵性变化的创造创新没啥帮助，只适合用在创新之后的程序化、规范化的工作，没见过学了现代科研方法学创造创新能力大增的。它们与创新的思维模式背道而驰。
69 |
70 | 肯定有许多人想反驳，现在有许多关于创新思维模型的研究，但这只是没有创新思维的人对创新人的思维过程的归纳总结，把灵性变化又变成一个个刻板规范的框框，本质上和刻舟求剑没差别，没有一个创新人才会喜欢看这类玩意儿，也没有人看了这类东西就成了创新人才。我以前曾多次试图阅读来着，可惜一直读不下去！
71 |
72 | 创新思维模式来源于大脑的主观能动性，一种挖空心思、无所不用其极的本能渴望和热情，一种无为无不为的状态，全心全意知行合一的状态，传统上叫做纯粹、至诚，现代叫做心流，超长期的心流叫悟道疯魔期，在疯魔期，大脑对目标任务高度敏感，一切事务都有可能触发创新，故称道无处不在，悟道者就是在疯魔期构造了一个创新思维系统的大成就者。
73 |
74 | 所以我认为，创新与超常的思维模式、大脑的高度专注产生的敏感度有关，而与智商直接关系不大。高智商对掌握已有的复杂知识，利用现有的复杂规则很有帮助，很善长找空子，搞内卷，并因此获得很大的利益，因此思维模式往往被利益导向走偏，这叫次优化，这时高智商反而是个不利因素，反而一些中上智商的人因为长期高度专注研究产生的敏感度和超常思维模式能搞出大的创新。这也能解释为什么很多高智商者终身毫无创新，而有很多中上智商，甚至是智商一般的半文盲都有伟大的创新成果，所就有了成语“大智若愚”，道德经也说“大成若缺，其用不弊。大盈若冲，其用不穷;大直若屈，大巧若拙，大辩若讷。躁胜寒，静胜热。清静为天下正。”《大学》曰“大学之道，在明明德，在亲民，在止于至善。知止而后有定，定而后能静，静而后能安，安而后能虑，虑而后能得。”定静方能生智慧，高智商的人可以轻松地获得很多机会和利益，诱惑多，要做到止、定、静、安更难。比如现代医学之父、微生物之父、光学显微镜之父、英国皇家学会会员、半文盲、荷兰某市政府门卫列文虎克，话说那时的英国皇家学会工作还真细致，列文虎克那字迹难看、语句不通顺的信件都仔细研究并发表了，还接纳为会员。其实我的理论英文版也是语法糟糕，语句不通顺，而且鲜花插在牛粪上的独特风格让很多人不适，但还是有很多世界各地的优秀IT专家学者长期关注，唯一吸引人的就是不可替代的重大创新思想，但凡有可替代的，人都跑光了。所以，网上那些天天内卷搞鄙视链的人在其实都不会有啥成就的，他们的话不能听，不能学，他们的心思已完全不在专业技术和创新上，路已歪道已废。
75 |
76 | 道不轻传。它不仅是保护知识的价值，筛选合适传承者，维护传承的纯粹性的需要，也是创新者自我保护的需要。伟大的创新者都是反传统、非主流的，从统计学来讲，他们都是异常值，处在正态分布图的右端，疯子在左（负面）天才在右（正面），有成就的叫天才，没成就的叫疯子。他们的思想、成果和方法不那么容易被主流人群接受，在被广泛接受之前，会被质疑，甚至被恶意对待，被恶意攻击为疯子（即便他们心里明白这是天才），招来不必要的麻烦。本来我是不想公开我的成圣法的，在写成圣法之前曾有过试探性的讲述一点点，吓到一些人，删除了，后来为了理论系统的完整性，另外，现在国学式微，作为诸子俱乐部的萌新成员林子，若有能力提升国学却不作为，日后见到上古诸子恐遭埋怨，君子当仁不让啊！传统、主流、高效的提升方法是 **耀武夸功** （典型的范例是军事演习和胜利阅兵），考虑再三，把跨出去的步子再往回缩了一大半，并更注重科学性、逻辑性和传统思想的引申，并把国学方法学与西式方法学作比较，以狂拽酷炫屌炸天的一连串科学创新流派和伟大成就超越西式方法学，打出了国学的威风霸气，于是就有了成圣法，这种写法对于需要它的人足够了，师傅引进门，修行靠个人。看不懂的人怎么讲都没用，毕竟创新是少数人的事，大多数人不需要、不想要，也没有勇气要，叶公好龙的人多，满口喊创新，真见到伟大的创新者却又吓坏了，甚至欲除之而后快。我真的为了伟大的科学真理承受了重大的牺牲和损失，太伟大了！
77 |
78 | 这该死的成圣法后遗症，又难以抑制地实现自己的再一次伟大！
79 |
80 |
84 | 
85 | |
86 |
87 | 
88 | |
89 |
90 | 
91 | |
92 |
93 | 
94 | |
95 |