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.
Why Hacker News points people here: HN cites it as early evidence that visual and interactive programming can go well beyond wire diagrams, in a Smalltalk and Alan Kay tradition.
“here's a demo of something called "Alternate Reality Kit"[2] back in 1986. Brace yourselves.”HN comment, 2018
“here's a demo of something called "Alternate Reality Kit"[2] back in 1986. Brace yourselves.”
1986 demo of Alternate Reality Kit from PARC.
Full comment
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
Cites itgamblerNov 2018
“There is more to visual programming than simple wire diagrams and "code-blocks-as-visual-blocks"”
Prior work showing visual programming beyond wire diagrams.
Full comment
There is more to visual programming than simple wire diagrams and "code-blocks-as-visual-blocks": linkthis videolinklink 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.
Cites itgamblerApr 2019Full comment
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
Cites itgamblerJul 2019
Example of Smalltalk-style programmable interfaces.
Full comment
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 videolinklinklink (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. )
Cites itromanivFeb 2021
“In 1986 people wanted to make real programming more like a computer game”
1986 example of making programming feel like a computer game.
Full comment
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.
