Hacker News Reader

Comment by king_magic | Hacker News Reader

Well, I've been programming for 20+ years across dozens of languages, and I can't understand what a single one of those diagrams is actually doing.

But I can grok the "textual code" example almost instantly, so fast that the difference in effort is almost laughable. I find the mental overhead in understanding the diagrams vs. "textual code" (that phrase makes me mentally chuckle each time I read it) is orders of magnitude higher. Sorry, but I simply don't buy what they're selling (and I say this as someone who lives and dies by the whiteboard).

About the only thing out of this that looks actually useful for real-world software engineering is the visual profiling piece. If I were them, I'd probably throw out everything else they are working on and focus on that single piece alone, because that could be pretty useful.

View on HN

As you said, you have been programming for 20 years, therefore you likely have built a lot of experience and innate skills for dealing with text and considerably less for dealing with diagrams.

I don't think this tells anything whether someone with the same amount of experience in diagrams might be able to make more of it than you with the equivalent text representation.

For what it's worth, mathematicians work on paper so they aren't constrained by anything, but they still use textual nested syntax instead of visual dataflow graphs.

That's a completely false analogy. We rely on text to represent what's best written as text. When you want to speak of a specific automaton or graph, you'll give a figure, unless the mathematical structure is really big (infinite maybe) and thus best described intentionally.

Frege's notation is another example, although it was a bit idiosyncratic, but its legacy very much lives in proof theory.

And then there are string diagrams, proof nets, ...

Do you know anybody doing maths who could say "well I've never felt the need to use a figure in my life"?

> We rely on text to represent what's best written as text.

Yes exactly. And if you look at the common methods for how knowledge is represented, in mathematics or any field really, it's very roughly around 80% knowledge as text and 20% graphs/diagrams/figures.

An image can be extremely helpful and illustrative if appropriate. But almost nowhere do you see people communicate primarily with images.

Text is king. I think if the programming environment doesn't embrace text as the primary input method, then it's not really good as a general-purpose environment; it'll only be successful in niches.

> But almost nowhere do you see people communicate primarily with images.

I'm not quite sure how humans could communicate primarily with images, at least until neural interfaces are in widespread use... I would argue that, yes, we communicate primarily with text, because we have the innate skill - speech - to do so efficiently and we have no equivalent skill for images. This doesn't tell anything about how knowledge would be best expressed in theory.

> And if you look at the common methods for how knowledge is represented, in [...] any field, it's very roughly around 80% knowledge as text and 20% graphs/diagrams/figures.

Sources, please. But even assuming this is true, this would leave 20% which are better represented visually. And I believe it's a worthwhile goal to integrate visualisations for those 20%. An integration like this seems possible with Luna's approach of offering both, a text and a visual representation.

> Text is king. I think if the programming environment doesn't embrace text as the primary input method, then it's not really good as a general-purpose environment

I agree with you that it's a good idea to have some textual representation - If for nothing else so you can use existing tools. But that seems to be exactly what Luna is going for, if I understand the site correctly.

I don't see why text has to be the primary input method.

> But that seems to be exactly what Luna is going for, if I understand the site correctly.

Yeah, I'm withholding judgement on Luna specifically, until we can see it in action. Their model could be a good one, it all depends on whether they treat the text representation as a first class citizen or not.

Paul we do treat BOTH text and visual graphs as first class citizens. Luna's compiler is all about AST modification. In fact Luna provides few different AST models, the most important are:

1) Standard AST - one that is a common and extendible syntax representation. Both the textual code as well as visual graphs are able to translate to and from this AST model. To be most precise - both representations are just some kind plug-ins (with some funny type-level-safety built-in) over this AST representation, so they are both first class citizens and they are completely equal to each other.

2) Core AST - a desugared, type-checked, minimal lambda calculus language, that is used to perform all sort of optimizations before next steps towards generating the target code (assembly / js).

We treat the graphical interface exactly the same way, never favoriting any representation over the other. If you would like to develop another one, like natural language input, you have just to provide methods for translating it to and from AST and our infrastructure delivers everything you need to translate it to and from visual or textual one.

I hope this spots a light over the internal design of Luna :)

I agree that for describing a specific graph, drawing it is sometimes the best way. Most of the time an automaton or graph is a mathematical object under study. The notation used to study graphs and automatons and prove things about them is symbolic. Saying that maths notation is visual because a mathematician might draw a diagram to illustrate their proof is like saying that programming is already visual because a programmer might draw a diagram to illustrate their program.

It's true that there are some visual notations in mathematics, but they tend to be the exception rather than the rule, and where they are used it's a mixed system most of the time. Frege's notation was half symbolic half visual, and the visual part of it didn't catch on except for the horizontal line. The rest of it got "symbolified". I don't think that's a coincidence. Actually the most commonly used half visual half symbolic notation in mathematics is the commutative diagram. I suspect that over time even the use of those may decrease in favour of symbolic type theory notation.

