software architecture

Jeffrey Emanuel ✔ @doodlestein · 19h So if I manage to actually build this thing, who gets the plaudits? Me or Fable/Anthropic? Can we agree it's me (lol)? That would be like crediting Aladdin with the works of the Genie. But I DID have to ask for something odd, in a very special way... claude.ai/public/artifac... [Embedded document image, titled "COMPREHENSIVE PLAN FOR FRANKENSIM", subtitle: "A single, memory-safe Rust continuum for computational geometry, physics, optimization, and rendering — designed from a blank slate for Apple Silicon and many-core x86, built on the Franken constellation (asupersync, FrankenSQLite, FrankenNumpy, FrankenTorch, FrankenScipy, FrankenPandas, FrankenNetworkx), with zero other runtime dependencies."] 0. How to read this document This is a design plan, not a survey. Every mechanism described here is chosen because it is load-bearing for the mission: given a physics-based objective and constraints, synthesize the geometry that optimizes it — faster, more correctly, and more verifiably than any existing system, on commodity many-core CPUs, in pure safe Rust. Ambition is calibrated with three tags used throughout: • [S] Solid — established mathematics and engineering; the work is implementation excellence, not research risk. • [F] Frontier — published research from roughly the last decade that no mainstream system has productized; real engineering risk, enormous payoff. • [M] Moonshot — novel synthesis proposed here for the first time (to my knowledge); prototyped behind feature flags, promoted only after the Gauntlet (§13) validates it. The mix is deliberate: the spine of FrankenSim is [S], the leapfrog features are [F], and a handful of [M] bets are what make the system unlike anything else. Nothing tagged [M] sits on the critical path of the roadmap. 1. Thesis: why a blank slate wins Every existing pipeline for "optimize a shape against physics" is an archipelago: OpenCASCADE or a B-rep kernel for geometry, gmsh or a proprietary mesher for discretization, an FEM/CFD code (FEniCS, MFEM, deal.II, OpenFOAM, SU2, COMSOL, Abaqus) for physics, SciPy/NLopt/Dakota for optimization, ParaView for looking at the wreckage. Each island is excellent. The water between them is where everything drowns: 1. Derivatives don't cross boundaries. The CAD kernel doesn't know the mesh's sensitivity to a control point; the solver's adjoint dies at the mesher; the optimizer sees a noisy black box and falls back to finite differences or pure evolution. 2. Error bounds don't cross boundaries. Geometry tolerance, meshing error, discretization error, solver tolerance, statistical noise — nobody composes them. You get a number with no pedigree. 3. Provenance doesn't exist. Six weeks into a design study, nobody can reconstruct which mesh, which solver settings, and which random seed produced the Pareto point the client liked. 4. Cancellation doesn't exist. An optimizer that discovers a candidate is hopeless after 10% of its simulation cannot claw back the other 90% of the compute — the process model is "run to completion or kill -9." 5. The hardware is wasted. These codebases predate 96-core CCD-partitioned CPUs and 546 GB/s unified-memory laptops; they are MPI-shaped or single-threaded-with-OpenMP-sprinkles, allergic to work stealing, and dependent on BLAS binaries tuned for a different decade. [cut off]

Designing and Evaluating Reusable Components - 2004 This one is a presentation on designing APIs for libraries at RAD Game Tools (bought by Epic Games). Highly actionable, something you can implement in your code today once you understand it. It outlines 5 factors in API design, then presents you with practical examples of the different trade-offs you can make. It ends with a pretty solid list of dos and don'ts. [Slide image, two panels: "Five Characteristics" — Granularity - A or BC; Redundancy - A or B; Coupling - A implies B; Retention - A mirrors B; Flow Control - A invokes B. "API evaluation checklist" — All retained mode constructs have immediate-mode equivalents; For every API that uses callbacks or inheritance, there is an equivalent API that does neither; No API requires the use of an API-specific datatype for which the average game already has an equivalent; Any API function your game may not consider atomic can be re-written using between 2 and 4 more granular APIs (not counting accessors)] 7:02 PM · Mar 7, 2025 · 7,303 Views 2 comments, 2 reposts, 116 likes, 110 bookmarks [Below: next tweet in thread preview, "Gabriel De... 16h ... The Only Unbreakable Law"]

The Only Unbreakable Law This one starts by trying to answer the question of whether there are any actual laws in Software Architecture, and proceeds to outlines principles that are the closest we have so far. I won't spoil the conclusions, but it will make you seriously question software practices you see in companies today. [Video thumbnail: man in a "Star Code Galaxy" t-shirt next to a diagram of a tree/hierarchy structure] 7:02 PM · Mar 7, 2025 · 7,098 Views 2 comments, 1 repost, 89 likes, 58 bookmarks