There is a long history of Visual or Graphical Programming Languages, and most of them make more sense than the name of Microsoft’s Visual Basic, C#, and Visual Studio IDE. Some people don’t like to code, and for them, graphical programming languages replace semicolons and brackets with easy-to-understand boxes and wires.
This Friday, we’re going to be talking about graphical programming languages with [Boian Mitov]. He’s a software developer, founder of Mitov Software, and the creator of Visuino, a graphical programming language for the embedded domain. Everything from the Arduino to Teensy, ESP8266, ESP32, the chipKIT, and Maple Mini are supported with this IDE. It’s a simple drag-and-drop way of programming microcontrollers that Scratches an itch (see what I did there?) for an easy way to introduce non-programmers to the embedded world and also provides a faster way to build custom applications.
When it comes to graphical programming languages, we can’t find a better Hack Chat guest than [Boian]. He’s the author of the OpenWire dataflow processing technology — another graphical programming language –, the IGDI+ library, VideoLab, SignalLab, AudioLab, PlotLab, InstrumentLab, and author of VCL for Visual C++. He’s a regular contributor to Blaise Pascal Magazine, too.
During this Hack Chat, we’ll be discussing what makes Visual Programming worth it, how and why it works, when it doesn’t and how to develop a graphical programming language. Visuino will be of special interest, And I’m sure someone will work in a, ‘what’s happening with Max/MSP under Ableton’ question. If you have a question for [Boian], here’s a question sheet to guide the discussion.
Here’s How To Take Part:
Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. This Hack Chat will take place at noon Pacific time on Friday, August 11th. Here’s a time and date converter!
Log into Hackaday.io, visit that page, and look for the ‘Join this Project’ Button. Once you’re part of the project, the button will change to ‘Team Messaging’, which takes you directly to the Hack Chat.
You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.
Thank you!
Well… my name in Boian, not Bojan, but close enough ;-)
Oh Dear, sorry for that mistake Boian. I’ve made the changes here and on our event page. Looking forward to the Hack Chat on Friday!
Thank you! :-)
“Some people don’t like to code, and for them, graphical programming languages replace semicolons and brackets with easy-to-understand boxes and wires.”
The writing it down as it where is the easier part. The understanding and breaking down a problem into an efficient form a computer can deal with is the harder part, and the tools don’t help as much.
This.
Being a car mechanic is difficult and dirty work, you know what, if we make all the parts red and paint giant numbers on them! Then it’s no longer difficult and dirty! See how ludicrous it sounds when you translate it to a different field?
(I’m not saying a few graphical programming things have their place in the world. Especially for teaching kids. But there is a difference between a tool and a toy)
Actually it has been shown that if you color coordinate machine parts and number them, it does make putting many types of machiNed together a whole lot simpler (cars, rockets, ships, planes, etc. Now programming isn’t the same thing and your right it requires the abilities to break down tasks/problems into smaller and easier tasks as well as problem solving, but what does that have to do with whether it’s in text or graphics? In fact it doesnt. The only argument that I’ve ever read has been that it’s usually a lot faster for someone to type out code instructions then to drag and drop them, but this logical only applies if someone is using a keyboard. What about a programming using your phone? From my own experiences it’s the opposite. Graphical programming is still very new and like all new things there are those who will be repealed about it passionately. That is just one of the prices for progress. Take care now.
Visuino actually allows you to solve this problem. With it you don;t have to break down the problem into a sequence of execution, but in functional blocks like Generator, Stepper Motor, Sine Wave generator etc. It is a dataflow solution very different that something like Scratch as example, where you still have to code ;-)
No, it doesn’t solve the problem. In fact it only makes it worse in the long run because the essential skill of breaking down a large system into smaller parts isn’t learned. Your solution is a dead end one as it develops no usable programming knowledge for someone to progress with. There’s nothing with any weight to add to a resume. Labview is a usable skill in some engineering and scientific work. Simulink is the most useful as its used in everything from vehicles to spaceflight and it generates safety compliant code. Visuino is a toy. Scratch at least teaches programming structure and the thought process.
Well.. we all have different opinions :-) If you think that Visuino is toy, that is good :-) . At least kids will have fun with it. I use it myself, and I developed it originally for myself to solve my own programming problems, and a fair number of professionals already use it, but what I really want is the kids to use it, and the younger the better, so your opinion that it is a “toy” tells me that I have succeeded in my primary goal, of making programming microcontrollers as much fun as playing a game :-)
Traditional sequential programming in my opinion is obsolete, and not well suited for modern computer architectures, so teaching people programming process with scratch or other programming languages to me is teaching them something that is completely obsolete, and akin to teaching them machine code programming. Does it have some specific ocasional value? yes. Is it the proper way to design complex systems, and software? IMHO – no ;-)
Again this is my opinion, and I respect the opinion of others :-) . We want diverse and colorful world, not single opinion or solution :-) . The more the merrier… :-)
Modern computer architectures when one gets down to the heart really hasn’t changed that much. We’ve added layers but the basics are there. There are academic CPUs that break some of the model, but they’re still academic and suffer the same fate as most do. The harder part in all this isn’t hardware, it’s people and their limitations. Any design is something people have to be able to wrap their problems around, and by extension, us. There’s also the inertia in that any solution has to be better than the old, otherwise why use it?
“There’s also the inertia in that any solution has to be better than the old, otherwise why use it?”
Exactly! Visuino allows you to create a very complex program in 2-3 minutes, and simpler one in 20-30 seconds. The same takes hours and days in traditional programming. So here is the reason I use it myself, and others use it too… ;-)
Speeding up and simplifying the development by orders of magnitude is probably what people will call “better than the old” ;-) If you don;t believe my statement, you can watch some of my video tutorials. Rarely a project takes more than 1 minute to develop from scratch, and I do many projects every day as part of my work. This would not have been possible without Visuino ;-)
You’re making the assumption that he’s giving any merit to Visuino at all. He doesn’t seem to be in any way. I would tend to agree with him. You’ve made a closed, dead end solution that hinders the development of essential skills. Your statement about how modern processors work shows you don’t understand how modern processors work at all. We’re also talking about an 8bit AVR core.
You claim it takes hours or days? That’s grossly exaggerated to read from a sensor or move a servo. You repeat how hard it is, and how long it takes then casually develop a graphical language IDE that is orders of magnitude more complex than even reading and manipulating a few registers on a micro using bitwise operations. It’s not hard, and once someone bothers to actually learn it doesn’t take very long to do simple tasks.
Hound,
Yes, doing a simple task does not take long. Doing simultaneous tasks however is quite complex. Furthermore Visuino programs on only AVRs, it programs Teensy, chipKIt PICs, ESP8266, ESP32, FreeSoc2, FemtoIO, Maple, and growing number of other platforms. Again, it could be just me, but trying to control the speed of stepper, while at the same time controlling ultrasonic ranger, has proven to be challenge for me doing it in traditional code. This was the reason I actually did the project for myself at the beginning.
Everyone decides for himself what tools are best. The diversity is a great thing, and the more tools and options we have the better :-)
It sounds a bit foolish to me however to judge a solution that you have never even tried for couple of minutes… ;-) At least take a look at it, to see how crappy it really is, so you can bash it properly… :-D
Exactly. The difficulty of programming isn’t in the program representation. It’s in actually figuring out what you want to achieve and how you’re going to explain that to the computer.
I get what you are saying .. but there are situations where graphical programming tools help enormously.
I spent a long time developing stuff for process control systems that used IEC-61131 programming languages. These allowed chemical and mechanical engineers, who were not necessarily code jockeys, to to a respectable job implementing process control strategies. Of course, if you were a better programmer, from the standpoint of being able to model algorithms really well (just as you describe), then you could make better use of the tools. And, of course, if you really wanted to go crazy, you could do a bit of meta-programming, and write programs (usually in some textual scripting language) to generate the programs .. and then folks could graphically see what you hag magically generated (hey — auto-documentation!)
And currently, I do a lot of node-red programming. Much faster than writing web-sockets, MQTT stuff, serial interface code etc by hand .. just plunk down the requisite blocks, wire them up and you’re good — because graphical languages compel the designer to think carefully about that a programmer tends to do over and over .. so the graphical components then offer a standard way to implement typical tasks. Of course, you can meta-program node-red too — it’s just a JSON document that parameterizes and wires together standard building blocks that.
At any rate, I have done my fair share of graphical and textual programming, and graphical programming unquestionably has its place .. whether as an easy on-ramp for beginners or as a way to rapidly knit together self-documenting code that is heavy with “boiler-platable” stuff ,, or, in some cases, it’s a great match for the conceptual elements of the problem being solved.
I’m surprised people aren’t mentioning Unreal’s Blueprint. Granted not everyone deals with a game engine, but it is one of the more popular ones. I believe Unity has something similar.
Is it Friday?
Yes
Have been using LabView for over 20 years, with no pleasant experiences. LV is an accident waiting to happen.
A reasonable analysis will have nothing to do with evaluating GUI stuff. The analysis of “visual” stuff should be data flow vs. imperative.
I was going to make a comment about LabView, but I see you’ve gotten there first. I only used it at university, but even there making anything non-trivial was an exercise in frustration.
One of the main issues for me was having to find the correct symbol for the thing I wanted to do, you already know what it looks like, what it does, and what it’s called, but you still have to go churning through UIs to find it. Then of course there’s the issue of making it ‘readable’ (not sure what else to call it).
Perhaps you eventually become so proficient with the UI that hunting for the right symbol is no issue, perhaps you learn all the keyboard shortcuts (in which case you may as well be typing). Perhaps if I’d been introduced to graphical programming first I’d love that more than any of the others.
Again, I believe that Visuino offers “a bit” friendlier experience than LabView ;-)
“One of the main issues for me was having to find the correct symbol for the thing I wanted to do, you already know what it looks like, what it does, and what it’s called, but you still have to go churning through UIs to find it.”
Kind of a graphical auto-complete is needed.
In LabVIEW it’s called ‘Quick Drop’. Hit Ctrl+Space and start typing the name of the function you want to place. You can create your own custom shortcut names for any function you want. Once you’re used to it, you almost never use the graphical function palettes again. Creating a ‘clean’ program is often frustrating, but as an electrical engineer turned full time LabVIEW developer for 10+ years, the graphical nature of LabVIEW gave me the ability to create things I wouldn’t have otherwise been able to via text based programming (because I am a visual learner, not because of anything lacking in text languages).
People can rip on graphical programming (and LabVIEW in particular) all day long, but I never had a particular interest in programming, then suddenly found myself primarily writing software for the next decade in an environment that matched the way I think and learn. I’ve also seen my text programming interest and skills improve due to using LabVIEW. Like anything else, it’s just one tool of many that fits some problems and some users quite well, while others, not so much.
I think you will discover that Visuino is “a bit” better than LabView ;-)
I no for me a Person that no’s nothing about programing Visuino is a lot better than LabVIEW. It takes something the average person can not due and makes it possible. For me it was being able to program my 4′ tall Skeleton Robot. Thank You Boian
Thank you Chris :-) !
You know you should put the Skeleton Robot on Hackaday.io as a project. I am sure a lot of people would love to see it, and you may get some valuable input and help ;-)
Why does this feel like a planted comment?
You probably should ask Chris ;-) . I guess it is, because I have been blessed a lot of fans, and sooner or later one of them posts… :-D .
“Graphical Programming Languages”
Like GeoForth?
We probably will talk mostly dataflow programming like LabVIEW, Visuino, Embrio, but may cover some other concepts like Scratch etc.
Something like what LEGO Technics uses?
Not quite. If I am not mistaken LEGO still uses sequence diagram, similar to programming. The plan is to focus on Dataflow design, where you specify what controls what, and let the editor figure out how to write the code. A much higher and easier to use design concept. Kind of like the way you hook your DVD/VCR to the TV and not focus on what signal and how each will send ;-)
I was joking about the geoForth. Have you considered any of the open source alternatives to those tools such as MyOpenLab, etc?
We can talk about MyOpenLab etc. in the chat :-) . Since among many other Dataflow products, I also develop Visuino, and since Arduino programming is specifically challenging among inexperienced makers, for anything more complex than reading single sensor etc. I plan to mainly latk about it, but we can discuss other products and concepts too :-)