Alan Kay Thesis: The Reactive Engine (1969) | Hacker News Reader

Alan Kay Thesis: The Reactive Engine (1969)

chilton-computing.org.uk

149 pointsgjvc28 comments

> Babbage owned what was probably the first instance of computer graphics, a woven portrait of Jacquard in silk done on the parametric loom whose resolution (1000 threads to the linear inch) approached that of the very best devices today.

The comparison still holds true. Plus I like the contrast with the modern analogy of a thread.

Then it may as well be first instance of 3d printing.

Embroidery machines and automated looms absolutely are the first instances of 3D printing; they just don't get a lot of credit for it because we've been doing it so long and textiles aren't an "exciting" field to a lot of people.

in "The Difference Engine", Lovelace & Babbage's work is accelerated and cinemas show movies with giant screens made of programmable-cloth with coloured rotating beads as pixels

Wow, that's a neat find, it's almost a book. FLEX was heavily influenced after Alan Kay saw 'The Mother of All Demos' and a lot of the elements in FLEX made it into Smalltalk.

http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

I think it was more everything that Engelbart stood for together with his report on Augmenting Human Intellect rather than the demo alone.

> This was in early 1967, and while we were pondering the FLEX machine, Utah was visited by Doug Engelbart.

> ...

> An entire conceptual world and world view [Engelbart 68]. The impact of this vision was to produce in the minds of those who were “eager to be augmented” a compelling metaphor of what interactive computing should be like, and I immediately adopted many of the ideas for the FLEX machine.

I don't think it is possible to see the Mother Of All Demos in any way separate from the person of Doug Engelbart and what he stood for. Biggest regret of my professional life, I had the opportunity to meet him in 2000 or so and didn't.

For the rest of us I agree, but I think Alan Kay was much closer to his work. From the Smalltalk history he'd met Engelbart in 67 a year before the demo.

Probably my biggest regret is how long it took me until I realised how important Engelbart was. I'm reading through his report now.

A friend of mine was a friend of his, and gave Doug space to work. Both are dead now so it's never going to happen but spending time on reading up on Doug Engelbart is a very good investment.

Douglas Engelbart was a giant amongst giants.

Great quotes, like I wish to God these calculations were executed by steam... C. Babbage, The Analytical Engine

Where's the Reactivity? The thesis is entitled "The Reactive Engine", yet I don't see any reactivity in the system— at least not as I know the term now. What am I missing? Or has "Reactive" changed its meaning over the years?

If I understand correctly, the reactive part is the fact the user gets output after providing input

So what we would call interactive?

A bigger deal at the time than it is today.

This term is being used like this in other places as well, for example reactive vs. proactive agents.

Ahh, my pet peeve. Glad someone else brought it up.

Yes, "reactive" has changed meaning, dramatically. Or maybe not so much "changed" as become overloaded and muddled as to be almost entirely ill-defined/meaningless nowadays.

What is called "reactive" today tends to be a dataflow-ish programming style, usually unnecessarily embedded in and permeated with FP tech and terminology.

This goes back to Lucid[1], "The Dataflow Language", and then via the synchronous dataflow languages Esterel (imperative) and Lustre (functional) to Microsoft's Rx extensions, though Erik doesn't advertise the link unless pestered (I pestered).

Esterel is successfully used in avionics, for example at Airbus. Part of what makes it attractive is that the synchronous dataflow networks employed can be compiled to efficient state machines that have deterministic/provable latencies, which is is nice when controlling airplanes :-)

That's also where the term "reactive" came from: it describes the types of systems that these languages were useful for, using the definitions from David Harel (the statecharts[2] guy):

1. Transformative 2. Reactive

In this classification, reactive systems are those that have to interact with the world, and the world cannot wait, a superset of real-time and interactive systems (though that is a bit fluid, with a separate interactive category for when the world can wait).

So synchronous dataflow languages had certain properties that were beneficial for reactive systems. In the translation to Rx, that property of the systems built using the tech was somehow transferred to the dataflow-ish tech itself. Which is a bit odd, because while the synchronous dataflow tech can be useful for reactive systems, there are lots of other ways of successfully implementing reactive systems. OO springs to mind, where reactivity is built into the fabric of the paradigm (objects react to messages sent to them).

And of course another wrinkle is that most of the FRP/Rx technologies are just datadflow-ish not actually synchronous dataflow, so the characteristic that made the synchronous dataflow languages useful for reactive systems is not actually present. Meaning the already very tenuous link is broken.

Another branch is (Conal) Elliot and Hudak's "Functional Reactive Programming", which explored what would happen if, unlike the normal sequences/collections, which map N->values, you'd instead map R->values. A lot of the current FRP community claim this as their starting point, an idea strongly disputed by Conal. So "FRP" has very little to do with FRP. If that weren't enough, Conal (rightly, IMHO) no longer thinks FRP is a good name for what he did.

[1] https://en.wikipedia.org/wiki/Lucid_(programming_language)

[2] https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/res...

It’s amazing that such simple websites from 1969 survive modern browsers, yet Facebook cannot fix zoom on Safari...

The paper was written in 1969. HTML wasn't even conceived until the 1980s. The paper could have been digitized as recently as this morning.

Something to be said for digital text that will last vs what is lost due to evolving display standards

> It’s amazing that such simple websites from 1969 survive modern browsers

It would be the most amazing thing in my life to date :)

> It’s amazing that such simple websites from 1969 survive modern browsers

Yes the original browsers from 1969 might not still survive but the websites do. :)

All zero of them.

> It’s amazing that such simple websites from 1969 survive modern browsers, yet Facebook cannot fix zoom on Safari...

Shut it down, go home everybody. We've hit peak HN.

I think I liked the old 1969 browsers better than the ones we have today:

https://en.wikipedia.org/wiki/Teletype_Model_33

Probably has better keyboard and lower latency than iTerm2.

Any website from 1969 is probably a website that has some bugs in its date and time handling code...

At least their SSL certificates will not expire for a couple of decades.

Reply on news.ycombinator.com