On Wed, Aug 28, 2013 at 5:57 PM, John Carlson <[email protected]> wrote:
> Multi-threaded Object-Oriented Stack Environment ... MOOSE for short. Would you mind pointing me to some documentation? I found your document on "A Visual Language for Data Mapping" but it doesn't discuss MOOSE. From the intro thread, my best guess is that you added objects to and arrays to your RPN language? But I'm not sure how the multi-threading is involved. > Also check out VIPR from Wayne Citrin and friends at UC Boulder. Also > check out AgentSheets, AgentCubes and XMLisp while you are at it. Not far > from SimCity and friends. Also looking at videos from unreal kismet may be > helpful if you haven't already seen them. I've now checked these out. I am curious what led you to recommend them. To clarify, my interest in visual programming is about finding a way to unify HCI with programming and vice versa. To make the 'programmer-model' a formal part of the 'program' is, I now believe, the most promising step in that direction after live programming. As I described (but did not clarify) this enables the IDE to be very thin, primarily a way of rendering a program and extending it. The bulk of the logic of the IDE, potentially even the menu systems, is shifted into the program itself. (While I am interested in game development, my mention of it was intended more as a declaration of expressiveness than a purpose.) Croquet - with its pervasively hackable user environment - is much closer to what I'm looking for than AgentCubes. But even Croquet still has a strong separation between 'interacting with objects' and 'programming'. Other impressions: VIPR - Visual Imperative PRogramming - seems to be exploring visual representations. I was confused that they did not address acquisition or assignment of data - those would be the most important edges in data-flow systems. But I guess VIPR is more a control-flow model than a data-flow. One good point. made repeatedly in the VIPR papers is that we need to avoid "edges" because they create complexity that is difficult to comprehend, especially as we zoom away from the graph. I do like that Kismet is making reactive computation accessible and useful to a couple million people. > > I think you should replace stack with collection > I could model a number of different collections, within the limit that it be constructed of products (pairs) to fit the arrowized<http://en.wikipedia.org/wiki/Arrow_(computer_science)>semantics. So far I've modeled: * one stack (operate only near top - take, put, roll; no navigation) * list zippers (navigational interface in one dimension: stepLeft, stepRight) * tree zipper (two-dimensional navigation in a tree; up, down, left, right) * list zipper of stacks (stepLeft, stepRight, take, put, roll) * named stacks via metaprogramming (ad-hoc navigation: "foo" goto) The tree-zipper is the most expressive I can achieve without metaprogramming. The more expressive collections, however, are not necessarily "good". After building the tree zipper, I couldn't figure out how I wanted to use it. Same for the list zipper, though the 'hand' concept serves a similar role (take and put instead of stepLeft and stepRight). For a list of anonymous stacks: I tend to stick around on one stack for a while, and forget the relative positions of other stacks. That's why I eventually went for named stacks. > > Have you considered controlling stacks, program counters and iterators > from the same basic metaphor? We used recorder buttons. Forward, Reverse, > Stop, Fast Forward, and Fast Reverse. Then undo (delete previous > operation) and delete next operation. [..] You'd probably want to add copy > and paste as well. [..] Along with the recorder metaphor we added > breakpoints which worked travelling in either direction in the code. My language doesn't have runtime stacks, program counters, or iterators. But I've mentioned viewing and animating parts of the compile-time history. > I know you can make a recipe maker with a recipe, but who decides what a > recipe makes? Another recipe maker; you need to bootstrap. Can you make more than one type of thing at the same time? Can a human > make more than one type of thing at the same time? Or a robot? Living humans are always making more than one type of thing at a time. I mean, unless you discount 'perspiration' and 'CO2' and 'heat' and 'sound' and a bunch of other products I don't care to mention. I imagine the same could be said for robots. ;) Humans can do a lot once it's shifted into their subconscious thoughts. But their eye focus is about the size of a dime at arms length, and they aren't very good at consciously focusing on more than one problem at a time. Robots, however, are only limited by their mobility, sensors, actuators, processors, programming, and resources. Okay... that's a lot of limits. But if you had the funds and the time and the skills, you could build a robot that can make more than one thing at a time.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
