Hacker News Reader

Comment by ericHosick | Hacker News Reader

They are going for a visual language, and visual languages are inherently hierarchal. The goal is to easily represent context of any part of a program in a visual way.

Trying to map source-code that stores a lot of it's context on the stack is really hard to visually represent. Trying to represent the stack in a visual way makes for a icky looking visual language.

However, if you can keep all of the context/state of your program in one area and it is hierarchal... Then, you can build great visual representations of your program because, really, you are displaying a data-structure (your program becomes a data-structure). So, all the cool things you can do visually representing data-structures, you can do with your actual program.

View on HN

> They are going for a visual language

'Visual language' is a very overloaded term and we are in no way set on any particular ideology. Textual languages and visual layout have different strengths and weaknesses and there are lots of cases where it makes sense to mix both. There is plenty of evidence that both are useful (eg http://www.amazon.com/Small-Matter-Programming-Perspectives-...). My only aversion to text is as an unstructured storage and communication format - it makes much more sense to allow tools to communicate using a shared, versioned and structured database rather than watching for changes in text files.

> visual languages are inherently hierarchal

Excel - https://www.google.com/search?q=excel&client=ubuntu&hs=fRx&c...

Access - https://www.google.com/search?q=access&client=ubuntu&hs=Jnc&...

Labview - https://www.google.com/search?q=labview&client=ubuntu&hs=v5H...

Blender - https://www.google.com/search?q=blender+node+editor&client=u...

PureData - https://www.google.com/search?q=puredata&client=ubuntu&hs=4S...

TouchDevelop - https://www.google.com/search?q=touchdevelop&client=ubuntu&h...

Kodu - https://www.google.com/search?q=kodu&client=ubuntu&hs=N9H&ch...

Pretty much the only hierarchical example that comes to mind is Scratch.

> Trying to map source-code that stores a lot of it's context on the stack is really hard to visually represent.

Yes. But non-local scope and control flow are also pretty hard to represent and understand. That's why we ended up avoiding both.

> However, if you can keep all of the context/state of your program in one area and it is hierarchal...

It doesn't have to be hierarchical. Excel and Access both have amazing (by programming tool standards) visual representations of your program and your data.

> So, all the cool things you can do visually representing data-structures, you can do with your actual program.

Data and code are different though. Eve is homoiconic-ish (code is stored in tables) but the actual visualisations and manipulations applied in 99% of the use cases are very different. We don't spend nearly as much time manipulating code as data compared to reading, writing and understanding code so it makes sense to default to visualisations that optimise for the latter.

Most of those languages have some kind of hierarchy. Lab view can define sub-components, TouchDevelop is basically procedural, excel has sub-sheets. Kodu is not hierarchical, but neither is it really a full language and the Brooks' subsumption architecture it is based is hierarchical (check out [1] on how to make Kodu hierarchical).

[1] http://research.microsoft.com/pubs/179364/p61-mcdirmid.pdf

Are sub-components and sub-sheets an argument for _hierarchy_, or for reuse of symbols? I think it's the latter.

As far as abstractions go, they are hierarchical. Actually, abstraction is all about breaking up and managing complexity into separate parts, and one would do pretty poorly without any hierarchy in their code.

Even Kodu is hierarchical to a limited degree since each bot is programmed separately, but its not unlimited as in the other examples listed (which I would argue, is necessary to be considered hierarchical).

OP's premise wasn't that "hierarchy exists", but that it's "the correct organization of data." Now you are just glibly pointing out that everything can be structured as a hierarchy. That does not make the case.

I'm not pointing out that everything can be structured in a hierarchy, I'm pointing out that everything needs to be structured in a hierarchy at some point to deal with complexity; these are very different observations.

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.

> 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.

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.

> 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.

> 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.

> excel has sub-sheets

It has sheets, but not subsheets (which are a feature of some other spreadsheet programs that you can find lots of questions online about how to do or fake in Excel; that being said, its still heirarchical, both in its structure and the visual metaphor for interacting with it.)

> Pretty much the only hierarchical example that comes to mind is Scratch.

Excel is your first example (and the one that the Eve dev blog keeps referring to while showing examples that aren't very Excel-like visually except insofar as anything which uses a grid as one of its visual elements is "Excel-like"), and Excel's objects are accessed through heirarchical identifiers where the parts of the heirarchy that are local to where the reference is used can be omitted. (Well, sort of; for external files, rather than locality, the path can be omitted if the file is currently open in Excel -- and certain references, notably tables, only work in the same circumstances that allow omitting the path.)

The heirarchy is path -> filename -> defined-name for defined names, and path -> filename -> sheetname -> range for unnamed cells or ranges; each of the steps of this heirarchy are also directly represented in the visual UI you interact with when doing references by point/click/drag rather than textually, as well. So, both in the names and the visual metaphor, Excel is heirarchical.

True, I hadn't considered that. The data-flow is not hierarchical, which is what distinguishes it in my mind, although apparently not in my commenting :)

Let me back up and state my premises more accurately. Most successful visual languages:

* emphasise global data-flow and only have control-flow locally, if at all (eg 'if' expressions in excel)

* support broad, shallow hierarchies for organising large projects but don't require any hierarchy for small projects

* allow data-flow between arbitrary sources/sinks regardless of data organisation

So control-flow hardly exists, data-flow is not hierarchical and the data model has a shallow hierarchy where the leaves are big flat chunks of data.

I suspect that even in organisation, a single strict hierarchy is not the best model. Non-technical users often struggle with hierarchical file-systems and prefer tags or search. File-systems themselves end up needing to implement multiple parents (eg links in linux).

We haven't gotten to large projects yet in Eve but our solution will likely draw from the evolution from hierarchical file-systems to tags, search and 'smart folders'.

> 'Visual language' is a very overloaded term and

All great points and I agree with them.

> Pretty much the only hierarchical example that comes to mind is Scratch.

I tend to lean towards Sean's post: https://news.ycombinator.com/item?id=8468838.

> non-local scope and control flow

I read you are going for an "Excel" type approach. I thought you were doing this to deal with non-local scope. I hope so because I think it is a good idea.

> are also pretty hard to represent and understand

Control flow is also really hard to represent but I don't think it is because of any aspect of the visual representation or core technology. You can remove coding from programming but you can't remove critical thinking and problem solving from programming: which is basically what programming is.

Control flow is critical thinking and problem solving. That is why when you "presented our prototype to a small number of non-programmers and sat back to watch the magic. To our horror, not a single one of them could figure out what the simple example program did or how it worked."

It is because there are inherent mental models that we use as tools to solve problems and think critically. People need to be given a visual representation of control flow in a way they are familiar with. I'm guessing you guys have done an amazing job (I've seen light table).

Frankly, I have a lot of experience in this space. I've spent ~5 to 6 years studying it and building out tools. I recognize a lot of the pains you are going through because I've been there. I would be more than happy to chat with you about it. I am totally stoked about Eve and would like to help.

> understanding code so it makes sense to default to visualisations that optimise for the latter.

I may be totally reading this wrong but you should not default visualisations to represent a given program. In my opinion, this is a mistake that all VPLish type things have made (as you said, it is a totally overloaded word). You can easily represent a given small part of a program in any domain you like: using the same underlying program. It could look like a mathematical equation to a mathematician, textual code to a programmer or process flow abstractions to someone in logistics.

This is one of the great strengths of hierarchical type programming languages: the same code can be represented using multiple visual abstractions tailored to the user.

This is why I totally agree with this statement "The environment should be optimised for the way that people use it, not the way that we think it should be used."

but think you should reconsider this "We should observe users and collect data to discover common actions and workflows." There are no common actions or assumptions you can make when going visual because there are so many different ways people approach solving a problem.

Programmers are only kind of aligned because we all go through this grinder that requires us to fight with compilers and figure out error messages and deal with syntax and so on. So, we all kinda mentally solve problems in the same way (and by kinda, it isn't like close but a lot closer than say an accountant and a painter solve their problems).

I hope this isn't too long winded but I really do have a lot of knowledge in this space.

> I thought you were doing this to deal with non-local scope.

Non-local data-flow (you can reference any table in a query) but only local control-flow (at the same level as excels 'if' statement) and no scoping (references are absolute and global - they don't change depending on where you are in the program).

> Control flow is critical thinking and problem solving.

Critical thinking and problem solving do not require programming with control flow and they are certainly not limited to programmers (you didn't claim the latter, but it is a common assertion on hn and it needs to die). Here are some of the people we've talked to about their programming needs, both for Eve and in past work:

* a radiologist with phds in both medicine and nuclear physics * an ex- radar engineer who now manages and schedules multi-million dollar aerospace projects * a group of traders at a prestigious prop trading company

These people are certainly capable of critical thinking, abstraction, problem solving etc. All of them build complex programs in Excel and other tools. None of them have got the hang of traditional programming. I've seen research that argues that supplying task-specific primitives and ensuring early success on the learning curve are both vital. I suspect that the distinction between traditional control-flow-heavy programming languages and static-data-flow end-user languages plays a big part in that learning curve.

That's not to say that non-local control-flow is evil or that it can't be taught, just that it seems to put a big hump in the learning curve and we can usually get away without it.

> It could look like a mathematical equation to a mathematician, textual code to a programmer or process flow abstractions to someone in logistics.

When I say visualisation I include all of the above, not just graphical representations. For example, our default table view is a grid of cells and our default rule view is a mixture of graphical meta-data and textual formulae.

> There are no common actions or assumptions you can make when going visual because there are so many different ways people approach solving a problem.

I think you are thinking much higher level than I am. There are lots of common actions that every programmer I know does every day. For example, I run my program in the browser, check the console for exceptions, put a breakpoint on the line where the exception happened and try to cause the exception to happen again so I can observe the local state, often having to click through the breakpoint multiple times to get the actual error case. In any sane environment (eg Common Lisp) that process would be optimised to: check the console for exceptions, click the 'open debugger here' button next to the exception.

> Non-local data-flow (you can reference any table in a query) but only local control-flow (at the same level as excels 'if' statement) and no scoping (references are absolute and global - they don't change depending on where you are in the program).

I'm quit surprised by this. In data-flow programming (e.g. FRP), non-local data-flow is a big no no, while non-local non-contiguous control-flow rules the day but is completely encapsulated (programmers only manipulate data flow via wiring, control flow is inferred).

> I suspect that the distinction between traditional control-flow-heavy programming languages and static-data-flow end-user languages plays a big part in that learning curve.

This is a guess, but I don't really see it. A cook can definitely follow a recipe, or even write one for others to read, which involves lots of control flow. We are totally steeped "in time" and our communications often make references to sequenced time-stepped actions.

Spreadsheets are great in accounting and were invented way before we had computers. Math and logic are also nice, and very specialized for the educated, but they came way after we developed our skills for natural language (which was the original OOP). It is quite difficult to say why programming is hard, and what makes it easy.

> Critical thinking and problem solving do not require programming with control flow

Ya bad choice of words. Control flow requires critical thinking and problem solving (but critical thinking and problem solving is not always about control flow).

Hmm. Though, I guess if you go way deep, every decision we make is based on two or more options.

> These people are certainly capable of critical thinking, abstraction, problem solving etc.

Ya. But the way they think critically, their internal mental model, might be totally different than how you are I think. So, we all may come to the exact same conclusion. Just through a very different thought process using different abstractions to represent that critical thinking.

Reply on news.ycombinator.com