DRAKON – An algorithmic visual programming language

Grasshopper (Rhino) is quite successful for architecture and 3D modeling, but its also tied to the engine. Also see https://news.ycombinator.com/item?id=7274674 for an exhaustive list.

1) I think although LabView is quite useful, it's interaction design is terrible (that users play along only attests to it's utility!)

3) It's essentially a way of displaying code, so perhaps any new languages could reuse the same graph/flowchart environment. But inherently visual languages are designed either towards people who don't want to learn a language or who are performing specific tasks where the graphic flow improves their reasoning. I'd say for the vast majority of 'coding' those are not the case, since the "concept density" is very low (but visual UIs may help a lot of get started programming people anyway).

Having a graphical environment also helps remove a lot of cruft from languages that newcomers shouldn't really have to deal with.

For example, if I want to make a C program to computer the distance between tow points on a plane, I have in my head something like "d=sqrt((x1-x2)^2+(y1-y2)^2); output d", and actually programming I'm going to have to import a couple of libraries to take care of both floating point arithmetic and IO. The only way a novice can know that is looking at an online reference basically; while a decent UI could easily provide a searchable list of math/IO functions and include libraries automatically. Those are always taken care of in visual programming languages. The syntax itself of languages is arbitrary in many ways you have to learn on a case by case basis (in the example, how exactly do you use printf to "output d"?), while in an UI you are forced to use the correct syntax, because it's the only option.

When you are programming an operating system or low level application none of those really matter, but for a newbie making a simple Mobile app it's going to involve googling a lot and copious amounts of copy-pasting templates for getting trivial things done.

> The guys at Epic

The people at Epic. Sorry, I know it's annoying, but sexism in computing isn't going to change if we don't pay attention to the language we use.

Interesting how this could tie into the diagrams coming out of the dataflow paradigm (flumejava, flink, millwheel, naiad, and Frank McSherry's rust timely-dataflow). All of which can be succinctly diagrammed out, but I like the rigor of this. People in this thread have mentioned Max/MSP (it's precursor puredata/pd) are really interesting visually, but they often feel write only. Some of the rules of drakon could be attempted in a max patch, but the shortest path nature and lack of jump labels could foil the idea.

At any rate, some food for thought when it comes to trying to ideate programs away from a computer or at least away from a repl or IDE.

Some of the data flow representation software enables us to do this, I guess. From UML diagrams, we could create classes etc