Vocabulary
Since software and programming is a new frontier we need new language to be able to express ideas about it, instead of just mapping terminology from bridge-building. Otherwise we can get misled about how things really are, by broken analogies. The best example of this is Rich Hickeys talk about simple made easy.
What are some concepts in software and programming that we don't have a good name for? Try coining some new terms. Is there anything we can import to here from the c2 wiki?
Related Links[edit]
Other people have understood the important of this too e.g. the movement for not saying piracy or stealing but copying
- Copying Is Not Theft - Question Copyright.
- GNU words to avoid.
- Bellman on "Dynamic Programming".
- unmumble programming slang archive mostly jokes.
- [1] small section mentioning some of Dijkstra's terms.
bug compatible[edit]
Yikes. This term is so old it's even in the jargon file.
bus factor[edit]
How screwed are the users of the software going to be, or the people who try to take it on if the lead maintainer disappears?
betamaxed[edit]
When a somewhat inferior option becomes the most popular standard and dominates.
decomplect[edit]
To simplify by unweaving threads.
- Antonym of complect.
Separation of Concerns[edit]
TODO: explain this.
- Coined by Dijkstra in EWD447.
footgun[edit]
Related to: Shooting yourself in the foot.
shotgun surgery[edit]
"Shotgun Surgery" refers to a change to one piece of code resulting in the need to change many other pieces of code"
featureitis[edit]
A pretty powerful visual image of software going wrong by sprout feature after feature.
Avoid this by doing one thing well.
boilerplate[edit]
related to bookkeeping code
callback hell[edit]
Describes programming in CPS, with everything done through callbacks instead of direct style.
cleanroom[edit]
Could be used to describe the debugging technique of comparing the output/trace of a working program against an in-development version.
Has two quite different meanings.
- https://en.wikipedia.org/wiki/Cleanroom_software_engineering
- https://en.wikipedia.org/wiki/Clean_room_design
over engineered[edit]
When you solve a problem with a rube goldberg machine.
endless march/upgrade treadmill[edit]
You have to upgrade to fix old bugs, upgrade provides new features that add new bugs. The result is software that is never stable and always has more and more bugs! Makes software soar in terms of linecount.
Keeping up to date on the latest upstream kernel will generally net all the bug fixes that have been created thus far, but with it of course brings completely new features, new code, new bugs, and new attack surface
- Applies to the linux kernel
- Applies to gcc.
malcompliance[edit]
Today's fun, customer says "Is it OK if we make 20k requests per hour to this endpoint". No problem, say we. I suppose making all 20k of those requests within the first minute and then waiting for 59m to do another batch still counts?
second-system effect[edit]
The second-system effect (also known as second-system syndrome) is the tendency of small, elegant, and successful systems, to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.
coined in the mythical man month(?).
habitability[edit]
Habitability is the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently.
from a Richard Gabriel article.
a 100% problem[edit]
It's what I call the 100% problem. To be secure, you need to sanitize 100% of your inputs. To be insecure, you need miss only 1. Humans don't do anything right 100% of the time, so if you have a hundred million inputs across a million applications, well, you're going to have some vulnerabilities.
bloatware[edit]
The more resources our computing platforms provide, the more bloated and complex software becomes: expanding to fill it.
second system syndrome[edit]
The second-system effect (also known as second-system syndrome) is the tendency of small, elegant, and successful systems, to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.[1]
The phrase was first used by Fred Brooks in his book The Mythical Man-Month, first published in 1975. It described the jump from a set of simple operating systems on the IBM 700/7000 series to OS/360 on the 360 series, which happened in 1964.[2]
learned it from https://rwtxt.com/rwtxt/about
abstraction without regret[edit]
Popularized by Tiark Rompf. Abstract may sometimes cause regret in e.g. interpreter overhead, but other techniques (like staging) can be used to abstract without regret. What are some other situations where abstract without regret takes some extra effort?
- A case study in abstraction without regret https://www.cs.purdue.edu/homes/rompf/papers/rompf-icfp15.pdf
path dependence[edit]
Path dependence explains how the set of decisions one faces for any given circumstance is limited by the decisions one has made in the past or by the events that one has experienced, even though past circumstances may no longer be relevant.
rewritis[edit]
A disease in which one becomes desperate to rewrite an entire codebase from scratch.
software erosion[edit]
Software erosion: It seems that what happened to Quake codebase has started to happen with Quake 2: You cannot open the workspace with Visual Studio 2010. You will need to use VS 2008 :(.
from http://fabiensanglard.net/quake2/index.php
principle of least power[edit]
use the least powerful thing possible. e.g. regex to tokenize instead of a CFG.