> 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.
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
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.
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.
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.
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?
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.
The comparison still holds true. Plus I like the contrast with the modern analogy of a thread.
http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
> 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.
Probably my biggest regret is how long it took me until I realised how important Engelbart was. I'm reading through his report now.
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...
Shut it down, go home everybody. We've hit peak HN.
It would be the most amazing thing in my life to date :)
Yes the original browsers from 1969 might not still survive but the websites do. :)
https://en.wikipedia.org/wiki/Teletype_Model_33