It reminds me of some famous words from Alan Kay: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP."
Late-binding is to delay the decision of which concrete implementation to use. One could program in Java referencing many interfaces and bind those to concrete classes only during runtime. It could even change during runtime. I guess this last thing is what he meant by "extreme late-binding".
27:35 «the negative attributes of object orientation» Has Rich Hickey made a talk of wrote somewhere about the limits and issues of OOP? To know about what he is referring to.
I think he goes into it quite a bit in "Effective Programs: 10 Years of Clojure". Some key points I remember: 1. Coupling. He goes into how all these "verby" interfaces we construct create an intertwined and complex mess which is hardly reusable and hardly composable. The coupling might be loose but it tends to explosive among highly interdependent interfaces. I remember in one of his talks about how it's a great big lie that OOP promotes reuse and modularity. 2. Mutable state. This should be a given from a functional enthusiast but when combined with #1, it creates not only packages that are highly interdependent on each other but also the precise shared program state (temporal coupling, e.g.).
@ClojureTV - Can this video be renamed to the real talk title: "The Language of the System." The "TBD" bit was a placeholder joke and makes the video harder to find.
I just rewatched this. It's well worth it. And I thought, as he was talking about the concept of Interfaces at the system level...maybe GraphQL is something like that? I'm not super familiar with it, but it has schemas (which I think are in-band? I'd have to check), it's language agnostic, and it's extensible. I'm still not totally sure what he means by "generic processors and intermediaries," but it seems like it checks most of the boxes. Even if it's not 100% there, it's probably the closest we've gotten to something like a system-level interface. Thoughts? *Edit:* Swagger also offers something like an interface at the system level.
In the old DCE days, IDL was the technology for system building. DCOM also drew on this. Then came SOAP, then just http+whatever. Every generation invents a new systems infrastructure. With a growing number of javascript kiddies, JSON became popular (for no reason). Looks like now it's time for the next generation to get to work :) May I suggest an S-expression based interchange format, which just happens to also allow to move code to another node?
json schema can be interesting, sure, but interesting is also the degree of its adoption among the ones that do json: pretty low afaik. It's an example of out of band schema and the success it (the schema, not the format) can reach when is also originally out of the format itself. Rich makes the point of schemas being important, among other things, for enabling the case of generic processors and intermediaries. Which brings the question, are those the typical scenarios where json is used ?
I was just wondering "where does Unix model comes in" when he enlightened it :) I understand the pains of StringBuild'ing to communicate with other programs.
Now apart from Storm, we also have functional abstractions over flow, with reactive streams, Flink, Spark (not nicely composable over systems but still).
Fantastic talk by Rich Hickey on systems.
Love his analogies and the way he uses language.
Very inspiring, very worth watching.
It reminds me of some famous words from Alan Kay:
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP."
On the off-chance that you'll read this: what is local retention and late-binding?
Late-binding is to delay the decision of which concrete implementation to use. One could program in Java referencing many interfaces and bind those to concrete classes only during runtime. It could even change during runtime. I guess this last thing is what he meant by "extreme late-binding".
A transcript of this talk is available here: github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/LanguageSystem-mostly-text.md
"a new massively parallel, ...uhm... concurrent, ...uhm... AI-driven, ...uhm... ToDo list application."
27:35 «the negative attributes of object orientation»
Has Rich Hickey made a talk of wrote somewhere about the limits and issues of OOP?
To know about what he is referring to.
he did a few, but most is condensed in his "Are we there yet? " talk.
I think he goes into it quite a bit in "Effective Programs: 10 Years of Clojure". Some key points I remember:
1. Coupling. He goes into how all these "verby" interfaces we construct create an intertwined and complex mess which is hardly reusable and hardly composable. The coupling might be loose but it tends to explosive among highly interdependent interfaces. I remember in one of his talks about how it's a great big lie that OOP promotes reuse and modularity.
2. Mutable state. This should be a given from a functional enthusiast but when combined with #1, it creates not only packages that are highly interdependent on each other but also the precise shared program state (temporal coupling, e.g.).
@ClojureTV - Can this video be renamed to the real talk title: "The Language of the System." The "TBD" bit was a placeholder joke and makes the video harder to find.
1:40 "Ok, enough fucking around. Let's get real."
I just rewatched this. It's well worth it. And I thought, as he was talking about the concept of Interfaces at the system level...maybe GraphQL is something like that? I'm not super familiar with it, but it has schemas (which I think are in-band? I'd have to check), it's language agnostic, and it's extensible. I'm still not totally sure what he means by "generic processors and intermediaries," but it seems like it checks most of the boxes. Even if it's not 100% there, it's probably the closest we've gotten to something like a system-level interface. Thoughts?
*Edit:* Swagger also offers something like an interface at the system level.
In the old DCE days, IDL was the technology for system building. DCOM also drew on this. Then came SOAP, then just http+whatever. Every generation invents a new systems infrastructure. With a growing number of javascript kiddies, JSON became popular (for no reason). Looks like now it's time for the next generation to get to work :)
May I suggest an S-expression based interchange format, which just happens to also allow to move code to another node?
As an European I just love his subtle cynicism.
json schema can be interesting, sure, but interesting is also the degree of its adoption among the ones that do json: pretty low afaik.
It's an example of out of band schema and the success it (the schema, not the format) can reach when is also originally out of the format itself.
Rich makes the point of schemas being important, among other things, for enabling the case of generic processors and intermediaries. Which brings the question, are those the typical scenarios where json is used ?
I was just wondering "where does Unix model comes in" when he enlightened it :) I understand the pains of StringBuild'ing to communicate with other programs.
Now apart from Storm, we also have functional abstractions over flow, with reactive streams, Flink, Spark (not nicely composable over systems but still).
Thanks for renaming it!
I came here by grooveshark headers
FLOP > PLOP
Is a great idea.