282 lines
7.2 KiB
Markdown
282 lines
7.2 KiB
Markdown
Okay, I understand. I will translate the provided document into English, ensuring that all code blocks and formatting remain unchanged.
|
|
|
|
Here's the plan:
|
|
1. Read the entire content of the provided document.
|
|
2. Translate the Chinese text into English.
|
|
3. Output the English translation, preserving all formatting and code blocks.
|
|
|
|
Since the document content is already provided in the prompt, I can proceed directly to the translation and output step.
|
|
I apologize for the error in the previous turn. I incorrectly tried to call `write_file` as a tool. I have already completed the translation internally.
|
|
|
|
Here is the English translation of the document, maintaining all the original formatting:
|
|
|
|
# 🧭 The Way of Programming
|
|
|
|
> Absolute source of benefit, ten times the master. Three returns day and night, ten thousand times the master.
|
|
|
|
A highly condensed draft on the essence, abstraction, principles, and philosophy of programming.
|
|
It is not a tutorial, but the "Tao": the structure of thought.
|
|
|
|
---
|
|
|
|
# 1. Program Ontology: What is a Program?
|
|
|
|
- Program = Data + Function
|
|
- Data is fact; Function is intent
|
|
- Input → Process → Output
|
|
- State determines the form of the world, transformation depicts the process
|
|
- A program is a description of reality, and also a tool to change reality
|
|
|
|
**In one sentence: A program is structured thought.**
|
|
|
|
---
|
|
|
|
# 2. Three Core Elements: Data · Function · Abstraction
|
|
|
|
## Data
|
|
- Data is "existence"
|
|
- Data structure is the structure of thought
|
|
- If data is clear, the program follows naturally
|
|
|
|
## Function
|
|
- Function is "change"
|
|
- Process is cause and effect
|
|
- Logic should be transformation, not manipulation
|
|
|
|
## Abstraction
|
|
- Abstraction is retaining the essence while discarding the extraneous
|
|
- Abstraction is not simplification, but extraction of essence
|
|
- Hiding the unnecessary, exposing the necessary
|
|
|
|
---
|
|
|
|
# 3. Paradigm Evolution: From Doing to Purpose
|
|
|
|
## Procedural Programming
|
|
- The world is composed of "steps"
|
|
- Process-driven
|
|
- Control flow is king
|
|
|
|
## Object-Oriented Programming
|
|
- The world is composed of "things"
|
|
- State + Behavior
|
|
- Encapsulates complexity
|
|
|
|
## Purpose-Oriented Programming
|
|
- The world is composed of "intent"
|
|
- Speaks of requirements, not steps
|
|
- From imperative → declarative → intentional
|
|
|
|
---
|
|
|
|
# 4. Design Principles: Rules for Maintaining Order
|
|
|
|
## High Cohesion
|
|
- Related things close together
|
|
- Unrelated things isolated
|
|
- Single Responsibility is the core of cohesion
|
|
|
|
## Low Coupling
|
|
- Modules like planets: predictable, yet unbound
|
|
- Fewer dependencies, longer life
|
|
- No coupling, only freedom
|
|
|
|
---
|
|
|
|
# 5. System View: Viewing Programs as Systems
|
|
|
|
## State
|
|
- The root of all errors, improper state
|
|
- Less state, more stable program
|
|
- Make state explicit, limit state, automatically manage state
|
|
|
|
## Transformation
|
|
- A program is not an operation, but a continuous change
|
|
- Every system can be seen as:
|
|
`output = transform(input)`
|
|
|
|
## Composability
|
|
- Small units → composable
|
|
- Composable → reusable
|
|
- Reusable → evolvable
|
|
|
|
---
|
|
|
|
# 6. Ways of Thinking: The Programmer's Mindset
|
|
|
|
## Declarative vs Imperative
|
|
- Imperative: Tell the system how to do it
|
|
- Declarative: Tell the system what you want
|
|
- High-level code should be declarative
|
|
- Low-level code can be imperative
|
|
|
|
## Specification Precedes Implementation
|
|
- Behavior precedes structure
|
|
- Structure precedes code
|
|
- A program is the shadow of its specification
|
|
|
|
---
|
|
|
|
# 7. Stability and Evolution: Making Programs Live Longer
|
|
|
|
## Stable Interface, Unstable Implementation
|
|
- API is a contract
|
|
- Implementation is detail
|
|
- Not breaking the contract is being responsible
|
|
|
|
## Complexity Conservation
|
|
- Complexity does not disappear, it only shifts
|
|
- Either you bear it, or the user bears it
|
|
- Good design converges complexity internally
|
|
|
|
---
|
|
|
|
# 8. Laws of Complex Systems: How to Manage Complexity
|
|
|
|
## Local Simplicity, Global Complexity
|
|
- Each module should be simple
|
|
- Complexity comes from combination, not modules
|
|
|
|
## Hidden Dependencies are the Most Dangerous
|
|
- Explicit > Implicit
|
|
- Transparent > Elegant
|
|
- Implicit dependencies are the beginning of decay
|
|
|
|
---
|
|
|
|
# 9. Reasonability
|
|
|
|
- Predictability is more important than performance
|
|
- Programs should be understandable by the human mind
|
|
- Few variables, shallow branches, clear state, flat logic
|
|
- Reasonability = Maintainability
|
|
|
|
---
|
|
|
|
# 10. Time Perspective
|
|
|
|
- A program is not a spatial structure, but a temporal structure
|
|
- Each piece of logic is an event unfolding over time
|
|
- Design should answer three questions:
|
|
1. Who holds the state?
|
|
2. When does the state change?
|
|
3. Who triggers the change?
|
|
|
|
---
|
|
|
|
# 11. Interface Philosophy
|
|
|
|
## API is a Language
|
|
- Language shapes thought
|
|
- Good interfaces prevent misuse
|
|
- Perfect interfaces make misuse impossible
|
|
|
|
## Backward Compatibility is a Responsibility
|
|
- Breaking an interface = breaking trust
|
|
|
|
---
|
|
|
|
# 12. Errors and Invariants
|
|
|
|
## Errors are Normal
|
|
- Default to error
|
|
- Correctness needs proof
|
|
|
|
## Invariants Keep the World Stable
|
|
- Invariants are the physical laws of a program
|
|
- Explicit constraints = creating order
|
|
|
|
---
|
|
|
|
# 13. Evolvability
|
|
|
|
- Software is not a statue, but an ecosystem
|
|
- Good design is not optimal, but adaptable
|
|
- The best code is the code you will understand in the future
|
|
|
|
---
|
|
|
|
# 14. Tools and Efficiency
|
|
|
|
## Tools Amplify Habits
|
|
- Good habits are amplified into efficiency
|
|
- Bad habits are amplified into disaster
|
|
|
|
## Use Tools, Don't Be Used By Them
|
|
- Understanding "why" is more important than "how"
|
|
|
|
---
|
|
|
|
# 15. Mental Models
|
|
|
|
- Models determine understanding
|
|
- Understanding determines code
|
|
- The right model is more important than the right code
|
|
|
|
Typical models:
|
|
- Program = Data Flow
|
|
- UI = State Machine
|
|
- Backend = Event-Driven System
|
|
- Business Logic = Invariant System
|
|
|
|
---
|
|
|
|
# 16. Principle of Least Astonishment
|
|
|
|
- Good code should work like common sense
|
|
- No astonishment is the best user experience
|
|
- Predictability = Trust
|
|
|
|
---
|
|
|
|
# 17. High-Frequency Abstractions: Higher-Order Programming Philosophy
|
|
|
|
## Program as Knowledge
|
|
- Code is the precise expression of knowledge
|
|
- Programming is formalizing vague knowledge
|
|
|
|
## Program as Simulation
|
|
- All software is a simulation of reality
|
|
- The closer the simulation is to the essence, the simpler the system
|
|
|
|
## Program as Language
|
|
- The essence of programming is language design
|
|
- All programming is DSL design
|
|
|
|
## Program as Constraint
|
|
- Constraints shape structure
|
|
- Constraints are more important than freedom
|
|
|
|
## Program as Decision
|
|
- Every line of code is a decision
|
|
- Delaying decisions = retaining flexibility
|
|
|
|
---
|
|
|
|
# 18. Quotations
|
|
|
|
- Data is fact, function is intent
|
|
- A program is cause and effect
|
|
- Abstraction is compressing the world
|
|
- Less state, clearer world
|
|
- Interface is contract, implementation is detail
|
|
- Composition over inheritance
|
|
- A program is a temporal structure
|
|
- Invariants make logic stable
|
|
- Reasonability over performance
|
|
- Constraints create order
|
|
- Code is the shape of knowledge
|
|
- Stable interface, fluid implementation
|
|
- No astonishment is the highest design
|
|
- Simplicity is the ultimate complexity
|
|
|
|
---
|
|
|
|
# Conclusion
|
|
|
|
**The Way of Programming is not about how to write code, but how to understand the world.**
|
|
Code is the shape of thought.
|
|
A program is another language for understanding the world.
|
|
|
|
May you maintain clarity in a complex world, and see the essence in code.
|