Lambda the Ultimate

I kinda like Audrey Tang's rule of thumb:

Things interacting in a small number of simple ways (anything)
Things interacting in a large number of simple ways (OO handles best)
Things interacting in a small number of complex ways (FP handles best)

Things interacting in a large number of complex ways what you need is a lot of small mostly independent programs loosely coupled. Generally a dynamic glue between the various pieces, and those pieces written as per the above.

In her original version it was VB for the interfaces, Haskell for engines and Perl for glue.

His point (though I think a bit too general) is a good one, "Most computing models treat computation as the expensive resource, it was so when those models were developed! Today: computation is free it happens “in the cracks” between data fetch and data store Data movement is expensive both in time and energy."

His solution was pretty interesting, having controllers that allow for messages to be sent by descriptor or name:
i.e. Dec13th version of Oslo talk or
Most recent version of Oslo talk.

And then combining that with something like distributed version control... I'm not sure how you would handle the merge problem but the idea is fascinating.

This is a strange example of idea that, out of context, is somewhat convincing, but loses most of its ground when rephrased into the context of the talk.

Here is the argument of the speaker :
- Indeed, objects with inheritance can be encoded with functions and explicit open recursion
- but functions are less modular because you have to plan ahead parameter changes

This strikes me as a bogus claim. With the usual encoding of objects as a tuple/record of functions, each taking a "recursive" self parameter to model open recursion and dynamic dispatch, *you don't have to plan ahead*. You just need to add a new function/method somewhere, and call it through the self parameter in any place you wish. There is no plumbing as he claims because the plumbing is already done through `self`.

And this is perfectly natural, even obvious in retrospect : if you faithfully encode object plus inheritance in lambda-calculus, you get something which has just the same properties, with the same behavior wrt. code evolution, and also the same drawbacks wrt. difficult static reasoning due to the multitude of hard-to-specify extension points.

You could attack the idiomatic functional style to be somewhat different wrt. code evolution than the idiomatic object-oriented style. That's certainly true (new data vs. new operations, etc.; that's what JeffB is talking about in his reply). But attacking the functional translation of object-oriented style is bogus.

.

That said, I was rather pleased by the talk. There is a lot of historical research and the general idea that it's interesting to know about what people have done, in which context, etc. This is good. The technical content is quite fuzzy and wide-ranging, with suggestions rather than solutions, but could be considered thought-provoking.

There is a lot of whining about "complex time systems" in this talk that I felt somehow misdirected (all the more when you advertise programming style that do have more-complex-than-necessary behavior, bringing necessarily more complex static reasoning on the table). But I do not wish to start yet another static-vs-dynamic debate in this thread.

There is a funny idea that "object-oriented abstraction can exist without types" (around slide numbered 52 in the presentation and 92 in my PDF reader). He reuses the ADT (abstract data type) vs. Object distinction : one common but private implementation/representation of all ADTs element, vs. potentially different internals for objects of the same type/interface. His idea is that ADTs need a data representation (algebraic data type, concrete data) to benefit from the common representation, and therefore require type hiding to be effectively encapsulated. On the contrary, objects don't/can't/shouldn't expose their internals to each other, so can expose themselves as basically closures, black boxes, codata, that we aren't inspectable even in presence of type information. That's the usual remark that you can hide private state inside a closure (and you don't need existential types for that).

Before the final "concurrency, distribution, fault tolerance" pitch, there are a few statements that I found troubling.

Core Ideas of SIMULA
[...]
The actions and interactions of the objects created by the program model the actions and interactions of the real-world objects that they are designed to simulate.

I know that I have succeeded as a teacher when students anthropomorphize their objects

Another bit that is both weird and nice :

Algol 60 and Simula:
- Dahl recognized that the runtime structures of Algol 60 already contained the mechanisms that were necessary for simulation.
- It is the runtime behavior of a simulation system that models the real world, not the program text.

[...]

The Value of Dynamism:
Smalltalk is a “Dynamic Language”
Many features of the language and the programing environment help the programmer to interact with objects, rather than with code

Proposed definition: a “Dynamic Programming Language” is one designed to facilitate the programmer learning from the run-time behavior of the program.