可逆计算

nop-chaos-flux 是一个基于 React 19、Zustand 5 和 Vite 8 构建的低代码运行时框架。它受百度 AMIS 启发，但基于创新的设计原理从零开始独立实现，包含 JSON

前提：设计思想的源头 Flux 的核心设计思想并不是在实现过程中逐步发现的，而是早在 AMIS 理论研究阶段就已经确立。nop-entropy/docs/theory/amis/ 下的两篇文章——为什

引言 nop-chaos-flux 是 Nop 平台的渲染层——一个基于声明式 DSL 驱动的低代码运行时，用于在浏览器中渲染和执行由 Schema 描述的应用页面。它的 DSL 表面形态与百度 AM

1. 引言 — 为什么需要又一个低代码框架？ 百度 AMIS 是一个非常优秀的设计。它功能强大、文档丰富，被广泛用于各种企业级应用，在低代码渲染领域有着深远的影响力。然而，AMIS 的发展历史很长——

在关系型数据库查询中，我们经常需要根据关联集合来判断主表记录是否符合条件。例如： 查找"至少有一个角色是管理员的用户" 查找"所有订单都已完成的客户" 查找"没有任何未读消息的用户" 传统SQL需要写

引言：一个正在发生的范式转移 2026年，我们正站在 AI 发展的一个重要拐点上。当一些系统开始以“Agent Operating System”而非“聊天机器人框架”自我定义（例如最近发布的 Ope

开篇：两个误解，一个真相 Nop平台（官网：https://nop-platform.github.io/) 是一个基于可逆计算理论从零开始构建的新一代低代码开发平台。它的核心理念是通过DSL（领域特

在落地可逆计算理论和Nop平台的过程中，我反复观察到一种现象：一些核心设计思想，程序员听完之后觉得“确实有道理”，但他们事前绝不会自己想到。 这种“想不到”不是因为智力不够或知识不足，而是因为日常编程

引言 领域驱动设计（DDD）是 Eric Evans 在 2003 年提出的一套软件设计方法。二十年来，它被广泛讨论，也被广泛误解。多数教程会给你一份模式清单——实体、值对象、聚合根、限界上下文——然

讲解视频：Nop入门：使用NopReport导出Excel图表_哔哩哔哩_bilibili Nop平台内置了一个非常精简的中国式报表引擎NopReport，它可以实现商业报表引擎如FineReport

Nop平台为开发自定义DSL（Domain Specific Language，领域特定语言）提供了一系列基础设施，核心机制是通过XDef元模型（Nop平台的元模型语言）定义XML格式的语法结构，然后

在我的前一篇文章《目前程序语言与软件工程研究中真正严重的缺陷是什么？》中，我提出了一个核心观点：当代编程语言与软件工程的主流理论，把注意力几乎全部集中在“单个程序的静态快照”上，却缺乏一套以“变化本身

如果只从“某种语言不够优雅”“某种方法落地难”来谈缺陷，很容易停留在战术层面。要谈“真正严重的缺陷”，必须下潜到更底层的问题： 我会从三层来展开： 学界主流范式到底在假定一个什么样的世界？这个世界观的

对于软件领域的大量设计原则和所谓的方法论，我一直持有很深的怀疑态度。为什么会存在这些原则，能否从科学的层面证明它们的有效性？可逆计算理论试图为软件构造提供一个更加坚实的理论基础，它明确提出应该将“差量

摘要： 模型驱动架构（MDA）通过提升抽象层次与自动化来应对软件复杂性。然而，传统MDA在实践中面临“往返工程”与“胖模型”等挑战，这些问题的解决一般依赖于工程经验，缺少完备的数学理论的指导。本文探讨

知乎上有人问了一个问题：Java微服务API版本兼容如何实现平滑升级？ 在微服务架构中，服务频繁迭代导致API版本差异增大，而客户端（如App、Web前端）的升级节奏往往滞后，这常常引发兼容性问题，甚

初次接触"最小信息表达"原则时，很容易觉得它不过是又一个"高内聚低耦合"式的抽象口号。但当我们真正尝试将其应用到日常设计中，会发现这个概念远比看起来复杂。在讨论和实践中，我注意到自己和同行们反复陷入几

很多人感觉Nop的理念“高大上”但落地无从下手，这是非常正常的。根本原因在于：Nop不是一个解决特定问题的“工具”，而是一套重构你软件开发工作流的“新操作系统”。 一、 Nop解决的根本问题 在数学层

在领域驱动设计（DDD）的殿堂中，“聚合根作为一致性与事务的边界”几乎是一条不容置疑的金科玉律。它被视为守护领域模型纯洁性、确保数据完整性的最后一道防线。然而，当我们将目光投向那些极度复杂、需要高度演

知乎上有人提出一个问题： 这是一个非常好的问题，它触及了DDD实践中最核心的困惑点。这个观察非常准确：理论上充血模型很合理，但实践中却容易陷入“业务逻辑到底放在哪”的泥潭，导致代码散乱、难以维护。 我