Programming
Table of Contents
- Testing (Programming)
- Program as Data
- Probabilistic Logic Programming
- The Night Watch
- Rump's Royal Pain
- Property Based Testing
- Software Design Books
- A Philosophy of Software Design
- Your Code as a Crime Scene
- Code that Fits in Your Head
- Documentation
- BitTorrent
- Worse is Better
1. Conferences
2. Style
- Tiger Style: https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md
- Callbacks go last in the list of parameters. This mirrors control flow: callbacks are also invoked last.
- Pair the asserts (Contract Checker)
- Fail Fast
3. Event Based Programming
Can be thought as a programming paradigm. Useful for Distributed systems.
Procedural paradigm is the most familiar and simple paradigm for programmming. However, it doesn't work for distributed system, because function calls
- aren't movable accross resource: they happen in the system it was started
- are tied to lifetime of resource
However, event handler based system is fit for distributed systems. They provide the necessary semantics.
But have the cons:
- stack ripping / callback hell
Can we have procedure based programming model with an event based execution model? An event loop provides this model.
For concurrent applications, event loop (async/await) provide the abstraction of procedurs based programming and event based execution.
Similarly, we can use distributed event loop [https://www.youtube.com/watch?v=hofEKFZtBj8] to translate the same effect to distributed systems.
- We can have recovery if the component async commands can be restarted and give idempotent results.
4. Simple Made Easy
From Simple made easy (YT), a talk by Rich Hickey.
- Construct vs. Artifact: Programmers often choose a construct (the source code/language feature) because it's easy (familiar/quick to type). However, they must be assessed based on the resulting artifact (the running program) and whether it is simple (unentangled).
- Limits: Complexity limits a programmer's ability to understand and reason about the system for debugging and change.
- Speed is a Myth: Focusing on ease leads to a fast start, but the growing, unmanaged complexity will cause the development pace to slow down invariably over the long term.
4.1. Simple vs. Complex Constructs
| Complex Constructs (Complecting) | Simpler Alternatives (Disentangling) |
|---|---|
| State (complexes value & time) | Values (immutable) & Consistency (transactions) |
| Objects (complexes state, identity, & value) | Functions & Namespaces |
| Methods (complexes function & state) | Polymorphism a la Carte (protocols/type classes) |
| Variables/var (complexes value & time) | Managed References (e.g., closures references) |
| Inheritance (complects types) | Polymorphism a la Carte |
| Syntax (complects meaning & order) | Data (maps, sets) |
| Imperative Loops/Fold | Set Functions |
| Actors (complects what's done & who does it) | Queues |
| ORM (Object-Relational Mapping) | Declarative Data Manipulation (SQL, Datalog) |
| Conditionals (if/else) (scattered) | Rules (declarative rule systems) |
| Inconsistency (stands apart) | Consistency |
by Polymorphism a la Carte (Polymorphism On Demand) he means, mechanisms for adding polymorphism on demand separate from the data structure definitions themselves. This allows the ability to add new behavior to existing types (or new types to existing behavior) without changing and recompiling the existing code. E.g.
- Protocols (Clojure)
- Type Classes (Haskell, Scala)
- Multimethods (Clojure)
4.2. Design for simplicity
Designing a simple system involves a strict separation of concerns, often broken down by asking Who, What, When, Where, Why, and How:
| Concern | Principle of Simplicity | Solution/Tool |
|---|---|---|
| What (Operations/Function) | Do not complect with "How." Use small, focused specifications for functions. | Protocols, Interfaces (small), Type Classes |
| Who (Data/Entities) | Build components using dependency injection (taking subcomponents as arguments) . | Direct Injection Style |
| How (Implementation) | Implementation code should be islands that do not dictate What or Who. | Polymorphism Constructs (Protocols) |
| When & Where (Location & Time) | Avoid direct connections (Thing A calling Thing B) which complects location and time . | Queues (to decouple) |
| Why (Policy/Rules) | Do not strew policy throughout the application logic. | Declarative Rule Systems |
| Information | Do not apply object-like encapsulation to information. It ruins generic data manipulation. | Represent Data as Data (Maps and Sets) |