Skip to content

Commit

Permalink
梳理文档
Browse files Browse the repository at this point in the history
  • Loading branch information
entropy-cloud committed Feb 1, 2025
1 parent 50ed357 commit 2bbb049
Show file tree
Hide file tree
Showing 8 changed files with 672 additions and 61 deletions.
7 changes: 7 additions & 0 deletions docs/compare/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,3 +5,10 @@

## 与Skyve低代码平台的对比
参见 [nop-vs-skyve.md](nop-vs-skyve.md)

## 与SolonFlow的对比
逻辑编排引擎与Solon平台中的solon-flow引擎对比,参见[nop-task-flow-vs-solon-flow.md](nop-task-flow-vs-solon-flow.md)

## 与APIJSON的对比
NopORM + NopGraphQL的功能与APIJSON框架的对比,参见[nop-vs-apijson.md](nop-vs-apijson.md)

23 changes: 20 additions & 3 deletions docs/compare/nop-task-flow-vs-solon-flow.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ nodes:
```javascript
@Test
public void testDiscount()
public void testDiscount()
FlowEngine flowEngine = FlowEngine.newInstance();
flowEngine.load(Chain.parseByUri("classpath:flow/bookDiscount.yml"));

Expand All @@ -62,7 +62,7 @@ nodes:

//价格变了,省了100块
assert bookOrder.getRealPrice() == 400;
}
}
```

**NopTaskFlow的核心(nop-task-core模块)虽然只有3000行左右的代码,但是它是一个非常完整的逻辑编排引擎,支持异步处理、超时重试、断点重提等高级功能**,所以用NopTaskFlow可以很容易的实现solon-flow所演示的功能。
Expand Down Expand Up @@ -180,7 +180,7 @@ steps:
可逆计算理论强调同一个信息可以具有多种表达形式(Representaion),这些表达形式因为信息等价,所以可以自由的进行可逆转换。比如说,所谓的可视化设计可以看作是DSL模型的一种可视化展现形式,而DSL代码文本是模型信息的文本表达形式。之所以能够进行可视化设计,原因就在于可视化表象和文本表象之间可以相互转换。

```
可视化表象 = Designer(文本表象), 文本表象 = Serializer(可视化表象)
可视化表象 = Designer(文本表象), 文本表象 = Serializer(可视化表象)
```
利用Nop平台内置的机制和可逆性的可复合性,从字段级别的多重表象可以自动推导得到对象级别的多重表象,从而自动实现模型对象的可视化编辑。比如说,对于solon-flow而言,如果要开发一个可视化设计器,需要专门针对solon-flow的语法去设计并实现这个设计器,但是在Nop平台中,我们可以根据元模型定义自动生成一个专用于逻辑编排的可视化设计器,并不需要针对逻辑编排引擎去编写设计器。
Expand Down Expand Up @@ -278,6 +278,8 @@ steps:

在Nop平台中,我们还可以将Excel模型导入到数据库中,通过Web页面来在线编辑、调整规则,并可以在线调试。

