Early programmers had to represent code using binary, octal, or hex numbers. This gave way quickly to representing programs as text to be assembled, compiled, or interpreted by the computer. Even today, this remains the most common way to program, but there have been attempts to develop more visual ways to create programs graphically. If you program microcontrollers like the Arduino, you should check out XOD and see how you like visually creating software. The software is open source and currently, can target the Arduino or Raspberry Pi.
You can launch the IDE in a web browser or download a local copy. You transfer nodes from a palette into a grid-like workspace. These nodes might be inputs, outputs, processing blocks, or represent real-world I/O devices. Nodes have inputs and outputs of specific types and you connect them together, connecting like types only, although there are blocks that can convert.
For example, to the right is a simple set of nodes that forms the prototypical flashing LED program. A clock node creates a pulse that toggles a memory element and a digital output accepts both the signal and a constant value indicating which port it represents.
This is a simple example, but it does show the intuitive flow of joining nodes. There is a reasonable array of node types and sufficient documentation.
There are out-of-the-box nodes for ultrasonic sensors, temperature sensors, servos, LCDs, buttons, and H-bridges. You can create your own super-nodes (patches) and you also can make multiple disjointed flows to execute more than one task at a time.
When you generate the code you get a lot of boilerplate that sets up the run time system and the nodes you use. Your main code appears to be in an evaluate function. For example, here’s a snippet of the code that corresponds to the simple graphical blink program:
void evaluate(Context ctx) {
State* state = getState(ctx);
TimeMs tNow = transactionTime();
TimeMs dt = getValue<input_IVAL>(ctx) * 1000;
TimeMs tNext = tNow + dt;
if (isInputDirty<input_RST>(ctx)) {
if (dt == 0) {
state->nextTrig = 0;
clearTimeout(ctx);
} else if (state->nextTrig < tNow || state->nextTrig > tNext) {
state->nextTrig = tNext;
setTimeout(ctx, dt);
}
} else {
// It was a scheduled tick
emitValue<output_TICK>(ctx, 1);
state->nextTrig = tNext;
setTimeout(ctx, dt);
}
}
There are a few rough edges, which isn’t surprising for new software. For one thing, nodes have fixed numbers of inputs and outputs. So if you want, for example, a ten-input AND gate, you’ll have to build it. Another apparent issue is there is no way we found to select a lot of items at once. If you decide you want to move a whole bunch of nodes down to make room for something new, you are going to be in for a lot of work.
There are other drag-and-drop programming languages, of course. We’ve covered Scratch for the Arduino and the Raspberry Pi, before. However, this is a dead simple way to try flow-based programming with minimal setup.
in before;
https://imgs.xkcd.com/comics/real_programmers.png¨
better abstraction tools are always welcome.
https://imgs.xkcd.com/comics/real_programmers.png
ahh the foibles of not having an editing feature, guess i will have to live with it…
Truth be told… the && operator in C also takes only two inputs. The generated code is far from pretty too… I don’t expect a masterpiece from such a tool, but indentation would be nice!
True but linking then is possible in the same statement left to right without cascading. So if the blocks had a Cascade in pin that would be a better analogy. This would be really good for selectors for example.
Parens but admittedly I’ve never tested the nesting depth.
For C, the major IDEs generally support a nesting depth of 256; would think the compilers keep up with that if not exceed it. That includes brackets, parenthesis and quotations within the same group. If you would like to automate the testing of this you can safely assume it will most likely be a power of 2.
It just happened that this weekend I searched for something similar. So far didn’t found XOD, but found these instead:
– LabVIEW RT or Matlab Simulink – both very powerful, very stable, closed source and very expensive
– Scilab Xcos – powerful, unstable, open source, free
– MyOpenLab – enough power, stable, open source, free
Will give it a try to XOD, too, thanks!
Tested XOD with some analog input mirrored to a PWM output, while logging the timestamped analog input value to the serial port, while blinking pin 13 LED, just for fun. Well, it’s working.
Noticed that un-clocked blocks are optimized out. Also, it is not so reach in functions as other older products, but most of the necessary blocks are already present. Looks very promising. Fast enough for normal use, 1ms step with output logging to serial port was working just fine.
As far as I tested it, it was very stable. Couldn’t crash it (except that it hanged once, when the serial ported was kept busy by another terminal program), but otherwise it was rock solid.
I liked it, well done!
In a class they had us program FPGAs with a schematic layout tool and with verilog code. I’m an EE so I thought I would like the schematic layout better, but it turns out code is much faster to write and easier to debug for anything more comple than a few components.
I had the same experience when I learned fpga. The best example is to do a 7 segment decoder in schematic and then again in verilog.
I agree. The further you get from the code the harder it is to find out where those inevitable and spontaneous interesting features lay within the output. Unless it’s an incredibly noddy executable, at some point you have to dig in to the output, at which point you’re invariably left looking at a bunch of random and indecipherable XXEeUT001 style function and variable names trying to figure out what the hell is going on.
A similar programming system, LabView, from National Instruments has been around since 1986. It was originally developed for the MAC but is also available for the PC. Mostly use for laboratory and industrial control but a home and student version is available for $50 USD. It can be used with LEGO Mindstorms as a teaching tool, and elements can be ported to the Raspberry Pi.
Yes although labview is a giant hodgepodge of features. The fpga stuff is a miserable hack. Great for prototypes but I can’t tell you how many times I’ve seen projects churn on trying to get lv to work the way they want and wind up spending more than they would have to do it in a way perceived as more expensive.
$50? We’re not all JD Rockerfellers.
” However, this is a dead simple way to try flow-based programming with minimal setup.”
Human mind as IDE.
Yeah, install this thing and see how it CONTAMINATES your environment, not to mention probably clobbering your installed binary versions newer/later than what already exists. This is the problem with this crap, especially in Linux – LEAVE THE MACHINE ALONE! Just install a stand-alone, don’t touch the system at all, and tell us where the damn thing lives. Don’t touch this stuff unless you try an install on a disposable machine or in a hard-bastioned VM.
I like visual programming environments, at work sometimes I have to use LabView, but as far as I know no visual programming environment can handle revision control and merging like what can be done with text based source code. This precludes or makes it very cumbersome for teams or bigger projects.
LabVIEW does have some diffing ability, but it’s definitely not as powerful as text diffs. Diffing dataflow languages seems to require a much better understanding of what the code is actually [i]doing[/i] than text diffs.
Ah, yes, yet another tool to abstract away the very easiest part of programming: syntax.