Great stuff as usual: inverse vandalism, confusing means to an end with an end, system programmers are high priests of a low cult, if you're not failing 90% of the time then you're not trying hard enough, science is a set of heuristics to get around buggy brains, etc.
Agreed. Just finished watching this. It's definitely worth spending an hour of your morning on listening to what these two giants (mostly Kay) have to say.
I love his work, and the ones that worked with him.
After learning Smalltalk, Oberon and Modula-3, I started a journey into the world of Xerox PARC and their influences into ETHZ and DEC research labs and became amazed how computing could have looked like already by the mid-90's.
To the point using UNIX stopped being fun, I wanted one of those environments, not a PDP-11 replica.
All these are "slogans" aimed at lightning up broken minds.
And "we" resonate with them i.e. we really have broken minds.
Taking this talk seriously means getting together, working hard at making computer science a... science. Finding problems worth solving not solving problems we can solve (or worse, that we do not/should not have).
How hard it is to do that with broken, insulting, narrow minded (autistic to some degree) and violent minds (think of high priests of lower cults)?
The fact that these ideas did not take off (or wrongly: Java, "modern" GUI that initially targeted 8yo children, iPad which is a lying Dynabook) makes you wonder: despite the obvious and useful function that computation could satisfy, i.e. infusing the most powerful ideas into young children & advancing these ideas:
What in the world is holding us back?
Can we break loose?
Well that is the default state of human affairs in general. Even Kay mentions that he was in a funk and hearing these great ideas from others and then putting them into slogans is what helped him repair part of his brain damage. Inventing the future is hard work, not everyone is cut out for it.
I don't think having a negative spin on having a buggy brain is the constructive approach. Avoiding the pop science is really the key point Alan Kay keeps going back to. Learn from the elders, there is much wisdom in the history of computing.
> "I don't think having a negative spin on having a buggy brain is the constructive approach."
I disagree.
Having a "negative spin" is precisely what we need.
We mostly do not even understand that we are stuck in a "Pink plane" (see Alan Kay videos for Pink|Blue plane definitions).
Result: stagnation with more or less identical "paradigms" (see [1]) for more than 50 years (FORTRAN?).
Computing can do much better than Facebook or Google... where is my Dynabook?
I've just seen the movie after your comments, it was interesting to see that they use emacs (without syntax highlighting, it appears..). OT, but how's vim for coding in erlang, anyone?
How so? It's a solid piece of software which has been around since forever (since before Ctrl-C and Ctrl-V conventions ever existed). We're all programmers, and Emacs is all about being a programmer's editor.
If you want to see an Emacs-user out-hipster every single web-developer who thought he was cool when he used HTML for his presentations instead of Powerpoint/Keynote... Then watch this: https://www.youtube.com/watch?v=TMoPuv-xXMM
It's incredibly contrived, and incredibly nerdy, yet this, to me, encapsulates so much about what Emacs is. And I love it :)
I had to check and according to https://en.wikipedia.org/wiki/GNU_Emacs , font-lock was added in version 19.28 released November 1, 1994. The movie certainly looks like it was recorded in the 80s.
Some people also still use Acme which AFAIK does not have syntax highlighting.
Can someone explain to me Alan Kay's problem with monads in functional programming? He attacks the monad concept several times in this talk rather cryptically.
I obviously can't tell you what he's thinking, but I can make an educated guess:
In the video (and almost anywhere else you look) you'll note he talks about recursion on the concept of "computer" as a way to scale, because that way the parts are as powerful as the whole.
If you split that concept into the sub-notions of "procedures" and "data", you no longer have that recursive principle, and "functions" in this context are sufficiently equivalent to procedures.
Going the other way, functions don't really scale up, many if not most things in computing are not functions to be computed. One could argue that computers and "computer science" are misnamed, as computation is more the exception than the rule. "Data-around-shufflers" would be more appropriate.
I didn't see the exact monad references, but they look like ways of working around the fact that the "function" primitive is inappropriate. It is really nice, mind you, and has wonderful properties. Kind of like circles as the basis for astronomical orbits: they are "perfect", but the world isn't perfect in the same way, so trying to model the imperfect world with these perfect primitives leads to having to introduce epicycles/monads.
> "Data-around-shufflers" would be more appropriate
In the French language we have "calculateur" which is the direct translation of "computer" but only commonly used in the context of scientific computing, and "ordinateur" which is the common name for computers... The meaning of "ordinateur" pretty close to "data-around-shufflers", from latin ordino (“to order, to organize”) - https://en.wiktionary.org/wiki/ordinateur: "in its application to computing, [ordinateur] was coined by the professor of philology Jacques Perret in a letter dated 16 April 1955, in response to a request from IBM France, who believed the word calculateur was too restrictive in light of the possibilities of these machines (this is a very rare example of the creation of a neologism authenticated by dated letter)"
Great point! Due to the latin origin as you mentioned, in spanish there is this too: Ordenador. Would be more or less: "sorter" (implying that it does that to data). Very likely influenced by Perret's coined term translated to spanish
Monads are the way to hide the fact that state change. Basically they allow you to abstract away the concept of time.
Alan Kay seems to push more in the direction of data as CRDTs or fully vector clocked, so that time is just an additional way to referenced some data.
It is close to the idea of separating time from space or to combine them in two.
In CS, we tend to consider a static vision of the world, and a function applied to it. When the truth is that the world exist at different time and is wildly different at each of this time. So a piece of data would be defined by its place in memory and the clock time (vector clock) it was in that memory. Closer to what CRDTs does in a way.
Another way to put it, with monads (or more generally FP) there is a separation of functions and data. With objects data is hidden behind procedural interfaces.
I'm not familiar with CRDT, can you compress the idea of how to "remember" a whole history of states with them and why are vector clocks important? The introduction on wikipedia reads like they are useful for (geographically) distributed processing. I can't really relate or contrast this to monads.
The problem with distribution is that things can happen simultaneously (or at least before the latency enable you to decide who is first), so your goal would be to be able to recreate an history despite that asynchronicity.
That is what Consistency in the CAP theorem hint at.
The whole idea is that if you define things not only by their state but also by the order this state has evolved, it enable you to know what is the most recent one but also to go back in time. It is especially useful if someone come late after you updated the state and you discover that their update should have happened before the most recent change in state.
Forget that idea of data being hidden behind procedural interface.
Another way to put it :
You have a Dog that is dirty at 1600. So you decide to clean him and put him in a bath. He is now clean at 1610. Now you have another person (thread? computer? no idea) that come at 1620 and got the order to clean the Dog at 1550 because someone saw he was dirty. The person do not ask if the dog is dirty or not. He got an order and do it. You now have a dog that is being cleaned again.
With Alan Kay point of view, there would not be a single dog with his single name. But a dog which name would be defined by his name and the moment you named it. So when the person that saw that the dog was dirty at 1550 and decide to clean him at 1620 when he was already clean would come to clean the dog, it would take the dog1550 and not the dog1620. So he would clean a dirty dog and not a clean one.
He would be in another legs of the Trouser of Time.
No problem, i think more people should look at the problems with time. We tend to not deal with it due to only doing single threaded synchronous stuff, but it is not how the future is going to be, nor the world it seems. So better learn now :)
Don't know his or your context, but McCarthy is the creator of Lisp, so in a way he's one of the pioneers of functional programming (there were of course other mathematicians inventing the foundations). Which is a way to combine programs from small building blocks that are just functions knowing no global state - they always return the same answer given the same arguments.
Contrast this to procedural or object oriented programming where usually the parts know a lot more about the context (state) than they really need to know. This can lead to implicit (and hard to discover) assumptions about the state of the world that are broken later on when some parts are changed, leading to bugs.
The way this works is by combining functions with (higher order) functions. For example, chain a function that gets A and returns B with a function that gets B and returns C. This is done without ever speaking of concrete inputs - reducing unnecessary knowledge should lead to fewer bugs. (Whether that's a more practical approach is another question).
Lisp is built on OOP: all sorts of objects that have state and functions operating on it. For instance, an I/O stream, needed to do the "read" and "print" parts of REPL, is a stateful object.
Lisp is not only where functional programming originated, but also object-based programming leading to OOP. Lisp was the first language which had first-class objects: encapsulated identities operated upon by functions, and having a type.
For instance, an object of CONS type could only be accessed by the "getter" functions CAR and CDR which take a reference to the object, and by the "setters" RPLACA an RPLACD.
Meanwhile, the other higher level programming language in existence, Fortran, had just procedures acting on global variables.
There are other places in the Lambda papers and whatnot where they talk about objects, but I don't recall seeing that exact phrase. Of course, just what they meant by it is another question.
That's the wrong context :) He was talking about McCarthy's later discussion of what he called "situations", and is similar to temporal logic (which came later). Functional programming doesn't satisfactorily address the state change problem.
So data structures shouldn't be viewed as static, but indexed by time. Fair enough. I still don't understand how this couldn't 100% be achieved via state monads, or at the very least purely functionally.
My take is that from Kay's perspective computing is a mixture of mathematical and biological abstractions [he has degrees in both]. Monads only touch on the mathematical abstractions and ignore biological abstractions. My take is that Kay may be of a mind that absent biological abstractions computing is diminished in its ability to solve important problems.
The thing about biology is that it's had a ~3 bn. year head start. It's also massively contingent; see evolution by natural selection. Which means that it may not actually represent any kind of global optimum[1].
[1] EDIT: Or even a local one if you're not optimizing the same thing that biology is.
What happens at 38:25?
Joe: "This algebra you've made it's a Prolog program you just move a few brackets". And I went "oh my god". From that moment on I was not interested in Smalltalk anymore.
Alan: Yeah, nether was I! But...
I had the privilege to hang out with him at Abstractions this fall, where he gave the keynote. He was just holding court in the commons, shooting the breeze about halfwit management, project estimation, Jira tickets, and everything that hasn't changed since Brooks.
Then he asked which session we were going to next, so we all hit one about concurrency issues. It was jammed and came in late to stand in the back. The presenter bemoaned locking and inconsistency and got to solutions. He started with a slide on immutability and lightweight functional actors in Erlang, having solved it 30 years ago, and pointed out Joe, who got a roomful of cheers and laughs and validation for his work, in person.
I've never seen an interview with Alan Kay that I did not find fascinating.
I like Joe Armstrong, and he's brilliant of course, but he interrupted too much in places. But it seemed to be out of enthusiasm, so I can't really be bothered.
Their message is essentially: you are all in cults, learn old stuff and start using actors and message passing. And not CSP, as Alan Kay puts it - it's too rigid and gear like.
What I got from it:
- model time explicitly
- build computer systems to work at a galactic scale
- know that reality is distinct from your mental models ("the map is not the territory") and you will see the present more clearly. The essence of comedy, science, and art involves changing the models through which we view the world.
