There’s a slide that says
circle.grow(3) grow(circle, 3)
“Objects and methods” are syntax sugar for structs and procedures.
I use to agree: they are just syntax sugar, where “syntax sugar” imply something inconsequential or communicates a lack of importance.
But in recalling my stumbles learning Elm – and given the fact that the talk is about our we wish FP was the norm; winning market share – I think we should appreciate the difference from another angle: usability. Appreciate maybe why OOP (syntax) has even slightly more users because of that usability win.
Hey it all adds up right?
Affordance describes all actions that are made physically possible by the properties of an object or an environment. A bottle screw cap affords twisting. A hinged door affords pushing or pulling. A staircase affords ascending or descending.
So, in the code snippet above, what does the variable
circle afford us to do? and how does a programmer find out?
NOTE: Keep in mind that the variable could be of a less straightforward type than a
UnnormalizedMeterReading), or the programmer might be new to the codebase, or be the original author but had forgotten all the details after a hiatus.
What does an OOP programmer do? I’ll just type c-i-r-c-l-e-. and after that period
. my code editor will show a handy dropdown list of possible actions, along with documentation snippet, specifically catered for the variable:
circle. color(c Color) : set foreground color to c grow(n Integer) : increases diameter by n moveTo(x, y Integer) : place the circle on specified x,y coordinate
Contextual help. Perfect. Basically an equivalent in GUI would be the wizard dialog and its “next” “next” “finish” buttons.
NOTE: That’s in fact exactly what the Swift Playgrounds iPad app does. You can code without even bringing up the keyboard.
On the other hand, what does an FP programmer do? Assuming I can figure out what type the variable is, I’ll open the documentation in my browser, press
CMD-F and try my luck with “Find on page” with some guess words… say…
When you design user interfaces, it’s a good idea to keep two principles in mind:
- Users don’t have the manual, and if they did, they wouldn’t read it.
- In fact, users can’t read anything, and if they could, they wouldn’t want to.
The first step is admitting you have a problem.
“Can any function from any module that can receive this Shape value, along with any other arguments, please stand forward? Curried functions in the current closure?”
Maybe something for the code editor community to think about.
FWIW, the SQL syntax has the same problem too: you type
SELECT and wait there.. no code editor can help you very much since nobody knows what you are trying to select
FROM yet. If that syntax had just switcheroo,
FROM ... SELECT ... the more usable SQL syntax could’ve driven SQL adoption even higher ;-)
UPDATE: See also, Data exploration through dot-driven development