Perhaps I can help you avoid talking past each other. On Mon, Jun 13, 2011 at 11:35 PM, Julian Leviston <[email protected]> wrote: > On 14/06/2011, at 1:50 PM, C. Scott Ananian wrote: > >>> When you're about to type the next "tile", you're given options... anything >>> outside of those options is impossible, so the computer doesn't put it in, >>> because syntactically it wouldn't make sense. >> >> There's nothing specific to tiles in what you wrote. You could do the >> same just as easily with a keyboard-based system. >> This is what I mean when I say that "tiles prevent syntax errors" is >> not accurate; it's confusing two separate things. >> Again: more accurately you could say, "strong typing can prevent >> syntax errors"... tiles have nothing to do with it, really. > > Assuming a "compile after composing" type of system. If it's a running, live, > system, then "type" is irrelevant because an "object" at the point of being > "talked to" will provide its own semantic and therefore > syntactic-appropriateness context (ie duck typing for want of a better term). > Do you see why I think text-stream based systems are outmoded crappy systems > yet?
The "strong typing" Scott is talking about is the equivalent of the snap-together shapes on the tile edges. Another equivalence is the choice-list of options you may be presented in an IDE. Both constrain (or guide, in the case of code-completion) your options based on the "type" of the interaction. Without some kind of type information there is no meaningful way to constrain the options, graphical or otherwise. Hopefully, I haven't misrepresented either of you, or added my own confusion to the conversation. [snip] > Instead of having actual one-level-linked instantiated objects AT THE POINT > of programming, we use multi-layered deferred referencing (ie text-stream > based "codes" which are later processed and further decoded into computer > codes by another computer program many times). One perspective on designing in solution-space is to visualize the object (or actor) instances and their interactions during the evolution of a computation. For me, syntax follows structure. That is, I first think about the objects and their connections, both static and dynamic, in a sort of general nodes-and-edges graph structure. Then I try to map the graph into a linear textual representation. The result is often frustrating, since linear streams of characters make some graph structures awkward to express. I expect that direct visualization of the object graph would be helpful here. On the other hand, I find that the behavior of the objects (actors) is easier to grasp in a compact textual representation, even though the behavior description has its own (fractal?) graph structure. In any case, the graph structure carries no type information. It is just a reference/reachability graph, constraining potential communication (a reference is required for interaction). The content (type) of the communication is not constrained. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
