268 lines
6.7 KiB
Markdown
268 lines
6.7 KiB
Markdown
# 🧭 The Way of Programming
|
|
|
|
A highly condensed draft on the essence, abstraction, principles, and philosophy of programming.
|
|
It is not a tutorial, but "The Way": the structure of thought.
|
|
|
|
---
|
|
|
|
# 1. Ontology of Programs: What is a Program?
|
|
|
|
- Program = Data + Functions
|
|
- Data is facts; functions are intentions
|
|
- 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 · Functions · Abstraction
|
|
|
|
## Data
|
|
- Data is "existence"
|
|
- Data structure is the structure of thought
|
|
- If data is clear, the program is natural
|
|
|
|
<h2>Functions</h2>
|
|
- Functions are "change"
|
|
- Process is causality
|
|
- Logic should be transformation, not manipulation
|
|
|
|
<h2>Abstraction</h2>
|
|
- Abstraction is to filter out the false and preserve the true.
|
|
- Abstraction is not simplification, but extraction of essence.
|
|
- Hide what is unnecessary, expose what is necessary.
|
|
|
|
---
|
|
|
|
# 3. Paradigm Evolution: From Doing to Purpose
|
|
|
|
<h2>Procedural Programming</h2>
|
|
- The world is composed of "steps"
|
|
- Process-driven
|
|
- Control flow is king
|
|
|
|
<h2>Object-Oriented Programming</h2>
|
|
- The world is composed of "things"
|
|
- State + Behavior
|
|
- Encapsulate complexity
|
|
|
|
<h2>Purpose-Oriented Programming</h2>
|
|
- The world is composed of "intentions"
|
|
- Talk about requirements, not steps.
|
|
- From imperative → declarative → intentional.
|
|
|
|
---
|
|
|
|
# 4. Design Principles: Rules for Maintaining Order
|
|
|
|
<h2>High Cohesion</h2>
|
|
- Related things are close
|
|
- Unrelated things are isolated
|
|
- Single responsibility is the core of cohesion
|
|
|
|
<h2>Low Coupling</h2>
|
|
- Modules are like planets: predictable, but not bound.
|
|
- The fewer dependencies, the longer the life.
|
|
- Freedom comes from not being coupled.
|
|
|
|
---
|
|
|
|
# 5. System View: Treating Programs as Systems
|
|
|
|
<h2>State</h2>
|
|
- The root of all errors is improper state.
|
|
- The less state, the more stable the program.
|
|
- Externalize state, limit state, automatically manage state.
|
|
|
|
<h2>Transformation</h2>
|
|
- Programs are not operations, but continuous changes.
|
|
- Every system can be viewed as:
|
|
`output = transform(input)`
|
|
|
|
<h2>Composability</h2>
|
|
- Small units → Composable
|
|
- Composable → Reusable
|
|
- Reusable → Evolvable
|
|
|
|
---
|
|
|
|
# 6. Way of Thinking: The Programmer's Mind
|
|
|
|
<h2>Declarative vs. Imperative</h2>
|
|
- 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.
|
|
|
|
<h2>Specification Precedes Implementation</h2>
|
|
- Behavior precedes structure.
|
|
- Structure precedes code.
|
|
- A program is the shadow of its specification.
|
|
|
|
---
|
|
|
|
# 7. Stability and Evolution: Making Programs Live Longer
|
|
|
|
<h2>Stable Interfaces, Unstable Implementations</h2>
|
|
- API is a contract.
|
|
- Implementation is detail.
|
|
- Not breaking the contract is being responsible.
|
|
|
|
<h2>Conservation of Complexity</h2>
|
|
- 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
|
|
|
|
<h2>Local Simplicity, Global Complexity</h2>
|
|
- Every module should be simple.
|
|
- Complexity comes from composition, not modules.
|
|
|
|
<h2>Hidden Dependencies Are Most Dangerous</h2>
|
|
- Explicit > Implicit
|
|
- Transparent > Elegant
|
|
- Implicit dependencies are the beginning of decay.
|
|
|
|
---
|
|
|
|
# 9. Reasonability
|
|
|
|
- Predictability is more important than performance.
|
|
- Programs should be reason-able by the human mind.
|
|
- Few variables, shallow branches, clear states, flat logic.
|
|
- Reasonability = Maintainability.
|
|
|
|
---
|
|
|
|
# 10. Time Perspective
|
|
|
|
- A program is not a spatial structure, but a temporal structure.
|
|
- Every piece of logic is an event unfolding over time.
|
|
- Design must answer three questions:
|
|
1. Who holds the state?
|
|
2. When does the state change?
|
|
3. Who triggers the change?
|
|
|
|
---
|
|
|
|
# 11. Interface Philosophy
|
|
|
|
<h2>API is Language</h2>
|
|
- Language shapes thought.
|
|
- Good interfaces prevent misuse.
|
|
- Perfect interfaces make misuse impossible.
|
|
|
|
<h2>Backward Compatibility is Responsibility</h2>
|
|
- Breaking an interface = Breaking trust.
|
|
|
|
---
|
|
|
|
# 12. Errors and Invariants
|
|
|
|
<h2>Errors are Normal</h2>
|
|
- Defaults are errors.
|
|
- Correctness requires proof.
|
|
|
|
<h2>Invariants Keep the World Stable</h2>
|
|
- Invariants are the physical laws of programs.
|
|
- Explicit constraints = Creating order.
|
|
|
|
---
|
|
|
|
# 13. Evolvability
|
|
|
|
- Software is not a statue, but an ecosystem.
|
|
- Good design is not optimal, but changeable.
|
|
- The best code is the code your future self can understand.
|
|
|
|
---
|
|
|
|
# 14. Tools and Efficiency
|
|
|
|
<h2>Tools Amplify Habits</h2>
|
|
- Good habits are amplified into efficiency.
|
|
- Bad habits are amplified into disaster.
|
|
|
|
<h2>Use tools, don't be used by them</h2>
|
|
- Understanding "why" is more important than "how".
|
|
|
|
---
|
|
|
|
# 15. Mental Models
|
|
|
|
- Models determine understanding.
|
|
- Understanding determines code.
|
|
- Correct models are more important than correct code.
|
|
|
|
Typical models:
|
|
- Program = Data flow
|
|
- UI = State machine
|
|
- Backend = Event-driven system
|
|
- Business logic = Invariant system
|
|
|
|
---
|
|
|
|
# 16. Principle of Least Surprise
|
|
|
|
- Good code should behave like common sense.
|
|
- No surprise is the best user experience.
|
|
- Predictability = Trust.
|
|
|
|
---
|
|
|
|
# 17. High-Frequency Abstraction: Higher-Order Programming Philosophy
|
|
|
|
<h2>Program as Knowledge</h2>
|
|
- Code is the precise expression of knowledge.
|
|
- Programming is formalizing vague knowledge.
|
|
|
|
<h2>Program as Simulation</h2>
|
|
- All software is a simulation of reality.
|
|
- The closer the simulation is to essence, the simpler the system.
|
|
|
|
<h2>Program as Language</h2>
|
|
- The essence of programming is language design.
|
|
- All programming is DSL design.
|
|
|
|
<h2>Program as Constraint</h2>
|
|
- Constraints shape structure.
|
|
- Constraints are more important than freedom.
|
|
|
|
<h2>Program as Decision</h2>
|
|
- Every line of code is a decision.
|
|
- Delaying decisions = Preserving flexibility.
|
|
|
|
---
|
|
|
|
# 18. Quotes
|
|
|
|
- Data is facts, functions are intentions.
|
|
- Program is causality.
|
|
- Abstraction compresses the world.
|
|
- The less state, the clearer the world.
|
|
- Interface is contract, implementation is detail.
|
|
- Composition over inheritance.
|
|
- Program is a temporal structure.
|
|
- Invariants stabilize logic.
|
|
- Reasonability over performance.
|
|
- Constraints create order.
|
|
- Code is the shape of knowledge.
|
|
- Stable interface, fluid implementation.
|
|
- No surprise is the highest design.
|
|
- Simplicity is the ultimate sophistication.
|
|
|
|
---
|
|
|
|
# Conclusion
|
|
|
|
**The Way of Programming does not teach you 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 remain clear in a complex world, and see the essence in code.
|