Looking back on a lot of Alan Kay's writing, I've noticed that when he was young he tended to write extremely long winded explanations of what he was trying to do. As he got older, the explanations got more terse. Now he doesn't explain at all: he just asks a related question. In my mind, I don't think this is by accident.

I've been starting to go in the same direction. I'm prone to writing extremely expansive replies to questions (just see my posting history here ;-) ). Some people read it, but most will not. I found that while I lose some fidelity with a more terse answer, I get better traction from shorter answers. However, the audience I add by making my answers more digestible tends to interpret the answers literally -- meaning that they don't think past what I've written.

So I started wondering if replying with questions as Alan Kay seems to do now would be useful. It certainly has its advantages. Although it goes in the opposite direction of increasing your audience, if you feel that most people aren't going to "get it" anyway, perhaps that's not necessarily a loss. It also is a cue to say, "This is a complex issue and you need to go back and look at some fundamentals before you can understand the answer". Those people who aren't willing to do that, probably aren't willing to put the work into understanding the answer anyway. And finally, in the very likely case that my answer is not actually very good, asking a question instead allows the person to formulate a better answer than I can come up with. This latter bit is especially worth thinking about, I think.

But I've resisted doing that as it is certainly intimidating and in some ways makes you look like a jerk ;-). BTW, I recently read some of his comments on what it means to be "object oriented" and I tried my best to build a system based on what he said. The results were extremely illuminating for me. Whether or not it matches his view, I found that working hard on puzzling out his comments took me in valuable directions that I had not considered before.

I started out by deciding to write a blog post. Here is my rambling second draft: https://github.com/ygt-mikekchar/oojs/blob/master/oojs.org#r...

However, as I was writing this blog post, it became obvious to me that I needed something better than Shape/Rectangle toy explanations. I needed to build something real. So I decided to build a test framework.

Here it is: https://gitlab.com/mikekchar/testy

I wrote a quick explanation of the design I was using here: https://gitlab.com/mikekchar/testy/blob/master/design.md You can read that first if you just want to see what I was doing and don't want the long winded explanation of how I got there from the blog post.

While I was writing this code, I decided to make a coding standard for myself because sometimes it helps to add constraints to examine how things are working. The coding standard is here: https://gitlab.com/mikekchar/testy/blob/master/coding_standa...

I suppose TL;DR: Objects should not represent ADTs. Instead they hold state. The object is really a collection of operations on that state (bundled together to give you better cohesion). The state is encapsulated in the object and should be inaccessible except through the operations. Objects should probably be immutable as well -- especially as it enforces that encapsulation. The best way to think about it is that the object itself is a monad (and it literally is). The methods on the object are functions that you would normally pass to bind. The "." that does the dispatch is essentially bind. I found that I never actually reached for subclass polymorphism (even though it was easy to implement). Instead I used essentially traits and I think this is in keeping with the modern idea that OO should encourage composition over inheritance.

Why do this instead of FP? Well, as you can see, my code is really FP with "FP Objects". I think the thing I liked about this is the idea that the objects created a nice abstraction for cohesive code. It's not that different than type classes (and I always think it's funny that type classes are usually implemented with virtual function tables). However, it is slightly more restricted in terms of generic functions. In a system without static type checking, I think it's easier to reason about this code. YMMV.

In the end, I found this way of programming very enjoyable. The code is still quite crufty, so please don't judge me ;-) I was just writing it to explore the ideas. It's not production code.

I considered going on and finishing Testy and possibly building something else with that style of programming, but it turns out that all current implementations of JS are quite inefficient when using closures (and may even leak memory!), so I decided to work on something else.

If you have any questions or comments, feel free to fire away.

I have a lot of respect for Alan Kay too but what you're hinting at is something that's bothered me about him for a long time: his "solution" for almost every problem is for everyone to be as smart as his Xerox PARC dream team.

He's like the Phil Jackson of technology: sure he's deserving of a ton of respect, but he wouldn't win anything with the 2012 Bobcats. Well that strategy doesn't work with society at large. You've got to work with the people who are, not those you wish would be.