3 ms·

> It hurts when it tries to visualize something better left in code. If you try to make a visual language as flexible as a general purpose programming language

> It hurts when it tries to visualize something better left in code. If you try to make a visual language as flexible as a general purpose programming language, it's going to be as complex and difficult to learn as any other general purpose programming language in my opinion. I think there's a fundamental limit to how simple you can make programming. Domain specific languages is a different beast however.

CyberDildonics 11y ago
Just because no one had done it doesn't mean it can't be done. A lot of difficult in programming stems from how opaque it is. It is like doing a rubiks cube in a black box, taking a look inside, then putting the lid on and starting again.
- seanwilson 11y ago
  I just think it's unlikely outside of domain specific problems. For example, flow charts and state machine diagrams can elegantly describe some algorithms but they have limited power which limits the complexity of the diagrams. If you want a visual language with programming features like function calls, state, threads, recursion etc. it's going to end up being of comparable complexity to just writing it in code in my opinion. Even visualising how a relative simple algorithm like quicksort works in an intuitive way is challenging let alone a fully working application. Happy to see examples that go against this though.
  - TuringTest 11y ago
    Visual languages are not good for representing complex state, but they're great for representing complex data transformations - often much better than textual languages. If you want to transform the structure of an input file (or any stream) with a hierarchical structure to an exit file with a different structure, in a text language you need to build a parser following the data's grammar, and create a state machine that represents the required transformations, which is not an easy task. With a flow language, you just draw an input component for each level of the hierarchy and list the data fields supported by that component; and then do the same for the output structure. The task is typically much simpler, as long as the task is pure data transformation and you don't need any side-effects during its execution.
    - seanwilson 11y ago
      > and you don't need any side-effects during its execution. Have you seen any visualisations for pure functional programs? So they wouldn't have any state/side-effects but I can't imagine how you'd visualise those usefully unless you only used small concrete example inputs and showed the function being evaluated. It is very interesting how some types of algorithms can be visualised easily and others cannot.
TuringTest 11y ago
> If you try to make a visual language as flexible as a general purpose programming language Visual languages don't need to fully replace a general purpose language to be useful; a good combination is where you use text to represent the abstractions in your program, and visual tools to represent the values. You can see this at work in one of the most successful visual tools, the interactive debugger, now embedded in every IDE worth its salt. The program's architecture is written in pure text, but the execution traces can be filtered, watched and poked interactively, rather than the textual alternative of writing everything to a giant linear log file. Visual environments are best at the initial exploratory phase of software design, when requirements are not fully specified and the code structure is still fluid. What all visual languages so far are missing is a way to build (textual) abstractions from the initial concrete, visual design. This would allow the programmer to grow the program "organically" by working with the data, without the need to write down every abstraction from scratch in text. There are Programming By Example[1] techniques that could help with this, but they are not well known nor widespread. I have hope that some breakthrough in visual programming is still possible by creating programming languages that don't try to copy imperative programming, but instead exploiting the strengths of a visual environment. Tools like Apparatus[2] show that this approach is a viable one. [1] https://en.wikipedia.org/wiki/Programming_by_example https://en.wikipedia.org/wiki/Programming_by_example [2] http://aprt.us/ http://aprt.us/

CyberDildonics 11y ago

Just because no one had done it doesn't mean it can't be done. A lot of difficult in programming stems from how opaque it is. It is like doing a rubiks cube in a black box, taking a look inside, then putting the lid on and starting again.

seanwilson 11y ago
I just think it's unlikely outside of domain specific problems. For example, flow charts and state machine diagrams can elegantly describe some algorithms but they have limited power which limits the complexity of the diagrams. If you want a visual language with programming features like function calls, state, threads, recursion etc. it's going to end up being of comparable complexity to just writing it in code in my opinion. Even visualising how a relative simple algorithm like quicksort works in an intuitive way is challenging let alone a fully working application. Happy to see examples that go against this though.
- TuringTest 11y ago
  Visual languages are not good for representing complex state, but they're great for representing complex data transformations - often much better than textual languages. If you want to transform the structure of an input file (or any stream) with a hierarchical structure to an exit file with a different structure, in a text language you need to build a parser following the data's grammar, and create a state machine that represents the required transformations, which is not an easy task. With a flow language, you just draw an input component for each level of the hierarchy and list the data fields supported by that component; and then do the same for the output structure. The task is typically much simpler, as long as the task is pure data transformation and you don't need any side-effects during its execution.
  - seanwilson 11y ago
    > and you don't need any side-effects during its execution. Have you seen any visualisations for pure functional programs? So they wouldn't have any state/side-effects but I can't imagine how you'd visualise those usefully unless you only used small concrete example inputs and showed the function being evaluated. It is very interesting how some types of algorithms can be visualised easily and others cannot.

TuringTest 11y ago

> If you try to make a visual language as flexible as a general purpose programming language Visual languages don't need to fully replace a general purpose language to be useful; a good combination is where you use text to represent the abstractions in your program, and visual tools to represent the values. You can see this at work in one of the most successful visual tools, the interactive debugger, now embedded in every IDE worth its salt. The program's architecture is written in pure text, but the execution traces can be filtered, watched and poked interactively, rather than the textual alternative of writing everything to a giant linear log file. Visual environments are best at the initial exploratory phase of software design, when requirements are not fully specified and the code structure is still fluid. What all visual languages so far are missing is a way to build (textual) abstractions from the initial concrete, visual design. This would allow the programmer to grow the program "organically" by working with the data, without the need to write down every abstraction from scratch in text. There are Programming By Example[1] techniques that could help with this, but they are not well known nor widespread. I have hope that some breakthrough in visual programming is still possible by creating programming languages that don't try to copy imperative programming, but instead exploiting the strengths of a visual environment. Tools like Apparatus[2] show that this approach is a viable one. [1] https://en.wikipedia.org/wiki/Programming_by_example https://en.wikipedia.org/wiki/Programming_by_example [2] http://aprt.us/ http://aprt.us/