Programming Patterns

Programming Patterns (aka idioms). This is something that fascinates me, especially as a Forth programmer. But Forth isn't the only language that can benefit from hard documentation of various patterns. Haskell is loaded with them, and provides a formal notation (functions) for documenting them too. One need only look at foldr and unfoldr for examples. Programming patterns can exist at all levels, from assembly language all the way up to 5th-generation languages. In some sense, XP-style unit testing is a programming pattern. However, programming patterns usually refers to something a bit more microscopic. For example, Forth allows the programmer to directly manipulate the return stack, thus allowing the programmer to produce god-awful hard to read code that is hard to reason about, and which is fundamentally unstructured. But, sometimes, it can be useful and even enhanced the structure of code. For example, if you have a lot of words that you'd like to run twice (for whatever reason), you might wish your language to have an operator just for this purpose. A very simple and utterly contrived example might be:

 : twice:   r> dup >r >r ;

Why would anyone ever want to write code like this? The answer is clarity of purpose; one of the biggest benefits that XP provided the computer industry was the vindication of self-documenting software. Compare:

 : foo      twice: ." Hello World!" ;

with:

  : foo'    2 0 do ." Hello world!" loop ;

Yeah, it does the same thing; but, the latter just doesn't communicate the intent nearly as well, and takes a whole lot more typing. Again, the above examples are contrived, but does show the nucleus of what makes a great opportunity to document a programming pattern.

One observation I've personally made is that most programming patterns tend to abstract away iteration and recursion -- in other words, they tend to promote loop-free coding. This isn't to say that loops are bad things; but you have to admit, they do get in the way of understanding things that, to us wetware computers, is much easier to express in a couple of sentences than as an explicit loop. Contrast for all foos, convert them to bars with Let f be a foo. Given f, convert f into a bar called b. Stuff b into a list named bars. When you're done, return bars as a result. No comparison.

So, what programming patterns do you know about, and think would benefit by being documented?

---

List alphabetically here.

---

What is the relationship between ProgrammingPatterns, DesignPatterns and the metaphors discussed e.g. WhatIsMetaphor? -- JohnFletcher

---

CategoryPattern