Hasty Briefsbeta

All tags

software design

16 stories total

Bilingual

Getopt() but Friendlier
2 months ago
- The article proposes a friendlier CLI argument parser in C that improves upon POSIX getopt() by allowing flags before or after positional arguments, using consistent separators for long options, and supporting short option chaining.
- The author implements an iterator-based parser using a struct to hold state (avoiding global variables) and a tagged union for argument types, achieving re-entrancy and a simpler loop structure.
- The parser is provided as a C23 single-header library with macros for convenient argument matching (e.g., ARG_SHORT, ARG_LONG, ARG_POS) and error handling.
- The discussion reflects on C's poor ergonomics and the value of reexamining established conventions, with the author noting C as a 'comfort language' despite its flaws.
The Bedrock of Software Design
2 months ago
- Algebraic data types (ADTs) consist of product types (combining fields) and sum types (one of several variants), with sum types being especially powerful.
- ADTs encode domain rules into the type system, making invalid states unrepresentable and eliminating the need for fragile comments or validation.
- Sum types like Rust's Result explicitly include expected failures in function signatures, ensuring callers handle errors without surprise exceptions.
- Option type models optional values, removing null/undefined ambiguity and forcing handling of absence.
- Exhaustive pattern matching ensures all possible cases are covered, preventing forgotten branches and making code safer.
- When domain models change, exhaustive matching on sum types causes compile errors at every affected location, guiding safe updates.
- Pattern matching reduces mental overhead by letting developers focus on one case at a time while the compiler tracks all combinations.
- Good domain modeling with ADTs means impossible combinations are reflected in the type system, not left as runtime concerns.
Reversing Abstractions: An Existential Crisis
2 months ago
- The author critiques the dominant 'forward/existential' approach in computer science, which hides implementation details, and advocates for 'backward/universal' approaches that make details accessible.
- Examples of opting out of hiding include ABIs (public conventions) and DWARF debuggers (meta-level descriptions), with debuggers representing a universal approach that can recover abstract views from any concretion.
- The neglect of backward/universal methods contributes to software brittleness, contrasting with biological adaptability, and programming language research is particularly averse to this direction.
- Link-time optimization (LTO) currently delays lowering rather than lifting; the author proposes using debugging information to lift object code back to intermediate representation for better flexibility.
- Networking's hourglass design (IP) exemplifies a universal approach supporting diversity, unlike existential uniformity, and the author calls for similar thinking in language implementation.
- The author argues that software performance is now limited by social and cultural factors, not machine performance, so overhead concerns about universal approaches should not be overemphasized.
Build agents, not pipelines
2 months ago
- The article contrasts two approaches for using LLMs in software: pipelines (control flow in code) and agents (LLM manages control flow via tools).
- Pipelines are more predictable and cost-effective, while agents offer greater flexibility and intelligence for complex tasks.
- Agents are preferred for hard problems like code generation, as they can autonomously gather context via tools like grep and read file.
- The text advises using pipelines for strict context size or cost requirements, and agents when unsure about assembling all relevant context.
- Key examples include using agents for coding assistance and combining both approaches for large-scale tasks like email surveillance.
Design Patterns
2 months ago
- Design patterns are common solutions to recurring problems in software design, meant to be used naturally rather than forced.
- The Strategy pattern encapsulates behavior via functions or objects, useful for clean code and deduplication.
- The Factory pattern creates objects, encapsulating state or hiding construction logic.
- The Visitor pattern is the inverse of an iterator, useful for trees/graphs but less ergonomic than iterators.
- The Builder pattern constructs objects with many configurable fields, primarily useful in libraries for non-breaking API changes.
- The Singleton pattern ensures only one instance of a class exists (e.g., loggers, thread pools), but harms testability.
- Other patterns like Facade and Command are considered trivial and intuitive, not worth special discussion.
- Explicitly naming patterns (e.g., FooBuilder, visit) helps communicate intent in code.
Solution-space Taste
2 months ago
- The solution-space taste analogy uses a 2D field of obstacles to represent problem-solving in software design, where paths are solutions.
- Junior engineers often only focus on immediate obstacles, leading to overcomplicated solutions, similar to LLM coding agents that make drastic changes like editing React.js source code for minor errors.
- Experienced developers use local exploration and backtrack when they sense unexpected complexity, employing heuristics like a one-day implementation limit to signal insufficient understanding.
- Advanced practitioners scout parts of the solution space out of order to create stronger heuristics, connecting sketched pieces more efficiently based on prior domain experience.
- The analogy simplifies real-world complexity but serves as an intuition pump for navigating problem spaces and cultivating taste for clean versus overcomplicated solutions.
- Developing taste requires writing at least 100K lines of code, receiving feedback from better programmers, and carefully studying code written by experts.
Separation of concerns in a bug tracker
2 months ago
- Bug trackers often conflate facts (bugs exist) with plans (intentions to fix), causing confusion.
- Examples: Jira's 'Fix Version' mixes definite reality and hopes; two-tier status lumps 'Won't Fix' into 'Closed'.
- Using the bug list as the entire to-do list forces features to be represented as 'anti-bugs', leading to awkward fields.
- Proposal: Separate records into a 'facts' table (e.g., bug existence, commit fixes) and a 'plans' table (e.g., intentions, deadlines).
- Facts and plans can be linked but independently updated, allowing projects to omit planning entirely if desired.
- Feature requests should be pure plans until implemented, then become positive facts about presence.
A Philosophy of Software Design - Bert Hubert's writings
2 months ago
- John Ousterhout's book 'A Philosophy of Software Design' is a concise 178-page work that distills 40 years of experience into insights on software complexity.
- The book identifies complexity as the defining trait of software success and offers concepts like 'shallow' and 'deep' methods, 'information leakage', and 'pulling complexity downwards'.
- Ousterhout critiques common practices, such as over-emphasizing commit messages over source code comments, and argues that code cannot document calling semantics.
- The book covers a wide range of examples, from language design to low-latency distributed storage, making it unique in its scope.
- Good design leads to more enjoyable development, as designers spend more time in the fun design phase rather than chasing bugs.
Hackers and Painters
2 months ago
- Hackers and painters are both makers, creating things rather than conducting research or science.
- The term 'computer science' is misleading; hacking is more akin to art or engineering, not science.
- Hackers should design software through iterative sketching and refinement, similar to painters, rather than following rigid upfront specifications.
- Static typing and premature design can hinder creativity; programming languages should be malleable like a pencil.
- Startups allow hackers to design and implement products directly, avoiding the committee-driven design of large companies.
- Day jobs and open-source projects enable hackers to work on beautiful software on the side, following the model of other makers.
- Empathy is essential for hackers to understand users and create great software, just as painters must engage their audience.
- Learning to hack comes from doing and studying examples, like painters copying masters or writers paraphrasing essays.
- Great software requires relentless attention to detail and beauty, even in parts users never see.
- Collaboration in software should be modular with clear ownership, avoiding multiple people working on the same code.
Holding a Program in One's Head
2 months ago
- Good programmers hold the entire program in their head, like a mathematician holds a problem, enabling deep understanding and easy manipulation.
- This ability is crucial early in a project to allow changing the problem being solved, not just the solution.
- Factors that help: avoid distractions, work in long uninterrupted sessions, use powerful languages, rewrite programs often, write rereadable code, work in small groups, avoid multiple editors on the same code, and start small with prototypes.
- Many programmers accidentally achieve these when working on side projects, leading to higher productivity and better design.
- Organizations often hinder this by treating programmers as interchangeable parts, scheduling meetings, and requiring multiple authors on code.
- Startups can exploit this weakness by focusing on problems that require deep individual concentration and allowing programmers to work without organizational constraints.
<antirez>
2 months ago
- The 10x programmer myth describes a programmer who can produce ten times the output of an average professional programmer.
- Programming is a design discipline, not linear, so experience and skills combine multiplicatively to boost productivity.
- Key qualities for high productivity include: bare programming abilities, experience for pattern matching, focus, design sacrifice, simplicity, avoiding perfectionism, theoretical knowledge, low-level machine understanding, and debugging skills.
- Simplicity is achieved through design sacrifices and avoiding complexity, often by eliminating non-essential features.
- Opportunistic programming prioritizes features with maximum user impact and minimal effort.
<antirez>
2 months ago
- The author feels a responsibility to help less experienced programmers adapt to AI-driven changes in programming, based on their own foresight and experience.
- The key shift is that programmers should focus on controlling the ideas and design of software rather than reading code line-by-line, because LLMs handle local optimization well and generate large amounts of code.
- Reasons to prioritize ideas: LLMs produce verbose code, humans have limited time, and it's more efficient to evaluate design through prompts instead of scanning functions.
- The author's work on DwarfStar and comparison with other implementations shows that AI can help catch errors in complex domains like local inference, where hand-written code is often flawed.
- Resistance to AI may be ideological; rigorous engineering and testing are more valuable than manual code review, especially for domains like GPU kernels.
- Even for codebases like Redis, detailed code review is becoming less useful; instead, documenting design ideas in a DESIGN.md file would be more valuable for future modification.
- Young programmers should learn fundamentals (e.g., writing a small interpreter) but not waste time reviewing LLM-generated code for mundane tasks.
- The software world was already 'rotten' before AI, and AI offers opportunities to improve it, though the change is painful.
Claude Is Not a Compiler
2 months ago
- The author argues that LLMs like Claude exceed compilers by working vertically across all software layers, from strategy to machine code.
- Traditional software layers (executive to compiler) involve decision-making, but LLMs enable cross-layer integration without organizational overhead.
- A concrete example: building a distributed DNS server for exe.dev using iterative agent-driven design, differential analysis, and scar-tissue guidance over a week.
- The process contrasted 'vibe-coding' (delegating decisions) with 'vibe-engineering' (using LLMs to augment decision-making across layers).
- Software layers that provide insight remain valuable, but those offering mere convenience are becoming obsolete.
- The emerging paradigm shifts engineers' focus upward without abandoning deeper layer understanding, making vibe-engineering synonymous with engineering.
DSLs Enable Reliable Use of LLMs
2 months ago
- Domain-Specific Languages (DSLs) enhance LLM reliability by providing clear boundaries and constraints, reducing variability in code generation.
- DSLs act as a source of truth for software systems, enabling LLMs to serve as natural language interfaces and iterative partners in design.
- Abstractions and semantic models, like Tickloom for distributed systems, ground LLM prompts in existing vocabulary, improving accuracy and reducing hallucinations.
- LLMs operate in two phases: as brainstorming partners during DSL design and as reliable generators once the DSL is established.
- DSLs support deterministic validation (e.g., parsers or compilers), allowing autonomous agents to self-correct errors without human intervention.
- Examples include using LLMs with PlantUML for presentations and internal DSLs for testing distributed system scenarios, showcasing their versatility.
- Well-factored DSLs produce maintainable, readable artifacts that capture intent, reducing reliance on prompts as the primary source of truth.
Why you should not have Managers in your class name
2 months ago
- Naming classes and methods correctly is crucial as it influences code structure, future thinking, refactoring, and extension, with poor naming leading to technical debt.
- Using '-er' suffixes like 'Manager' often indicates poor design; for example, 'ConnectionManager' became complex with multiple responsibilities, whereas 'Connection' would have been clearer and simpler.
- Choosing precise names helps maintain clean code, simplifies extension and refactoring, and reduces complexity and bugs, so spending extra time on naming is recommended.
"Software Engineering" Is Not Engineering
2 months ago
- Computer Science is not science and Software Engineering is not engineering because software design lacks objective metrics and ties to physical reality.
- Software is more akin to mathematics, allowing creation of virtual worlds with internal consistency, unlike engineering bound by physical laws.
- Debates in software often revolve around idioms, paradigms, and conventions, which are difficult to compare objectively due to reliance on human psychology and productivity factors.
- Programmer productivity and maintainability are key concerns, but empirical studies are scarce, and personal comfort with tools often dictates productivity.
- Existing computer science literature focuses on techniques and idioms, such as Boolean algebra, but fails to provide scientific methods for evaluating 'better' approaches.
- The flexibility of software enables infinite possibilities, but this also makes objective evaluation nearly impossible, leading to persistent, unresolved debates in the field.

firstprev0next

software design

Getopt() but Friendlier

The Bedrock of Software Design

Reversing Abstractions: An Existential Crisis

Build agents, not pipelines

Design Patterns

Solution-space Taste

Separation of concerns in a bug tracker

A Philosophy of Software Design - Bert Hubert's writings

Hackers and Painters

Holding a Program in One's Head

<antirez>

<antirez>

Claude Is Not a Compiler

DSLs Enable Reliable Use of LLMs

Why you should not have Managers in your class name

"Software Engineering" Is Not Engineering