Item — HN Reader

The way people have implemented visual programming has turned out to be a bit of an oxymoron. Visual and symbolic are entirely different channels of representation & understanding (for the most part). Representing a program using lines of code and throwing some "visual magic" to spread out lines of code across a screen doesn't take advantage of what EITHER visual or symbolic manipulation has to offer.

Visual programming efforts have tried to visualize code and operate at the wrong abstraction. Programming is just the act of creating programs. In a visual programming environment, the author / programmer should use visual interactions to "write the program". This means a few things needs to be considered:

- the representation - how is a computer program represented? how is state represented? - direct manipulation - imagine using a tool like Photoshop having to compile / build to see your changes between every edit. - input devices - mouse / keyboard works for writing lines of code. Touchscreen is a better input device / interface for visual programming but still lacking (no tactile response).

In my opinion, not enough is reinvented when visual programming efforts are tried. I think the entire stack (human input --> program state) needs to be reinvented and reconsidered. Bret Victor has a great section on visual program in his FAQ for one of his talks - http://worrydream.com/DrawingDynamicVisualizationsTalkAddend...

2 comments

I have been working on xol, a graphic based programming language.

xoL is a graphic based programming language. It represents programming concepts with graphics instead of text. It is product of a long, painstaking design effort, to get an optimal graphical presentation of programs. A good description of it is available in this blog post: http://lignixz.github.io/blog/posts/17/xoL_graphics_based_pr...

A partially working prototype from a previous version is available online. The newer current design has fundamental improvements over that previous prototype. The way some program elements work was redesigned. The control method was also redesigned. It is now aimed primarily at touch based controls. Here is the prototype for the previous version: https://github.com/lignixz/xra9 . The prototype is not optimized for performance so excuse that. It is functional to some extent, if you can figure how to use it. You can add and modify programming elements.

Would welcome any opinions/feedback. Also interested in finding partners/investors/sponsors that may be interested in this project.

It looks kind of similar to a dream project of my own. It's a project that I've promised myself to take up on one day. I started building a prototype in haskell, with front end in Gloss. Tried to get inspiration from functional reactive programming/modelling.

I thought about using something like a prototype called Hydra (1) as a sort of runtime for evaluating graphs. Anyway, I really want to get back to it at some point but other cool things that are slightly more low hanging tends to get in the way. :)

Another nice inspiration for these things is Ecolanguage (2), not really programming related but a diagram language for visualizing economic transactions.

(1) - https://github.com/giorgidze/Hydra (2) - https://www.youtube.com/watch?v=-QI1iuAvTKE

I have been working on a visual programming language for Haskell: https://github.com/rgleichman/glance Currently, it uses Diagrams and Graphviz to visualize Haskell programs. Please email me since I think there is a lot we could discuss.

I'll take a look, but if I never get back to you I would like to share with you this one important concept that has caused most efforts to fail.

Let me start with a quote from Brian Kernighan "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

When you make a graphic based programming language the debugging better be twice as good as the programming and this includes when things get really difficult with lots of threads, or when the over arching abstraction breaks at some low level and you are exposed to the underbelly of the CPU. At least C++ lets you gracefully traverse from the very high to the very low which is why it is favored in the end, you are never stuck you can always go lower.

I wonder how Victor's Realtalk project will incorporate his interest into visual programming: https://harc.ycr.org/project/realtalk/

Also, for anyone interested it looks like he just posted on HN for the first time under user 'worrydream'.

It's going to be entirely different I feel. Instead of manipulating graphics on a flat screen, focus will probably be on manipulating physical objects on a table / in a room.

Watch his 2 talks that highlight the thinking and inspiration behind the RealTalk project:

https://www.youtube.com/watch?v=klTjiXjqHrQ https://www.youtube.com/watch?v=agOdP2Bmieg