5 ms·

There's looking to be a lot of value in visual languages - this isn't the first one to hit the FP in the last few weeks. We're probably beginning to appreciate

There's looking to be a lot of value in visual languages - this isn't the first one to hit the FP in the last few weeks. We're probably beginning to appreciate the limits of text-based programming, and hopefully enough work goes into something different to create a tool with real productivity using visual code. The only trouble I can see is that there isn't a lot of speed at the moment in dragging and dropping to create graphs.

jbl 9y ago
I've been going back and forth on this for a while as I work on a product that allows users to build applications in a drag and drop visual manner. What I've seen is that while novices fairly quickly ramp up and get productive generating basic CRUD apps rapidly, they also rapidly hit a wall in two ways: 1. It can be hard or cumbersome to express more complex logic 2. The drag and drop interface often leads people to -assume- what the runtime will do. Right now, I'm leaning toward feeling that visualization should be a tool to understand the _behavior_ of what one has written, but not necessarily the thing one manipulates to express a program. Ballerina seems to be this, so I'm excited there!
krylon 9y ago
I currently have the "pleasure" of building a SharePoint workflow, which is done by clicking together building blocks in a graphical builder (running as part of Visual Studio). Maybe I am generalizing to hastily, but I absolutely despise the experience. In theory it sounds like a nice concept, in practice it tends to make trivial tasks exceedingly complicated[1]. And what would be a screen of code is several screens full of a block diagram. It is possible to zoom out, but text gets unreadable fairly quickly. [1] To be fair, I think that is probably more of SharePoint problem, whose complexity would be hilarious if I did not have to deal with it.
- onetokeoverthe 9y ago
  You'd probably appreciate the movie Zero Theorem. The hero, a coder, is doing the same procedure...it's by the Monty Python people.
  - krylon 9y ago
    Thank you! Terry Gilliam has made some great movies (although I found Tideland too intense to watch). This one is now on the top of my to-watch list.
heavenlyblue 9y ago
It seems to me the next "graphical language" interface should be more like working in an IDE, but instead of entering the text directly and having the hints provided - we reverse the problem and only allow the user to enter what is allowed by the syntax of the language. That would essentially generalise to "creating visual code", only now it would use the keyboard instead of the mouse.
sanjiva 9y ago
I'm leading the Ballerina language design. The team has about 15 engineers working on the runtime (and related tools) and about another 15 folks working on the browser-based composer and the IDE plugins. Ballerina's design point is to be a language with semantically equivalent text and graphic syntaxes. Its not a "visual language" really .. its a language with alternative syntaxes, one text and one graphic. That approach eliminates the "hit-the-wall" phenomenon of visual languages. And as other commenters have said, a lot of the graphical view is useful to understand overall structure and less to write lots of code. However, parallel code is much better visualized graphically as sequence diagrams are dead simple to grok. In terms of speed of the current Composer .. still WIP. Help is welcome :).

jbl 9y ago

I've been going back and forth on this for a while as I work on a product that allows users to build applications in a drag and drop visual manner. What I've seen is that while novices fairly quickly ramp up and get productive generating basic CRUD apps rapidly, they also rapidly hit a wall in two ways: 1. It can be hard or cumbersome to express more complex logic 2. The drag and drop interface often leads people to -assume- what the runtime will do. Right now, I'm leaning toward feeling that visualization should be a tool to understand the _behavior_ of what one has written, but not necessarily the thing one manipulates to express a program. Ballerina seems to be this, so I'm excited there!

krylon 9y ago

I currently have the "pleasure" of building a SharePoint workflow, which is done by clicking together building blocks in a graphical builder (running as part of Visual Studio). Maybe I am generalizing to hastily, but I absolutely despise the experience. In theory it sounds like a nice concept, in practice it tends to make trivial tasks exceedingly complicated[1]. And what would be a screen of code is several screens full of a block diagram. It is possible to zoom out, but text gets unreadable fairly quickly. [1] To be fair, I think that is probably more of SharePoint problem, whose complexity would be hilarious if I did not have to deal with it.

onetokeoverthe 9y ago
You'd probably appreciate the movie Zero Theorem. The hero, a coder, is doing the same procedure...it's by the Monty Python people.
- krylon 9y ago
  Thank you! Terry Gilliam has made some great movies (although I found Tideland too intense to watch). This one is now on the top of my to-watch list.

heavenlyblue 9y ago

It seems to me the next "graphical language" interface should be more like working in an IDE, but instead of entering the text directly and having the hints provided - we reverse the problem and only allow the user to enter what is allowed by the syntax of the language. That would essentially generalise to "creating visual code", only now it would use the keyboard instead of the mouse.

sanjiva 9y ago

I'm leading the Ballerina language design. The team has about 15 engineers working on the runtime (and related tools) and about another 15 folks working on the browser-based composer and the IDE plugins. Ballerina's design point is to be a language with semantically equivalent text and graphic syntaxes. Its not a "visual language" really .. its a language with alternative syntaxes, one text and one graphic. That approach eliminates the "hit-the-wall" phenomenon of visual languages. And as other commenters have said, a lot of the graphical view is useful to understand overall structure and less to write lots of code. However, parallel code is much better visualized graphically as sequence diagrams are dead simple to grok. In terms of speed of the current Composer .. still WIP. Help is welcome :).