I do think some sprinkling of visual notation is useful, also in programming, but representing expression trees as dataflow graphs? That has been tried many times and it hasn't been successful, nor is it likely to be in the future. I don't think flat text has any future though. A program has structure and is not best represented as an array of characters. Symbols and nested syntax are here to stay however. Humans just deal better with nesting and symbolic references than with a forest of lines and arrows.

Ironically one of the first languages of formal logic used a visual syntax [1] but only parts of it remain in use: as ordinary textual operators (like the turnstile ⊢ or negation ¬).

[1] https://en.wikipedia.org/wiki/Begriffsschrift

That's why I added the "and I say this as someone who lives and dies by the whiteboard" comment to my answer. Plenty of experience with diagrams. Wouldn't want to code with them for most use cases (and sure, there may be some use cases where visual programming tools make sense - not saying they're aren't any, just IMO, not many).

I'd think it depends strongly on the use-cases and also how the visual language is implemented. Some "visual programming" approaches I've seen simply take a traditional imperative program and turn it into a flowchart - or just show you a simplified AST with some pretty colors.

This is not very useful and often gives you the worst of both worlds - you gain no useful information about the underlying structure but lose many tools to edit the program efficiently. (Though in highly constrained environments - e.g. high level game scripting - even that can be useful)

On the other hand, there are often cases where some relevant aspect of your program has a structure that could be visualized easily - but not as easily expressed in text. In those cases, I think working with the visualisation can be a lot faster and less error-prone than working with text.

The trivial example is of course GUIs or other things which are visualized in the end anyway. But it is also true for data flow graphs (think Storm or TensorFlow) or networks of things that communicate (Components in an IOT container, services, machines on a LAN, etc).

of course visual programming doesn't magically un-fuck your bad design. If you have a big ball of mud and have a look at the component graph, you'll likely see a tangle of lines that doesn't give you insight. But I think that would be more a sign that you should overthink your architecture, not that visualisations are useless.

>Plenty of experience with diagrams.

How much experience with visual programming?

Enough to find it not useful for anything more complex than the trivial examples that are always shown to get people hooked. Windows Workflow Foundation, anyone?

Work for a company that sells visual programming tools. Our customers absolutely love the functionality.

A number of very large organizations are using it: from the military, to Netflix, HP, NASA, Pharmaceutical companies, and so on.

The major benefit is that it lets process owners/managers, who aren't programmers, see and understand the code/architecture behind their processes, and suggest, or even make, important changes to those processes.

How about a parser that creates a high level flow chart out of normal code?

Hi! I'm one of the guys behind Luna. The problem with such parser is that in vast majority of cases such graph is not readable by non-technical people, it is not interactive, does not visualise results and doesnt allow you to fast reconnecting components, switching and testing ideas. Moreover, it would be very hard to provide a tool that would draw graphs with the same layout of unchanged elements between iterations, so the layout would completely change after changing the text. In fact the problem originates from the source language - if you want to create a data flow graph out of imperative language, you'll hit a wall really fast, because the output would be messy and completely not understandable. Luna is purelly functional and designed in such way, the graphical representation matches the textual one in nice, seamless way.

Right, the so-called "level of abstraction" is just an abstraction for textual hackers, one that other hackers get but a visualizer like a "c to dot" parser wouldn't. You're basically making the abstract higher order domain of discourse the programming "language".

LabVIEW?

>Well, I've been programming for 20+ years across dozens of languages, and I can't understand what a single one of those diagrams is actually doing.

What exactly looks difficult to parse about the visual example going:

read -> grade -> transform -> grade -> final touches -> write

To me it's a very obvious image processing pipeline, reading the image, grading (in image processing terms this means color work, e.g. adding a hue to the highlights), doing a transformation (e.g. some rotation, or similar), grading again, and finally writing the result to disk.

If you wonder what "exactly" they are doing, then unless you open each box (like the 2nd "grade" box is open), they're not meant to tell you. Closed, they're meant to give a high level overview of how your functions etc are connected.

Think of it as seeing your code in your programming editor with the functions folded.

The second example is also obvious. There's a selectable (by dropdown) input source, currently set to read posts from Twitter. Posts read are then fed into a (switchable on/off) filter, that either passes them all, or only keeps the one from Europe.

Of course you need to spend a few minutes (or days) to familiarize yourself with the visual language (like you would for new terms if you met a new programming language), e.g. how the toggle icon means a "switchable" option.

Ok, so maybe I'm being a little over the top when I say "I can't understand what a single one of those diagrams is actually doing". I'm not stupid, and sure, I can grok 'em if I spent enough time digging into them.

My point is - I could either waste time piecing together a visual diagram like that (which is going to be fairly different visually from use case to use case - e.g., image processing vs. text processing, resulting in more mental overhead) - or I could look at code, which is (for me, at least) simply much quicker and easier to understand (in many cases).

