Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Full Metal Jacket: A visual dataflow language (2016)

fmjlang.co.uk

Post reply on HN
Print view View original

31–40 of 57 posts

Re: Full Metal Jacket: A visual dataflow language (2016)

#31

Post by TuringTest »

hliyan wrote: post #27
_wmd wrote: post #5

Earlier quoted context omitted.

Would you consider Microsoft Excel a visual language?

Excel is cartesian, which is hardly 'graphical'. There are virtually no superfluous graphical detail (e.g. placement of shapes, arrows, thickness etc.) -- the only part of the flexgrid that has semantic meaning is the row and column reference.

Giving meaning to coordinates in a 2D chart makes it a graphical language. It certainly is different from conventional languages, which use a tree metaphor (nested expressions) and a linear syntax (everything is considered a long stream of text to be parsed).

Using rows and columns instead of code blocks helps a great deal in reducing the cognitive load of having to address every part of the language through an ID, either for variables of functions. Not to mention intermixing code and data values, which is not considered part of conventional languages (though is common in interactive debugging sessions, which are typically considered "visual" debugging).

Re: Full Metal Jacket: A visual dataflow language (2016)

#32

Post by TuringTest »

hliyan wrote: post #3

"Text-based languages are so 20th century" This is arguably NOT true. Visual languages have consistently failed to match, let alone out-do textual languages for decades, and with good reason.

Visual languages fare very well for the use cases where they're adequate, and with good reason: dataflow specifications, data mungling, circuit design, and end-user development.

The error is thinking that "visual languages" are adequate for the same general purpose as textual languages. But for certain Domain Specific Languages, visual tools can be and have shown themselves to be quite useful.

Re: Full Metal Jacket: A visual dataflow language (2016)

#33

Post by TuringTest »

asn0 wrote: post #29
Eli_P wrote: post #12

Visual representation for code has its own niches for certain. The most newfangled thingy I've encountered is Ballerina[1], it's kind of text diagram convertible code, cloud-oriented. Looks cool; there are some codes on github[2]. But anyways, I think it may be worthy as a domain-specific environment only. Because as a general-purpose language, visual languages are claimed to have improved perceptible difficulty , bu…

I'm curious how Ballerina avoids (or does it?) this problem mentioned in another comment: >once a "program" gets complex it can get tangled fast. A node with 3000 edges starts to look messy.

That wouldn't be messier than a textual function making 3000 function calls, or accepting 3000 parameters. The way you handle this complexity should be the same in both cases: creating abstractions that bundle together related items, hiding the details on a lower layer and exposing only the general ideas at the outer level.

Unfortunately, visual languages tend to be quite poor at abstraction. We've been developing and improving ways to make better abstractions in textual languages for the last 50 years, but somehow visual languages seem to be using the same abstraction tools we had with ALGOL, when not the same ones we had with Assembler.

For a mental framework on how to analyze and design visual languages for usability, see Cognitive Dimensions of Notations.[1][2]

[1] https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati... [2] https://www.uxbooth.com/articles/a-usable-guide-to-cognitive...

Re: Full Metal Jacket: A visual dataflow language (2016)

#34

Post by 6nf »

_wmd wrote: post #5
hliyan wrote: post #3

"Text-based languages are so 20th century" This is arguably NOT true. Visual languages have consistently failed to match, let alone out-do textual languages for decades, and with good reason.

Would you consider Microsoft Excel a visual language?

I'm going to say 'yes'. It's a good question and I think Excel qualifies even though in normal use Excel shows the data but not really the logic / formulas etc.

Re: Full Metal Jacket: A visual dataflow language (2016)

#37

Post by vectorEQ »

i dont see how this is different from regular programming to be honest. perhaps that you dont have side effects as a possibility, but i just see someone making functions and tying them together and supplying inputs and outputs? :/ seems super tedious to have to use the mouse, like with most things programming related, a keyboard is generally much easier to use.

Re: Full Metal Jacket: A visual dataflow language (2016)

#38

Post by vectorEQ »

hliyan wrote: post #3

"Text-based languages are so 20th century" This is arguably NOT true. Visual languages have consistently failed to match, let alone out-do textual languages for decades, and with good reason.

visual languages are good for very specific domains. look at Reaktor from native instruments, thats something which does work a lot better visually as a lot of the people who need that functionality aren't programmers neccesarily, and programming dsp units is not an easy task. you have applications for visual programming, but often it's very very specific or just purely for educational purposes. (teaching logic can be handy to do visually for some audiences.)

Re: Full Metal Jacket: A visual dataflow language (2016)

#39

Post by coldtea »

RantyDave wrote: post #26
rdtsc wrote: post #6

I have seen visual dataflow languages and even worked on some of them. They usually work better in specific domains like stream processing, control systems, signal processing and such. Even then, once a "program" gets complex it can get tangled fast. A node with 3000 edges starts to look messy. There are some things you can do to fix it but then you just kind of wish to use a simple script. As for general computing,…

Visual effects lives breathes and eats visual languages. It's not necessarily a good thing - people get (very) competent with them then start writing C++ using the same style namely, copy-n-paste a go go. Refactoring fun for all the family.

That's C++'s (and its IDE's) problem though. In visual languages copy-n-paste is not copy and paste, it's reusing a component.

Re: Full Metal Jacket: A visual dataflow language (2016)

#40

Post by coldtea »

asn0 wrote: post #29
Eli_P wrote: post #12

Visual representation for code has its own niches for certain. The most newfangled thingy I've encountered is Ballerina[1], it's kind of text diagram convertible code, cloud-oriented. Looks cool; there are some codes on github[2]. But anyways, I think it may be worthy as a domain-specific environment only. Because as a general-purpose language, visual languages are claimed to have improved perceptible difficulty , bu…

I'm curious how Ballerina avoids (or does it?) this problem mentioned in another comment: >once a "program" gets complex it can get tangled fast. A node with 3000 edges starts to look messy.

Why would the node need "3000 edges"?

In a source based language, would it have 3000 arguments or connections to other parts of the program?

This seems to be an issue of complexity management which would be the same (or worse) in source form.

If anything with a visual language you would be able to have it only show some specific nodes of those 3000 (e.g. those of a certain type, or going to a certain receiver), jump to a higher level view, and so on. With text it's all a big dump.

A visual language UI is a superset of text (and can go down to a just-source representation and source editing if needed.

The reverse is not true -- a source editor is not a superset of visual editing.

Post reply on HN