On Jul 16, 2012, at 6:22 AM, Julian Gamble wrote:
> Brian - I'm really enjoying the book updates - particularly the section on implementing your own OO paradigm. It got me thinking about how to capture and communicate the essence of the ideas behind it.
I'm fairly notorious for being averse to definitions. I grant that is emotional (definitions are so often a power play), but it's also reasoned:
* Every definition includes terms that must also be defined. It's easy to assume there's agreement on a term when there's not, and that often bites people in amusing ways. Even in technical topics, which lend themselves to precision (that is, to fewer and more controlled layers of definitional recursion), definitional clarity is very expensive to attain and (in my opinion) typically only repays its cost when you're doing something like writing a compiler rather than talking to people.
* Definitions are binary categorizations: a person either *is* or *is not* a "bachelor". An object either is or is not a chair. It turns out that categories in the real world are fuzzy and, for any class C, you often cannot find any set of properties such that all elements of C have all those properties of C and no elements of not-C have them all. (See /Women, Fire, and Dangerous Things/ and my own
http://www.exampler.com/testing-com/writings/pnsqc-2005-communication.pdf )
Because of that, I'm not so focused on capturing an implementation of a canonical object-oriented language, but rather on presenting a variety of implementations that let people who are familiar with one of N different variations on the OO theme say, "Wow! So that's how thing-I-care-about X can be implemented."
As far as book-writing goes, I'm somewhat inspired by the idea that effective knowledge is tacit knowledge (see my writeup of medical education at
http://www.exampler.com/testing-com/writings/tacit-knowledge.html and Fleck's /Genesis and Development of a Scientific Fact/) My hope is that by approaching a topic from many different directions, and providing many different exercises, readers will get a "gut feel" for a functional approach to programming without necessarily being able to define what that is (since I can't). That gut feel will nicely prepare readers to get useful ideas when they encounter lots of different approaches to FP (or OO).
The danger of my approach is that it can lead to a vague and unorganized smear of techniques and ideas and facts, without any framework that a reader can grasp. I'm grappling with that in Part 2, and I hope you readers will let me know if things don't hang together in a way you think gives you the ability to think practical-but-new thoughts.
-----
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
Occasional consulting on Agile