Furthermore, these are idealized examples. Start throwing in error handling. Concurrent processes. I predict that diagrams that can fully capture complex systems will lean far more towards "visual overload" than not, and really, how useful is a tool like this at that point?

Maybe something like this could be fine if it's just high-level processes, but it just falls apart the more detailed things get.

Hi! I'm one of the guys behind Luna. I completely see your point of view. Working with visual grpahs is something you have to learn to do, exactly the same way like writing a code. Unlike code, diagrams are thought more obvious for people without really strong technical expertise. I cannot agree with one of your points - namely that with each use case diagrams would look differently. Nodes have a position on 2D whiteboard - just like text is layouted in a file and displayeb by your favorite editor. The colors in the graph indicate the type of data and all the variable names are just hidden, because you don't have to manually track where they have been used. If you just look at the lines, you instanlty knows what is happening to that chunk of data, no matter if you're processing text, tweets or programming hardware with it :)

Show me how you support error handling or concurrent processes. Heck, show me nested iteration or even basic recursion - then show me all of that, scaled up to real-world complexity.

My suspicion is that as your model approaches the complexity of real-world systems, the visual language you're creating will be unable to efficiently capture that complexity.

Would love to be proven wrong.

People have been doing "real world" (commercial products used by hundreds of thousands of people) in environments like Max/MSP and Reaktor. There are also lots of huge commercial done projects (Hollywood movie CGI and complex behavior) programmed in node based compositing and 3D environments -- heck, people even use Quartz composer for prototyping projects.

Moreover, nothing prevents you from writing code, as they say Luna maps 1:1 to the code they show next to the diagrams.

But when you want a higher level view of the whole program architecture, code can't show you that -- with code you only get some source file or another, and even that rarely all of it in a single screen. A visual representation can, and it can group larger units in single modules (e.g. your packages).

>My suspicion is that as your model approaches the complexity of real-world systems, the visual language you're creating will be unable to efficiently capture that complexity.

One can even make a trivial visual language of 2-3 node types that is turing-complete and can capture ANY complexity. Luna is, of course, far better than that. As for sufficiency, this depends on the level that one wants to play. You might still write code at the lower function level, but if the language makes it easy to group functionality in larger visual units, it would be great for the larger structure, and also great for configurable parts meant for non-coders.

> One can even make a trivial visual language of 2-3 node types that is turing-complete and can capture ANY complexity. Luna is, of course, far better than that.

I don't disagree with you on the first part - that you can make a trivial visual language that can capture any complexity. The challenge is - can a user "visually" parse through the visual representation of that complexity?

I haven't seen any evidence that Luna can effectively do that at scale. Until I do, I remain extremely skeptical.

I would love to prove you are wrong :) I've described error handling in a reply to another question here and we'll update the website later to illustrate it there too. All other stuff like nested iterations or recursions will be shown in our documentation and will be available for alpha testers. But there is no magic involved - I'll shortly describe the mechanisms here too. Each function is a node and each function usage is a node as well. If you are defining function, you can dig inside the node to define the graph of its body. You can use in this graph a node representing usage of exactly this function. I completely understand that textual clarification is not enough here (heh, just proven graphs are easier here! :D), but live demos and examples will be available for alpha testers now.

I think the big application of visual programming is in domains where the concrete "unit operations" map neatly to programming functions. For example, things like this:

https://www.aspentech.com/uploadedImages/Community/Blogs/Eng...

That chemical process simulator lets engineers who are bad "text programmers" make complex chemical process simulations by giving them a library of functions that correspond neatly with the set of tools the engineer is used to thinking about. Indeed, other engineers can discern the intent of a flowsheet made in this tool faster than they could if they were looking at the text-code.

Etoys and many others have tried, maybe a good language and good IDE could have sufficient benefit, but I'm unsure how a UI would ever map to complex algorithms better than textual-interface paradigms. They can try and see, even if the likelihood of failure is unfortunately very high (until it's not). VPL seems currently like an utopia, apart from dashboards, configuration of control systems which naturally map to the real world and interface builders.

One interesting VPL I ran into is a free fractal editor on iOS which lets one build up visual LOGO execution pipeline(s) of operations.

How much of that 20+ years of experience was in visual languages and how much it was in textual languages?

Like everyone, all of it. Doesn't bode well for this product idea.

How long did we try to get UML to work? There's a reason that visual representations haven't taken off, it's not like they haven't been tried before. And don't get me wrong - there are absolutely use cases for these types of tools, but at the end of the day, I think there are just too many challenges in visual representation for this to to work for "any application" (as Luna claims).

UML solved a non problem, tied to a bureacratic software design method. And it wasn't even executable.

And this feels like solving a non-problem as well, IMHO.

Yeah - this is a hard problem and the chances are small.

Nevertheless if you had 20+ years of experience in programming textual languages than it is no surprise that you understand them better than visual languages. That part of your argument does not seem valid.

MatLab/Simulink feels natural for control system / DSP design.

Reply on news.ycombinator.com