ADSP (Algorithms + Data Structures = Programs)
297: Design of APIs, UIs, and Algorithms
C++Now 2018: Ben Deane “Easy to Use, Hard to Misuse: Declarative Style in C++”
UX: Higher-level issues.
"Doherty Threshold" from Halt and Catch Fire: computer interaction must be <400 ms. Not actually true/mis-stated.
What kind of threshold are we targeting for a UI? E.g. direct interaction is 16–50ms (scrolling, dragging, etc). Discrete UI actions (e.g. clicking a button) must be <100 ms.
UI: Lower-level issues, like Fitt's law (target to hit must be as large as possible).
The Elements of Typographic Style by Robert Bringhurst. Must-read for folks interested in typefaces.
API design: avoid coupling a binary operator with an algorithm. E.g. std::adjacent_difference does not necessarily have to subtract things!
Difference between an awesome product and a tedious product is attention to detail.
Best systems are not designed for beginners. Folks are only ever a beginner for a short time (1–2w), most people are various states of "perpetual intermediate" (users can be intermediate indefinitely).
296: Networking in FPS and RTS
Networking is not correlated with Moore's law: even though CPUs have gotten faster, networking has not.
FPS
- Latency intolerant
- Relatively small world (what you see on the screen), can send full world on each network request.
RTS
- Generally run parallel simulations, with occasional syncs.
- Want to send whole world, but too difficult: too many objects.
301: AI Fluency
Auto-Research Academy idea: don't need to learn GPU programming, instead setup loops to let AI do it. At EuroPython and EuroSciPy sprints (sponsor: Modal, serverless GPU provider). GPU mode: GPU kernel programing community, regularly has competitions to get people to learn GPU programming.
288: C++Now 2026, Lasting Quality, Programming as Theory Building
C++Now 2026 talk to look for:
- Rob Leahy's talk about senders at a low level, Async Everything Part 1 and 2
Michael Case's talk in Lasting Quality [ slides ]
Types of quality:
Functional quality
- Does it meet specification/requirements?
- Low defect count
- Adequate/Good enough performance
- Does it do what it's advertised to do?
Process quality
- Can delivery dates be met? Can we deliver on time?
- Can budgets be met?
- Can we repeatedly do this without team burn out? Is the process reliable?
- Focus is on: organization, team, and execution
Structural quality
- Idea that "code is beautiful"
- Is it testable?
- Is it maintainable?
- Is it efficient? (Not necessarily performant) Efficiency = API concern, Performance = Implementation concern.
- Is it sufficiently abstracted? I.e. no leaky abstractions, does changing one part cause ripple effects in other parts?
- Is it secure?
- Does it have good APIs that are "designed", such that they are composable with no unexpected side effects or complication?
- With Structural Quality, Process and Functional Quality generally follow
Software design: something abstract that's typically independent of the implementation.
Different types of debt:
Technical debt: mis-nomer, because debt is supposed to be a financial tool. Generally thoguht of as the lack of ability to change software. Lives inside code.
Cognitive debt: team's understand of how the code works. Lives inside people.
Intent debt: Why did we make certain decisions? Why does the software work this way?
Technical debt can be fixed if you don't have Cognitive debt (at least much easier). Cognitive debt can be fixed if you don't have Intent debt. Extremely difficult to understand Intent debt.
Way to tackle Cognitive/Intent debt: rewrite software. How or why may bubble up if still relevant.
AI can tackle technical debt, but generally cannot touch Cognitive debt or Intent debt, because those live in humans.
Harold (Hal) Abelson and Gerald Jay Sussman wrote that quote in the preface to their 1984 textbook, Structure and Interpretation of Computer Programs (SICP):
> "First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute."
“The purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.” — Edsger W. Dijkstra
Programming as Theory Building, Peter Naur (1985).
Program is distinct from the implementation (program is not the code), it's the theory in the head of the people who built the program. Code is an expression of the program; if it were the program, it wouldn't be possible to replace parts of the code and it still work the same (Theseus' Ship).
Communicating the theory: lots of problems are issues with communication: diagrams, documentation, formula are generally very difficult to communicate. Code is an expression is often the best way to communicate because it's deterministic (and code with high Structural Quality are prime examples).
Programs are often self-similar (i.e. fractals). Each API is built in terms of the next. By the time we're at the top, complexity disappears. At the bottom (most complex), it's arbitrary: we can say it's 0 and 1s, but that's an abstraction of mushy waveforms at the hardware level, which are an abstraction on top of quantum mechanics.
