> I still like to convince myself, though, as to why this approach makes sense over the traditional OO / encapsulation approach.

I've become a 100% believer that Values are preferable to Objects & Encapsulation, full stop. However, I don't think that means you abandon objects, state, encapsulation 100%. I think that just means that you minimize them significantly.

I just watched a talk by Stuart Halloway [1] on Datomic where he makes a little "play at home" fill in the blanks table of design decisions and implications. He makes the assertion that if you take "program with values" to be the only given filled in table cell, you can make some arbitrary decisions for one or two other spots and the rest of the spots will fall out trivially with interesting properties. I guess the point is that programming with Values just affords you so much freedom and flexibility.

[1] http://www.infoq.com/presentations/Impedance-Mismatch

I agree with the trend, and also with the sentiment around interfaces.

Mutable/encapsulated approaches(which don't end at OOP, but rather continue into language design) act to define protocols. Protocols have a necessarily stateful nature; in the best case, the state is a single value at a single time, but in many real-world situations, state change events are frequent and need careful attention. Source code itself tends to need hundreds of changes to reach application goals, regardless of the language.

Functional and immutable style, on the other hand, acts on processes that are inherently computative, and this is the "nitty gritty" of most business logic. Even if the system is designed in an imperative fashion, it can bolster itself through a combination of a few "key methods" that apply functional style, and a type system that imposes a substantial amount of immutability.

The tricky part with OOP as we know it is to recognize when you're making a protocol, and when you're making an immutable computation. Many of the OO type systems used in industry lack the expressiveness to distinguish the two, and rush the natural life cycle of the architecture by imposing classes too early.

I don't really get it. From the blog post, Granger is describing a very imperative object system, but you seem to be claiming that it is somehow a value-oriented functional system. What am I missing?

That's a good question - there are still objects, or groupings of data, and even tags that identify which behaviors or functions apply to them in various contexts. What strikes me as different is the entire hierarchy is a nested data structure that is easy to reason about and modify at runtime without the use of a fancy debugger. The use of 'encapsulation' that hid the underlying data in each grouping and also bind functions / methods directly to each object in this case would only make it harder to work with. Why? Because to view, construct, augment at runtime or serialize the hierarchy would require constructors, serializers, deserializers etc, instead of having something that is just a data structure, ready to be viewed, put on a queue, sent over the wire etc.

The idea of 'behaviors' also provides flexibility in what functions can act on any grouping of data - the key value pairs needn't be associated with a 'class' which dictates what the associated functions will be adds more flexibility. As the author hints, there are other ways of achieving this agility - dynamic mixins.

Finally, while having a well defined protocol (or API or endpoint or whatever you want to call it) is valuable and helps organize code, I think taking this idea to the extreme and saying that every single object or piece of data you pass around as arguments or return values from these end points needs to be expressed as an abstract protocol itself is where you really start to lose. An expected format of the data structures of the arguments and return values can and should be part of an API, but needing to wrap them in objects doesn't really help - and that's where this trend I speak of begins to seem like progress to me.

This is quite the standard dynamic languages argument, I'm not seeing much new here but this wasn't meant to be new. However, my point is that this is heavily object-oriented and heavily imperative. It is just a different kind of object system that people might not be used to. If this ever catches on, we'll just need another Treaty of Orlando to re-harmonize the object community.

To be honest, a lot of the object system seems to be confused and muddled. I mean, there are a million different ways to get the kind of flexibility in what the author call "behaviors" (a term incredibly overloaded, BTW), protocols, traits, type classes, etc...dynamic mixins are nothing new here also (I've designed a couple of research languages with dynamic mixin inheritance, fun stuff).

As an academic, I want to see reasons why X was chosen and comparisions with previous systems that chose Y instead; but I know I won't get this from most of the people who do the interesting work in this field, so I have to figure it out for myself. Calling this an object system opens up a floodgate of related systems that I can compare it against.