https://www.hillelwayne.com/tags/terms/ Recent content in Terms on Hillel Wayne Hugo -- gohugo.io en-us Wed, 01 May 2024 00:00:00 +0000 https://www.hillelwayne.com/post/software-friction/ Wed, 01 May 2024 00:00:00 +0000 https://www.hillelwayne.com/post/software-friction/ In his book On War, Clausewitz defines friction as the difference between military theory and reality: Thus, then, in strategy everything is very simple, but not on that account very easy. Everything is very simple in war, but the simplest thing is difficult. These difficulties accumulate and produce a friction, which no man can imagine exactly who has not seen war. As an instance of [friction], take the weather. https://www.hillelwayne.com/post/world-vs-machine/ Thu, 04 Jan 2024 00:00:00 +0000 https://www.hillelwayne.com/post/world-vs-machine/ This is just a way of thinking about formal specification that I find really useful. The terms originally come from Michael Jackson’s Software Requirements and Specifications. In specification, the machine is the part of the system you have direct control over and the world is all the parts that you don’t. Take a simple transfer spec: ---- MODULE transfer ---- EXTENDS TLC, Integers CONSTANTS People, Money, NumTransfers (* --algorithm transfer variables acct \in [People -> Money]; define \* Invariant NoOverdrafts == \A p \in People: acct[p] >= 0 end define; process cheque \in 1. https://www.hillelwayne.com/post/complexity-constraints/ Mon, 23 Jan 2023 00:00:00 +0000 https://www.hillelwayne.com/post/complexity-constraints/ Complexity is bad. Simple software is better than complex software. But software is complex for a reason. While people like coming up with grand theories of complexity (Simple Made Easy, No Silver Bullet) there’s very little info out there on the nitty-gritty specific sources of complexity. Without that, all the theories feel to me like the four elements theory. We just don’t have the data needed to come up with something more predictive. https://www.hillelwayne.com/post/safety-and-liveness/ Tue, 06 Sep 2022 00:00:00 +0000 https://www.hillelwayne.com/post/safety-and-liveness/ img {border-style: groove; border-width: 1px; padding: 5px; } Sounds like I should write a post on safety and liveness! First, some definitions. A system is anything that has changing state. This is an incredibly broad definition that covers a wide variety of situations, like: Two threads in a thread scheduler Five servers behind a load balancer A reader and writer communicating on a FIFO queue A business workflow being manually followed A person waiting for the bus Etc. https://www.hillelwayne.com/post/software-mimicry/ Mon, 29 Aug 2022 00:00:00 +0000 https://www.hillelwayne.com/post/software-mimicry/ Mimicry is when software X reimplements at a higher level a core feature of software Y. The produced facsimile has some, but not all, of the same properties, enough to “look like” it’s the same thing but missing many of the nuances. This exists in every kind of software. One language can mimic another, a library can mimic a language, a database engine can mimic a product, etc. Example Design Patterns introduces the strategy pattern to apply multiple algorithms to the same call: https://www.hillelwayne.com/post/cleverness/ Sun, 06 Jun 2021 00:00:00 +0000 https://www.hillelwayne.com/post/cleverness/ “Don’t write clever code.” Why not? “Because it’s hard to understand.” People who say this think of clever code such as Duff’s Device: Duff's Device send(to, from, count) registershort*to, *from; registercount; { registern =(count +7) /8; switch(count %8) { case0: do{ *to =*from++; case7: *to =*from++; case6: *to =*from++; case5: *to =*from++; case4: *to =*from++; case3: *to =*from++; case2: *to =*from++; case1: *to =*from++; } while(--n >0); } } show all This code is “clever” because it exploits knowledge about the language, in this case the peculiarities of fall-through. https://www.hillelwayne.com/post/constructive/ Mon, 18 May 2020 00:00:00 +0000 https://www.hillelwayne.com/post/constructive/ Consider a data type that represents users, which includes “favorite people” and “blocked people”:1 data Person: favorites: set of Person blocked: set of Person We want a validation that says that these two sets are disjoint, a.k.a. no person can belong to both sets at once. We call these kinds of validations predicates, or boolean functions that correspond to our requirements. The predicates determine if a representable item is also a valid item.