When is visual programming too visual?
removingalldoubt.com
removingalldoubt.com
One of the things I really like about beginners having interface builders is that they can bridge the context between the code and the user interface in a way that is more meaningful than you get out of even web applications. To get started building interactive prototypes, you can draw first and flesh it out later, vs. learn how to draw in markup/code and then learn how to glue it together.
Some of my earliest memories of finding real accomplishment in programming were using Visual C++ and Visual Basic. While I had written a ton of absolute crap in BASIC and C before, the toy projects were relegated mostly to scripts and whatever text or ANSI interfaces I could dream up. I felt like I had made something accessible to other people. Also, my UI design skills got 1000 times better when I had an easy, accessible way to approach user-oriented design simultaneously with the behavior, and it helped me better learn how to divide my code up in ways that made sense.
Consider electronics. One engineer can create an electronics schematic and hand it to someone else who will build it and the second engineer will build what the first engineer specified. Right now, no such thing like that exists for software that isn't effectively a 1:1 mapping to source code. Flow diagrams and UML ain't it. And there's so much ambiguity in higher level diagrams (here's some layers, here's some lines, here's a thing that looks like a cloud) to make them only barely useful in describing software.
There is no standardized nor de facto schematic visual language of software that enables one human software engineer to specify the design (not even the full implementation) of a software system sufficiently enough to be able to hand that off to other engineers to build and be successful and predictable at doing so consistently. And if we can't get a system like that to work with humans in the loop we really aren't going to do much better purely digitally. You can program visually, but so often you end up spending more effort on minutiae than you would if you were coding textually, and so often you run into a very low ceiling where complexity becomes unmanageable.
P.S. Using interactive visual tools for things like UI design, that can be and always has been very beneficial, but that's a far cry from "visual programming".
Maybe that is the path we should take.
Create IC modules for apply, map, filter, fold, ... instead of adder, half-adder and so on.
I bet lots of lambda calculus programs could easily map to such constructs.
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.
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.
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.
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
[2] http://aprt.us/
I think where it really breaks down is when you have loops. And loops within loops. Text is much more friendly for that.
I have this idea that this problem could be solved with a visual flow language where, at runtime, you could see the collection of all values that each node is emitting during program execution, rather than just the current value. I have not seen that approach in any flow language, so maybe I'll implement this idea in the future as an experiment.
http://dist.alternativeto.net/s/bbb84d61-31f2-de11-8cae-0022...
Correction: I remember the underlying scripting language being GML (GameMaker Language). Maybe Delphi was embeddable into early versions of GameMaker? I also know that you could link plugins as DLLs...
It was a lot of fun and I found it impressive how easily you could throw things together. It was a nice change of pace from learning C++, where I had not yet gotten into graphical libraries.
On a related note, I also experimented a bit with RPG Maker, which allowed for some simple scripting and made it very easy to quickly create environments using sprites. https://en.wikipedia.org/wiki/RPG_Maker
[1] http://www.avs.com/solutions/express/ [2] https://cdsweb.cern.ch/record/400582/files/p69.pdf
The real visual programming is not quite there yet, and may never deliver at all: it's the stuff like LabView, Scratch, DRAKON, etc.
Tha said Delphi managed to sit somewhere in between, a little bit, which makes it an interesting case.
It's certainly not perfect. In practice, I quickly found that it adds a new level of obfuscation, due to the physical constraints of the 2D-space in which it is being visualized. In short, it easily becomes a mess of tangled connections and sometimes you may have difficulty physically locating the block you want to interact with.
Still, there's not a doubt in my mind that this is a great tool. Not a great tool for a team of programmers, but a great tool for a game studio as a whole. It allows designers and artists with limited technical knowledge to prototype game modes and develop user interfaces, without involving any programmers. Sure, they may need some help from software engineers who create new entities or guide them towards a cleaner design. The end result is still impressive: non-coders are building large parts of the game logic in a very intuitive way which requires no knowledge of code of any kind.
In essence, I see this type of language not as an alternative to writing code, but as an amazing tool allowing non-coders to to develop large portions of a program's functionality. Naturally, my own experience is essentially limited to the niche of game development. I don't know how useful this would be in developing, say, a website centered around an online shopping portal.
But scripting anything more complex and especially user interfaces is awful. The designers will back themselves into all kinds of corners and there will be all kinds of edge cases not handled and subtle bugs and tracking them down is very very hard.
There was one company started by x-Insomniac people IIRC that decided there should be no designers scripting. All scripting should be done by programmers. Their experience was that trying to make programming easier for non-programmers sounds great, and it is for introducing people to programming concepts and enabling them to make things, but when it comes to shipping code it's not great and too much time is spent dealing with the mess of spaghetti they make.
Note I'm not harshly judging designers here. Great designers make great design. I'm only saying that experienced programmers are more likely to write efficient, maintainable, bug free code than non-programmers.
In the end, though, when you have built up an existing team of designers and artists who know how to work in that environment, they can often train newcomers and help each other figure out some rather non-trivial stuff without it resulting in a terrible mess.
Also, the way it's used where I work, the majority of these tasks are essentially shoveling data between different parts of the system and hooking existing things up to each other.
I haven't tried it, but I was pleased to see that there's at least one current product that supports the underlying dataflow language: http://www.andescotia.com/products/marten/
This was way too visual for me, once you got accustomed to writing code, checking it into your VCS.
https://cycling74.com/products/max/
It looks like something people coming from a modular synthesizer background should be able to get.
In fact it makes a lot of simple tasks hard because something trivial like a loop takes an unexpectedly distracting amount of pointing, clicking, typing, dragging, and joining. The DSP and openGL parts aren't too bad, but hacking together non-trivial event and data processing logic can be torturous.
This is the big problem with dataflow - it makes you keep switching mental modes from visual object recognition to spatial understanding to text parsing/editing to causal modelling to UI design.
Text has its own issues, but it lets you stay in one mode.
I think VB and Delphi had a lot of success because they hit a sweet spot between the two. They let you solve visual and UI problems visually, and logic problems with code.
Webspace still doesn't have an exact equivalent. Flash came close, but the animation stage added an extra layer of complication. Most web design tools don't do a good job of simplifying and abstracting the relationship between onscreen elements and code the way VB and Delphi did.
That's because you don't create loops or if-statements in graphical programming languages, in the same way that you don't create loops or conditionals in functional programming; you use map, filter, etc.
Lots of great info, thanks for posting it.