4 ms·

Most of them don't use hierarchical data models, which is what we were discussing (I think?). Excel has one level of nesting (sheet.cell). Labview is a graph wh

by jamii 12y ago

Most of them don't use hierarchical data models, which is what we were discussing (I think?). Excel has one level of nesting (sheet.cell). Labview is a graph where components are grouped for reuse/abstraction. Access is relational(ish). TouchDevelop and Scratch are more traditionally hierarchical, with control-flow stacks and directed object graphs. I certainly wouldn't call Excel or Access 'inherently hierarchical'. Neither do I see the connection between 'visual languages' and 'inherently hierarchical' languages. If anything, the majority of visual languages I can think allow placing arbitrary computation at any point between arbitrary data sources/sinks. Where hierarchy exists it is usually fairly flat and used for organisation or code reuse. Arbitrary data-flow between any level or branch of the hierarchy is also a common feature.

dragonwriter 12y ago
> Excel has one level of nesting (sheet.cell). Excel has one level of nesting within a file, but Excel "programs" are not limited to a single file; and, in fact, Excel has features designed specifically for programs that require multiple files to be open at once to interact. Its true that each level of nesting in Excel is different in kind so that Excel doesn't support arbitrary nesting of namespaces, and that different bits of Excel functionality support different degrees of nesting.
seanmcdirmid 12y ago
Ah, I see. LabView supports objects, so its data model can at least be hierarchical there. But even if we ignore OO data models, I think even FRP (as pure data flow as we get) is hierarchical since components (and sub-components) can still encapsulate state. The only thing you really lose are aliases/implicit communication channels. Most visual data-flow languages follow this style. I would argue that relational is also effectively hierarchical if not intrinsically: even without nested tables you always have IDs tacked on in a column that refers to rows in other tables. And once you start doing that, well...object graph.
- jamii 12y ago
  > I think even FRP (as pure data flow as we get) is hierarchical since components (and sub-components) can still encapsulate state. That's an interesting point. We explicitly avoid encapsulating state in that way, preferring views to interfaces. > I would argue that relational is also effectively hierarchical ... object graph. A graph is fine. The difference from a typical OO hierarchy is we get to start wherever we want in the graph and we can easily insert new edges anywhere in the graph, or hyperedges that relate multiple entities. It's not like a filesystem where you have to decide which property of the file is most important and gets to be at the top of the hierarchy.
  - seanmcdirmid 12y ago
    > A graph is fine. The difference from a typical OO hierarchy is we get to start wherever we want in the graph and we can easily insert new edges anywhere in the graph, or hyperedges that relate multiple entities. It's not like a filesystem where you have to decide which property of the file is most important and gets to be at the top of the hierarchy. Objects support references that give you pretty much the same thing. The ability to add new kinds of edges is more of a function of your object system. In a dynamic language where members are basically defined as a dictionary, you just add a new key-value pair to the dictionary.

by jamii 12y ago

dragonwriter 12y ago

> Excel has one level of nesting (sheet.cell). Excel has one level of nesting within a file, but Excel "programs" are not limited to a single file; and, in fact, Excel has features designed specifically for programs that require multiple files to be open at once to interact. Its true that each level of nesting in Excel is different in kind so that Excel doesn't support arbitrary nesting of namespaces, and that different bits of Excel functionality support different degrees of nesting.

seanmcdirmid 12y ago

Ah, I see. LabView supports objects, so its data model can at least be hierarchical there. But even if we ignore OO data models, I think even FRP (as pure data flow as we get) is hierarchical since components (and sub-components) can still encapsulate state. The only thing you really lose are aliases/implicit communication channels. Most visual data-flow languages follow this style. I would argue that relational is also effectively hierarchical if not intrinsically: even without nested tables you always have IDs tacked on in a column that refers to rows in other tables. And once you start doing that, well...object graph.

jamii 12y ago
> I think even FRP (as pure data flow as we get) is hierarchical since components (and sub-components) can still encapsulate state. That's an interesting point. We explicitly avoid encapsulating state in that way, preferring views to interfaces. > I would argue that relational is also effectively hierarchical ... object graph. A graph is fine. The difference from a typical OO hierarchy is we get to start wherever we want in the graph and we can easily insert new edges anywhere in the graph, or hyperedges that relate multiple entities. It's not like a filesystem where you have to decide which property of the file is most important and gets to be at the top of the hierarchy.
- seanmcdirmid 12y ago
  > A graph is fine. The difference from a typical OO hierarchy is we get to start wherever we want in the graph and we can easily insert new edges anywhere in the graph, or hyperedges that relate multiple entities. It's not like a filesystem where you have to decide which property of the file is most important and gets to be at the top of the hierarchy. Objects support references that give you pretty much the same thing. The ability to add new kinds of edges is more of a function of your object system. In a dynamic language where members are basically defined as a dictionary, you just add a new key-value pair to the dictionary.