4 ms·

1. Diffs: There is no easy way to diff two versions. You need to diff the visual changes (what it looks like) and the semantic changes (what it means). How do y

by RNeff 12y ago

1. Diffs: There is no easy way to diff two versions. You need to diff the visual changes (what it looks like) and the semantic changes (what it means). How do you visually display the changes in a useful way? IE, what do you put into github? 2. Spaghetti code: Read the Dijkstra's paper on Goto, and mentally replace 'goto' with 'line'. 3. Text labels: Many graphical languages have lots of text labels in the display. 4. Limits: There is a human visual limit of about 50 items in a graphical picture, unless there is a underlying graphical semantic context such as geography or time series. 5. Too Big: Once the diagram is larger that one screen, navigation and comprehension become exponentially more complicated. 6. Graphical API: Not clear what is the graphical equivalent to modules, namespaces, packages, etc. How would you package reusable code and make an API available? During the 1970's, I spent years working on CAD tools, including logic schematic entry and IC layout programs. This was using graphical tablets in the pre mouse era. Even simple 8 bit microprocessors were too complex to draw schematics on a display, and barely possible to layout by hand on a display. I note that today logic design is using text languages such as Veralog, and layout is mostly automated.

dragonwriter 12y ago
> 1. Diffs: There is no easy way to diff two versions. Any visual programming language can be serialized to and deserialized from a linear format, which can easily be subject to diff. It should be fairly straightforward from that to also build a visual interpretation of the diff of the serialized forms (e.g., an animation of the transformation from the original to the new form.) Visual vs. semantic changes is only an issue if the language admits multiple visual representations that are structurally equivalent rather than (e.g.) accepting different inputs and reducing them to a canonical representation. But even if you allow that, you should be able to use canonicalization of that type "behind the scenes" to generate diffs which are comprehensive or which only identify semantically-significant changes. > 2. Spaghetti code: Read the Dijkstra's paper on Goto, and mentally replace 'goto' with 'line'. As in text language, using block structure rather than arbitrary gotos addresses this. There is no reason a visual language can't be block structured. (If you are concerned about procedure/function-calls-as-lines rather than gotos-as-lines, there's no reason that calls need to be lines; callables can be shapes, and calls can simply be inclusion of the shape in the procedure being drawn.) > 4. Limits: There is a human visual limit of about 50 items in a graphical picture, unless there is a underlying graphical semantic context such as geography or time series. There are similar limits in other domains, which is one of the reasons for structured decomposition of code in general. I don't see why this would apply less to visual code. > 6. Graphical API: Not clear what is the graphical equivalent to modules, namespaces, packages, etc. How would you package reusable code and make an API available? In general, names are shapes -- I don't see why that would be any different for names of namespaces vs. names of individual items within a namespace. Sure, how you depict either "opening" a namespace or accessing a name from it in a qualified way would be something a graphical language with namespaces would have to decide.

by RNeff 12y ago

dragonwriter 12y ago

> 1. Diffs: There is no easy way to diff two versions. Any visual programming language can be serialized to and deserialized from a linear format, which can easily be subject to diff. It should be fairly straightforward from that to also build a visual interpretation of the diff of the serialized forms (e.g., an animation of the transformation from the original to the new form.) Visual vs. semantic changes is only an issue if the language admits multiple visual representations that are structurally equivalent rather than (e.g.) accepting different inputs and reducing them to a canonical representation. But even if you allow that, you should be able to use canonicalization of that type "behind the scenes" to generate diffs which are comprehensive or which only identify semantically-significant changes. > 2. Spaghetti code: Read the Dijkstra's paper on Goto, and mentally replace 'goto' with 'line'. As in text language, using block structure rather than arbitrary gotos addresses this. There is no reason a visual language can't be block structured. (If you are concerned about procedure/function-calls-as-lines rather than gotos-as-lines, there's no reason that calls need to be lines; callables can be shapes, and calls can simply be inclusion of the shape in the procedure being drawn.) > 4. Limits: There is a human visual limit of about 50 items in a graphical picture, unless there is a underlying graphical semantic context such as geography or time series. There are similar limits in other domains, which is one of the reasons for structured decomposition of code in general. I don't see why this would apply less to visual code. > 6. Graphical API: Not clear what is the graphical equivalent to modules, namespaces, packages, etc. How would you package reusable code and make an API available? In general, names are shapes -- I don't see why that would be any different for names of namespaces vs. names of individual items within a namespace. Sure, how you depict either "opening" a namespace or accessing a name from it in a qualified way would be something a graphical language with namespaces would have to decide.