The contrast between function on the one hand and data on the other leads to two polar approaches to software design, namely, traditional functional decomposition (dating from the 1960s) and data-driven or entity-relationship decomposition (dating from the 1970s).
Objets occupy a middle ground; they have the tangibility and data content of an entity, but their outsides are defined by their function or behavior. This synthesis of data and function is what differentiates object-driven approaches from the other. – (Smalltalk Objects And Design, p 10)
I := Ward
I have to see the program working in my mind as I write. Modern scoping makes it easy to write little functions of local scope that say what I mean to do.
~
Of course, as soon as you start asking “does this object *do* the things I’m interested into?” you start getting into some places in mathematics that we don’t have answers for either (⇒ Extensionality). –– Quildreen Motta
~
A friend was amazed that I wrote functions *apr* and *may* in a test suite working with dates. Java's Date constructors are a confusing mess. I could say *apr(15)* or *may(26)* and get on with my business.
There is a confusion among programmers that the tools of their trade are to be applied only to their assigned problem. Every abstraction must be in service of the customer. With local functions I'm happy to abstract what I'm doing in the moment without any need to generalize beyond my immediate need.
Macros served this purpose for the assembly language programmer and have been raised to high art in lisp. I'm talking about something much simpler. **A handy function or two at the bottom of the page.**
Javascript seems to encourage this and coffeescript even more so. I chose tiny functions in the latter when rewriting programs I'd written in high school. See Craps Dice Game
.