Alternate Reality Kit by Randall Smith at Xerox PARC 1986 (VPRI-0131)

Yoshiki Ohshima regularly posts interesting "new" videos on his youtube channel[1]. Not only Alan Kay's talks but content produced in PARC back in the day, or relevant people around that environment. If you need a less abstract teaser before getting into the talks and "philosophy" part of the game, here's a demo of something called "Alternate Reality Kit"[2] back in 1986. Brace yourselves. 1. [LINK] 2. [VIDEO]

There is more to visual programming than simple wire diagrams and "code-blocks-as-visual-blocks": [LINK] [VIDEO] [LINK] [LINK] And yes, this: [LINK] This is not 100% real programming, because it does not include sensors, but you do create constructs that interact with the environment and accomplish goals. It's close enough to show what's possible with certain interfaces. Long-term: [LINK] There have been much fewer resources allocated to the development of these concepts. Mostly for historic reasons. The sad reality is that both critics and proponents of visual programming are often uninformed about prior work, user studies and related research rooted in cognitive and developmental psychology.

The reason people still care about Unix pipes is because you can take a bunch of arbitrary commands and string them together in a way that produces some useful results. Moreover, you can configure each pipe to do different things depending on what you need at the moment. What stops you from stringing together a bunch of arbitrary objects to achieve the same effect? Well, a bunch of things: 1. Verbose syntax of the language. 2. The need to compile new code. 3. Early binding that stops you from calling things you don't know about before compiling code. 4. The fact that objects can't just take arbitrary method arguments. #1 is self-imposed. #2 is solved by JIT compilation and some other technique. #3 is not a problem in dynamically typed languages. Most importantly, #4 is explicitly what polymorphism in OOP was supposed to solve. Poly = many. Morphos = shapes. The idea that the object adapts to the messages you send it. With this in mind, ls -a | grep “gear” can be interpreted as code that does the following: 1. Send the object representing 'ls' a message with -a argument. This will supposedly construct a list. 2. Send 'grep' object a message with "gear" argument. This will construct a configured grep instance. 3. Send response from #1 as a message (or stream of messages) to #2. This will generate a filtered list. 4. Send the object resulting from #3 a message that would request a console-friendly representation (e.g. a string with codes for color in console). 5. Display #5. Thi

Sounds more like "the challenge of using a mish-mash of non-integrated tools with no interface". Developers could definitively solve this by moving away from 70+ year old abstractions (files, terminal) towards things more in line with Smalltalk ideas. But I guess it's better to make thousands of beginners suffer each year, instead of admitting that the current way of doing things is conceptually flawed and outdated. [VIDEO] [LINK] [LINK] [LINK] (And no, there is nothing special about copy-pasting commands and Unix pipelines that cannot be easily recreated in UI if the UI is designed to be programmable. )

In 1986 people wanted to make real programming more like a computer game: [VIDEO] Today, when we have much more computational resources, I'm reading this article about representing Factorio as static text with compiler checks. Something somewhere is off.