Yoshiki Ohshima (大島芳樹)
1 HN recommender · recommended in 5 months, 2018–2021
11:54 · 4.1K views · Apr 18, 2016
A 12-minute demo of the Alternate Reality Kit, built by Randall Smith at Xerox PARC in 1986. It is a simulated physical world in which users manipulate objects and program by direct interaction.
HN cites it as early evidence that visual and interactive programming can go well beyond wire diagrams, in a Smalltalk and Alan Kay tradition.
5 comments from Hacker News
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. this video
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
There is more to visual programming than simple wire diagrams and "code-blocks-as-visual-blocks": [LINK] this 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.
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. this 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: this 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.