23 ms·

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 conve

by Eli_P 8y ago

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, but in general case, they don't. Try to define perceptible difficulty, or search for implementations in code linters, I believe it's always subjective, like max lines of code per function. The true code representation is multidimensional and incomprehensible for a monkey brain, even if you'd made it look like a multi-layer Manhattan-like glowing graph. [1] https://ballerina.io/philosophy/ https://ballerina.io/philosophy/ [2] https://github.com/search?q=ballerina https://github.com/search?q=ballerina

asn0 8y ago
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.
- TuringTest 8y ago
  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_notations https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati... [2] https://www.uxbooth.com/articles/a-usable-guide-to-cognitive-dimensions/ https://www.uxbooth.com/articles/a-usable-guide-to-cognitive...
  - zozbot123 8y ago
    > Unfortunately, visual languages tend to be quite poor at abstraction It's not as simple as that. Visual languages tend to be very good at portraying a fairly large subset of abstractions - loosely speaking, many and perhaps most abstractions that you'd want to model using category theory are almost inherently "visual" - and just not very helpful at portraying others. I think the answer is a tighter integration of textual and visual "modes" on the same codebase, rather than just using visual for everything no matter what.
    - TuringTest 8y ago
      Yes, I would expect that. Algebra expressions are best written with infix operators, rather than graphs. And data or control flows benefit from the boxes-and-arrows representation of visual languages. The problem is, how to decide what parts of the program ti represent as text, which ones are better as graphs, and where to place program data values?
- coldtea 8y ago
  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.

by Eli_P 8y ago

asn0 8y ago

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.

TuringTest 8y ago
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_notations https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati... [2] https://www.uxbooth.com/articles/a-usable-guide-to-cognitive-dimensions/ https://www.uxbooth.com/articles/a-usable-guide-to-cognitive...
- zozbot123 8y ago
  > Unfortunately, visual languages tend to be quite poor at abstraction It's not as simple as that. Visual languages tend to be very good at portraying a fairly large subset of abstractions - loosely speaking, many and perhaps most abstractions that you'd want to model using category theory are almost inherently "visual" - and just not very helpful at portraying others. I think the answer is a tighter integration of textual and visual "modes" on the same codebase, rather than just using visual for everything no matter what.
  - TuringTest 8y ago
    Yes, I would expect that. Algebra expressions are best written with infix operators, rather than graphs. And data or control flows benefit from the boxes-and-arrows representation of visual languages. The problem is, how to decide what parts of the program ti represent as text, which ones are better as graphs, and where to place program data values?
coldtea 8y ago
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.