关于NopRule的详细介绍,参见[采用Excel作为可视化设计器的开源规则引擎 NopRule](https://mp.weixin.qq.com/s/zJvovUG2f4mjB5CbrlX6RA)

## 四. 模型嵌套

Nop平台与所有其他平台、框架的一个本质性区别在于,它并不是孤立的去研发某个底层引擎,而是一次性抽象完成所有引擎的底层技术架构,所有的引擎都共享同样的XLang语言和可逆计算支持。使用XLang定义的DSL语言不需要自己去考虑扩展性问题(也不用设计相关语法),而且也不需要考虑多个DSL如何无缝集成在一起使用的问题。
Expand Down Expand Up @@ -342,3 +344,18 @@ Nop平台与所有其他平台、框架的一个本质性区别在于,它并
```

可以直接指定ruleModelPath,也可以指定ruleName和ruleVersion,然后动态确定规则模型对象(从虚拟文件内系统中加载,没有找到则尝试在数据库中加载)。

Nop平台并不只是提供单一功能的DSL,而是一系列DSL组成的所谓DSL森林。关于DSL森林的详细介绍,可以参见[Nop如何克服DSL只能应用于特定领域的限制?](https://mp.weixin.qq.com/s/6TOVbqHFmiFIqoXxQrRkYg),
更详细的示例参见[为什么SpringBatch是一个糟糕的设计?](https://mp.weixin.qq.com/s/1F2Mkz99ihiw3_juYXrTFw)


基于可逆计算理论设计的低代码平台NopPlatform已开源:

- gitee: [canonical-entropy/nop-entropy](https://gitee.com/canonical-entropy/nop-entropy)
- github: [entropy-cloud/nop-entropy](https://github.com/entropy-cloud/nop-entropy)
- gitcode:[canonical-entropy/nop-entropy](https://gitcode.com/canonical-entropy/nop-entropy)
- 开发示例:[docs/tutorial/tutorial.md](https://gitee.com/canonical-entropy/nop-entropy/blob/master/docs/tutorial/tutorial.md)
- [可逆计算原理和Nop平台介绍及答疑\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV14u411T715/)
- 官网国际站: [https://nop-platform.github.io/](https://nop-platform.github.io/)
- 网友Crazydan Studio建立的Nop开发实践分享网站: [https://nop.crazydan.io/](https://nop.crazydan.io/)

55 changes: 0 additions & 55 deletions docs/theory/delta-frontend.md

This file was deleted.

3 changes: 0 additions & 3 deletions docs/theory/delta-model-design.md

This file was deleted.

74 changes: 74 additions & 0 deletions docs/theory/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,9 @@ App = Delta x-extends Generator<DSL>

继续补充一些针对可逆计算理论的概念辨析,澄清对于可逆计算理论的一些常见误解

## [可逆计算理论中的可逆到底指的是什么?](what-does-reversible-mean.md)
可逆一词与物理学中熵的概念息息相关,熵增的方向确定了物理世界中时间箭头的演化方向,可逆计算理论所研究的是面向演化的粗粒度软件结构的构造规律,所以可逆正是这个理论的点睛之笔。一些没有学过热力学和统计物理的同学,对于熵的概念一无所知,看到可逆这个说法难免会感到一头雾水。可逆重要吗?软件要怎么可逆?逆向执行吗?这有什么意义?在本文中,我简单解释一下可逆计算理论中可逆到底指什么。

## [从可逆计算看Delta Oriented Programming](delta-oriented-programming.md)

本文对比了可逆计算理论与软件工程理论界的相关工作,如面向特性编程(FOP)和面向差量编程(DOP),并指出在可逆计算视角下,这些理论还存在哪些不足之处。
Expand All @@ -39,6 +42,12 @@ App = Delta x-extends Generator<DSL>

框架设计中的多维度扩展在数学层面上可以看作是张量积空间上的线性映射函数。本文从理论层面解释了可逆计算原理如何与Loader抽象相结合。

## [写给程序员的差量概念辨析,以Git和Docker为例](explanation-of-delta.md)
虽然都叫做差量,但是差量和差量之间仍然有着非常深刻的区别。总的来说git和docker本质上都涉及到差量计算,但是它们所对应的差量也有着本质上不同的地方,这里的精细的差异需要从数学的角度才能解释清楚。一般人对于差量概念的理解其实是望闻生义,存在着非常多的含混的地方,所以很多的争论本质上是因为定义不清导致的,而不是这个问题本身内在的矛盾导致的。
[金蝶云苍穹的Extension与Nop平台的Delta的区别](delta-vs-extension.md)
[DeepSeek AI对于Delta定制概念的理解--深度超越普通程序员](deepseek-understanding-of-delta.md)
[通用的Delta差量化机制](generic-delta-composition.md)

## [从可逆计算看DSL的设计要点](xdsl-design.md)

Nop平台基于可逆计算原理,提出了一整套系统化的构建机制来简化DSL的设计和实现,使得我们很容易增加针对自己业务领域的DSL,也很容易在已有DSL的基础上进行扩展。
Expand All @@ -50,3 +59,68 @@ Nop平台基于可逆计算原理,提出了一整套系统化的构建机制
## [如何评价一种框架技术(比如ORM框架)的好坏](props-and-cons-of-orm-framework.md)

对于一种新的框架技术,"很方便、很好用"这样的评价表达的仅仅是一种主观感受,能否在客观层面定义一些不受人的主观偏好影响的客观标准?
[什么是好的模型?](good_design.md)
[业务开发如何才能独立于框架](framework-agnostic.md)

## [Nop如何克服DSL只能应用于特定领域的限制?](nop-for-dsl.md)
Nop平台可以看作是一个语言工作台(Language Workbench),它为DSL(领域特定语言,Domain Specific Language)的设计和研发提供了完整的理论支撑和底层工具集。使用Nop平台来开发,主要是使用DSL来表达业务逻辑,而不是使用通用的程序语言来表达。有些人可能会有疑问:既然DSL是所谓的领域特定语言,那岂不是意味着它只能应用于某个特定领域,这样在描述业务的时候是不是会存在本质性的限制?以前ROR(Ruby On Rails)框架流行的时候,热炒过一段时间DSL的概念,但现在不也悄无声息了,Nop又有何特异之处?对这个问题的回答很简单:Nop平台是基于可逆计算理论从零开始构建的下一代低代码平台,而可逆计算理论是一个系统化的关于DSL设计和构建的理论,它在理论层面解决了传统DSL设计和应用所存在的问题。
[如何开发一个能够开发低代码平台的平台](meta-platform.md)
[从可逆计算看DSL的设计要点](xdsl-design.md)

## [Nop平台为什么是一个独一无二的开源软件开发平台](technical-strategy.md)
Nop平台与其他开源软件开发平台相比,其最本质的区别在于Nop平台是**从第一性的数学原理出发,基于严密的数学推导**逐步得到各个层面的详细设计。它的各个组成部分具有一种内在的数学意义上的一致性。这直接导致Nop平台的实现相比于其他平台代码要短小精悍得多,而且**在灵活性和可扩展性方面也达到了所有已知的公开技术都无法达到的高度**,可以实现系统级的粗粒度软件复用。而主流的技术主要基于组件组装的思想进行设计,其理论基础已经决定了整体软件的复用度存在上限。

## [为什么说XLang是一门创新的程序语言?](why-xlang-is-innovative.md)
XLang语言之所以是一门创新的程序语言,是因为它创造了一个新的程序结构空间,在这个结构空间中可以很方便的实现可逆计算理论所提出的`Y = F(X) + Delta`的计算范式
[DeepSeek的通俗版解释:XLang为什么是一门创新的编程语言?](deepseek-understanding-of-xlang.md)

对于这篇文章的答疑参见 [答疑1](xlang-explained.md)[答疑2](xlang-explained2.md)

## [如果重写SpringBoot,我们会做哪些不同的选择?](lowcode-ioc.md)
如果我们完全从零开始重新编写SpringBoot,那么我们会明确定义哪些核心问题由底层框架来负责解决?针对这些问题我们会提出什么样的解决方案?这些解决方案与SpringBoot目前的做法又有哪些本质上的差异?Nop平台中的依赖注入容器NopIoC是基于可逆计算原理从零开始实现的一个模型驱动的依赖注入容器,它通过大约5000行代码,实现了我们所用到的SpringBoot的所有动态自动装配机制和AOP拦截机制,并且实现了GraalVM集成,可以很容易的编译为native镜像。在本文中,我将结合NopIoC的实现代码,谈一谈在可逆计算理论视角下对IoC容器设计原理的所作的一些分析。

## [低代码平台需要什么样的ORM引擎?](lowcode-orm-1.md)
什么是ORM?ORM为什么可以简化数据访问层的代码编写?哪些常见的业务语义可以统一下放到ORM层来表达?在低代码平台的语境下,数据结构需要支持用户自定义调整,从前端展现界面到后台数据存储的逻辑路径需要被尽量压缩,ORM引擎可以为此提供哪些支持?如果我们不满足于事先限定的某些低代码应用场景,而是希望实现一条从LowCode到ProCode的平缓的升级路径,我们对ORM引擎会提出什么样的要求?
[低代码平台需要什么样的ORM引擎?(2)](lowcode-orm-2.md)

## [为什么在数学的意义上GraphQL严格的优于REST?](graphql-vs-rest.md)
Nop平台中通过严密的数学推理,对于GraphQL的定位进行了重新的诠释,获得了一些新的设计思想和技术实现方案。在这种诠释下,NopGraphQL引擎实现了对REST的全面超越,
可以说在数学的意义上GraphQL严格的优于REST。

## [从零开始编写的下一代逻辑编排引擎 NopTaskFlow](lowcode-task-flow.md)
NopTaskFlow是一个基于可逆计算理论实现的逻辑编排引擎。
[为什么NopTaskFlow是一个独一无二的逻辑编排引擎](why-nop-taskflow-is-special.md)

## [NopReport为什么是一个非常独特的报表引擎?](why-nop-report-is-special.md)
NopReport与一般的报表引擎不同,它可以直接采用Excel和Word作为模板,而不一定需要使用专用的可视化设计器。

## [为什么SpringBatch是一个糟糕的设计?](why-springbatch-is-bad.md)
SpringBatch的设计在今天看来存在严重的设计问题,对于性能优化、代码复用都极为不友好。本文分析了SpringBatch的设计问题,并结合NopBatch这一新的批处理框架的实现方案来介绍下一代批处理框架的设计思想。

## [为什么Nop平台坚持使用XML而不是JSON或者YAML](why-xml.md)
在Nop平台中,XML和JSON是自动支持双向转换的,本质上用哪种表达方式都不影响模型的语义


## [从可逆计算看低代码](lowcode-explained.md)
[从可逆计算看AI时代的复用](reuse.md)

## [关于Nop平台底层理论的答疑](faq-about-theory-of-nop.md)
[关于可逆计算的讨论--答圆角骑士魔理沙](discussion-about-reversible-computation.md)

## [什么是数据驱动?它和模型驱动、领域驱动、元数据驱动、DSL驱动之间有什么区别?](what-is-data-driven.md)
XX Driven是软件工程领域的常见黑话之一,翻译过来就是某某驱动,替换一下XX,我们就得到了数据驱动、模型驱动、领域驱动、元数据驱动、DSL驱动等等这一大堆的驱动。一个很自然的疑问是,这些不同的驱动之间有什么区别?有什么必要人为制造出这么多不同的概念?

## [小学生也可以轻松掌握的Paxos算法秘奥](paxos-explained.md)
Paxos算法是分布式领域中一个非常基本的算法,一向以晦涩烧脑著称。但是它之所以让人感到摸不着头脑,主要是因为我们不容易直观地理解它为什么要这样设计。尽管我们可以通过具体例子来验证其正确性,甚至可以用严谨的数学证明来说服自己它是对的,但我们还是很难回答,为什么一定要选择这种方式?这是否是唯一可行的方法?有没有可能不依赖数学推导,就能找到一种解释,让Paxos算法在直觉上显得不言而喻?
[Paxos的魔法学研究报告](paxos.md), [普通小学生也能理解的Paxos算法讲解](paxos-for-kids.md)

## [函数式编程为什么有利于解耦(Decouple)](functional-programming-for-decouple.md)
函数式编程的思想以及在我们日常编程中如何应用函数式编程来实现逻辑解耦,函数式编程在哪些方面提供了对于面向对象编程的一种有益的补充

## [从React Hooks看React的本质](essence-of-react.md)

```
(props, @reactive state) => vdom
```

render函数是一种好不容易建立起来的信息管道,如果使用一次就随手丢弃,那实在是太浪费了,何不反复利用?通过引入具备响应性的状态变量,规定一个全局的响应式规则:“无论什么原因导致state变化,自动触发局部的render函数重新执行”,就可以使得render函数得到成功的升华,**完美的将微观的交互性嵌入到了宏观的信息流场景中**
File renamed without changes.
Loading

0 comments on commit 2bbb049

Please sign in to comment.