There is a long history of graphical programming languages. 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. He specialized in video, audio, DSP, DAQ, industrial automation, communications, computer vision, artificial intelligence, as well as parallel and distributed computing. [Boian] is the author of the OpenWire open source technology, the IGDI+ open source library, the VideoLab, SignalLab, AudioLab, PlotLab, InstrumentLab, VisionLab, IntelligenceLab, AnimationLab, LogicLab, CommunicationLab, and ControlLab libraries, OpenWire Studio, Visuino, and author of the “VCL for Visual C++” technology.
For this Hack Chat, we’re going to be talking about ways to make programming microcontrollers easier. The focus of this discussion is Visuino, a graphical programming environment. Visuino allows anyone to program an Arduino, Teensy, or an ESP simply by connecting wires and choosing some logic. Think of it as a step above the programming environment that came with the Lego Mindstorms, Scratch, or whatever else MIT was coming out with in the early ‘aughts.
You are, of course, encouraged to add your own questions to the discussion. You can do that by leaving a comment on the Hack Chat Event Page and we’ll put that in the queue for the Hack Chat discussion.
Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. This week is just like any other, and we’ll be gathering ’round our video terminals at noon, Pacific, on Friday, May 25th. Here’s a clock counting down the time until the Hack Chat starts.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io.
You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.
Dagnabbit!
Programming is supposed to be hard!
That’s what makes programmers an elite caste!
Y’all don’t want any riff-raff getting in on the sweet benefits of programmin’…
Really wish I could remember the book, but it was a pseudo-hypothetical where the whole thing was approached from the domain side, not the nut and bolts side. Sort of the architect instead of the carpenter. That’s where the real skill and longevity is.
Really? Ever seen an architect actually build a house? Perhaps we should just stop confusing coding with systems design and leave it at that?
I agree with your underlying point. In the beginning programming was more simple and more complex at the same time. Dennis Richie, the founder of ASCII C and one of the main Unix contributors, goal was to create a more efficient, powerful, and easier way of programming. Later on we all know how Cpp expanded C as well as added a new paradigm known as oop or object oriented programming.
I know you probably know all of this, I’m just adding the info so other readers can understand the point I’m about to make and so you also have a basis for my point. Like it really matters ????
Programming isn’t supposed to be hard and in fact the easier the better. I don’t mean easy as in building LEGOs but, easier, as in more efficient syntax, more forgiving IDEs and compilers.
That being said, this visual crap is a joke and I agree with you that it has no place in our world. If you can’t learn to code then WYSIWYG, drag and drop, visual languages, simply won’t help anyways.
Either you have the mind for this or you don’t. What upsets many of engineers including myself is the morons who continue to try and bring even more developers into this already over crowded space! It’s bad enough that we are being called a “dime a dozen” by a large quantities of morons who have no clue.
To conclude, While programming languages are constantly evolving to make our lives easier. The visual language that we see above is nothing to fret over. In fact, look at it as a blessing. What quality software ever came from something as elementary as this? Programming isn’t supposed to be hard, and doesn’t have to be hard if you decide to stick to simple to-do list apps.
These abc-123 visual languages like the one we see here are less capable than basic, and will remain so. Don’t worry, you won’t see more efficient algorithms come to life with any of these projects. Visuino is just the latest of a long list of failures.
Pay close attention. With Visuino anyone can program an Arduino. To the individual who wants instant gratification and is too lazy to study day and night for a decade, will read right thru the catch! Visuino, being the brilliant visual programming language that it is has the same exact drawback as the rest of them.
Ready for it?
These Visuino engineers (sarcasm) get to choose from a list of pre-written blocks of code they usually call modules and then they have the daunting task of connecting the dots… I remember connect the dots when I was a kid. Whew! It was quite a challenge!
So don’t worry Ren… Those who seek the easy way out, cut corners, etc. Achieve nothing and end up with lousy results.
It’s pretenders playing with blocks.
Basically, Code describes, instructs, and links based on functions, objects, or depending on the language, multiple paradigms can be used in specific situations. Code is human readable syntax and I’m going somewhere with this… We found out a long time ago that descriptions based on pictures is pretty caveman and severely limiting.
We should call it what it really is… Programming for the special needs engineer.
No they won’t draw the solution to quantum computing.
No, there will never be an API created with a drag and drop or visual language… Visual language is an oxy-moron.
They can waste all the time in the world but facts are facts and behind a visual construct is code… Code that is locked in place and only has so many possibilities.
This is why I just do my thing and not worry about this stuff… In fact, it gets the weaksauce out of my way… So all the power to then.
Did you know that in Javascript, all you can do is use pre-existing javascript syntax? You can’t write assembly instructions at all, and everyone knows that real work is only ever done in assembly. I’m sure that Javascript will never take off.
Incidentally, shader programming in a lot of graphics engines is already done via drag-and-drop interfaces. These kinds of programming tools are already used widely in high performance production environments. To be fair, many of these tools also support dropping down in to the underlying language (GLSL, HLSL, etc) either for individual blocks or entire sections, but it’s entirely possible to write complex shaders and achieve good results without doing this.
To each his own opinion.
I see scratch, visuino, etc either as a first introduction to programming or a tool for “power users”.
Ever heard of IfThisThenThat ?
Of domotic systems that can be configured on the smartphone ?
Of the Turtle language ?
I remember when I began, C++ with Ogre3D were “hard” (among other things, g++ compile errors are not of this world).
On the other hand, BlitzBasic3D allows you to display 3d models in a few lines.
Nowadays, I’d puke by seeing my old BlitzBasic3D code, but I can say the same about my old C++ code.
crap, morons, lazy, failure, lousy
You speak like anyone who’s not a developer should be denied access to software legos, for both playing and simplifying their lives.
That they should stick to whatever gui we almighty developers chose.
In fact, this spares “noobs” from wasting a few years of their life just to change their lightbulb’s color.
In fact, this allows us developers to code reusable modules (which is good design) and users to plug them any way they want it.
“These Visuino engineers (sarcasm) get to choose from a list of pre-written blocks of code they usually call modules and then they have the daunting task of connecting the dots… I remember connect the dots when I was a kid. Whew! It was quite a challenge!”
Funny, “connecting the dots” is exactly what comes to mind about professional paid&legacy&boring programming.
It’s harder, takes more time, but has exactly the same value.
Well, for me it’s a hobby for an old man in my case. Visual programming is my only chance at possibly succeeding in my programming venture.
Just let me know how you get on with many things when you grow old, son…….
“Just let me know how you get on with many things when you grow old, son…….”
That’s why I make the effort to keep them young’uns off my lawn!
B^)
That’s absurd. You seem to believe that most programs are deep systems work. They’re not. Most programs are little more than a bunch of ‘when this happens, do that.’ type statements to put together the pieces. Exposing the ability to connect the pieces of a program easily is an extremely powerful tool.
Will someone have to drop to a lower layer to implement more complex stuff occasionally? Absolutely! But saying that you should have to study for years before you can do even basic programming is nothing more than simple elitism, of the kind that tried to keep reading and writing more complex than they needed to be to keep the masses illiterate.
> Some people don’t like to code, and for them, graphical programming languages replace semicolons and brackets with easy-to-understand boxes and wires.
more power to these folks if this sort of thing helps them out, and graphical programming should probably see a bit more research than it does, but the symbols and the typing aren’t the hard part of programming.
electrical engineers draw up their schematics with nice pretty boxes and lines (they can even fiddle around with actual physical objects that come in distinctive colors), but there are even fewer people running off to become (non-firmware) EEs than there are people picking up programming.
^ This.
Whenever someone at work tried to introduce a new programming tool (big words, fancy boxes, drag and drop, click-n-pray) with the promise that the business wouldn’t need as many developers, a recently retired developer/architect I worked with would counter with “That’s why they introduced assembler – so we wouldn’t need dev’s writing machine code”.
Coding is the easy part. 20 years ago a cocky younger self said in a job interview that “the language didn’t matter – I’d figure it out”. Now, in my middle years, I’m even more salty and sure of that statement. I’ve learned it’s the design, the environment and the politics that are hard to figure out. Not the language.
^^ both of these times 1000.
I remember back when the first “visual” coding tools like VB and Delphi 1.0 appeared, the marketing hype was “now the account manager can write his own programs without any coding! Fire your IT department!!!”. Me and my programming co-workers didn’t really believe any of it. Our skepticism was right.
And yes, the language doesn’t matter. In fact, the more languages you learn, the easier it gets. The language is not the hard part.
All three of these times even more! VB and its brethren were just one more wave in the “here’s a language to let anyone write great code”. Lest we forget COBOL!
Agreed, the only real limit in programing is one’s mathematical ability, once you have got over the basic mechanics of cutting code. What percent of people will have the high level maths skills but not be able to get their head around the low level skills? I teach my kids and they asound me with the stuff they do from time to time, yet it is always their current level in mathematics that determines the sort of problems they can comfortably work with, they cope with new syntactic conventions better than I can because their brains are so plastic and able to acquire language so rapidly. Ideas being another level of abstraction (or an entire stack of abstractions) take them more time, this is where I have an edge on them, for now. :-)
The bigger challenge is being able to think logically, akin to creating the sequence [i.e. algorithm] for a geometric proof.
Understanding the problem is most important.
Yes. Up to a point… i think most programmers earn a living writing the same things over and over again. Very few are at the frontline of new and exciting technology; most write boring business-oriented programs. Counting money, beans or bloodcells. And after a while, there really is no problem you haven’t solved before.
Suppose that depends upon how one defines “boring”.
http://adaptiveobjectmodel.com/
There are certainly many programmers who write the same things over and over again using the same old tools and I’ve met quite a lot of them (Windev, Delphi and VB programmers most notably), but I generally classify them as bad programmers.
Good programmers learn new things because it’s a domain of constant evolution. I’ve been programming for more than 30 years and I’ve never learned so many different concepts, paradigms, techniques and tools than in the past few years.
Good applications implemented today are very different from the ones written even 5 years in the past, not only because of technological changes, but because users expect more from their software in terms of user interface and they now ask them to solve new problems that were previously out of reach for a machine.
The whole point of Visuino is that you should not think sequentially but specify what data flow you want, and let the Visuino figure out the sequencing ;-)
There have been SO many attempts to do this over the last 20 years. Every single one has failed miserably. Please stop.
Unreal as well as Cryengine (among others) uses a graphical language. Most wouldn’t call that a failure.
They use node editors. You can be sure there are still people hacking away on the back end to make things work.
Of course text-based programming systems spring in to the world fully formed.
The Godot game engine supports visual scripting : http://docs.godotengine.org/en/latest/getting_started/scripting/visual_script/getting_started.html
False .. most factory automation uses a mixture of Ladder Logic, function block diagrams and Sequential function charts, and production is often coordinated by batch supervision systems that are also graphically programmed.
Every day, you use dozens of things that were produced in factories whose automation systems were programmed using graphical languages.
Whole marine industry is using Kongsberg systems for… well everything and most of it is programmed with graphic language. Have never met a PLC based system that was programmed in something different than ladder or block programming language (although there could be some). We still have Simulink (and even XCOS – whatever happened to RTAI) that produce applications (sometimes even for targeted platforms). I’m not sure how much can be done with Scratch.
Anyway visual programming works fine in industry – it is just not solving every problem, just few of them. Same like any other language.
This seems to be a US bias statement that I have noticed about PLC programming being ladder, FB and SFC. We tend to use FBD or may be SFC at a higher overview level but any real work is done in structured text. Lots of other code from other companies I have looked at is like this too unless its only basic automation.
While this is true, it concerns relatively simple programs whose goal is to be very reliable or easily doable by non-programmers (ETL software like Talend for example). Most software are much more complex than that and can’t be programmed with such simple visual tools.
Bring back BASIC!!! It was just about the easiest way to learn to program back in the day. It took me about a year to figure out there is a difference between “=” and “==” in C programming.
Maybe you need glasses? How can you not notice the difference; every primer on C I’ve ever seen calls special attention to this particular pecularity. Not to mention most programs won’t work properly if you confuse the = and == operators.
If this is such an obvious thing to avoid, then why does gcc have a particular error message for just this issue? Many programs will in fact appear to run correctly with this bug in place, hence the special warning message.
Because assignments are legal conditions, and in certain cases the compiler can infer that no logically resolvable branch can exist off the given usage or the value on the right is unassignable to the artifact on the left?
It has the error to check for unintentional usage (fat fingering). OP didn’t accidentally use the operator, as stated he didn’t understand there was a difference.
The assertion “Not to mention most programs won’t work properly” is patently wrong, because there were many many programs that shipped for years with this bug. The textbook warning was clearly 100% useless, because it was only the introduction of the warning message that caused the bug to be found. Clearly C is a language for computers and not for people, I’ve been saying this for decades. There are far too many gratuitously stupid design mistakes like this one.
If that’s true, you shouldn’t be programming. That particular “nuance” is covered in the first few chapters, operators section of every programming language manual, ever.
I don’t want to say rtfm, but, rtfm.
The concept of “equality” in programming is far more complex than == and newbies can be excused for not understanding the subtleties between the equalities of pointers, the equalities of strings, the equalities of floating point numbers, etc.
And in PHP there is =, ==, and also ===.
And in Perl =, eq, ==, eqv, ===, =:=, and ~~ to make things even simpler. :)
I got lost after they ditched line numbers
B^)
There are advantages to both graphical and text based programming.
Digital logic designers use schematic capture to design simple logic circuits. When designs get very complicated text-based HDL becomes a better alternative.
In my mind this works the same way in the software world. Simple programs can be accomplished very easily in a graphical environment. However as the code gets more complicated and involved, one needs text-based programming. If you’ve ever seen a rather involved LabView VI, you’ll know what i mean.
You do know that text is just a bunch of graphical symbols? You do know that most business processes and analytical analysis are programmed using graphical tools? Investment firms and HMOs have been using graphical tools for many years now for complex “big data” analysis.
Processed differently in the brain. One could say the world is *just* a bunch of atoms, but that simplifies everything to the point of uselessness.
“It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.”
-Albert Einstein
The point is to transmit information from the screen into the brain. It does not matter if the information is in English or French or pictures. If your work has hierarchies then you are really handicapping yourself by shoehorning it into a textual form.
You’re only handicapping yourself if you continue to try an work in a way or in an environment that simply does not work for you. Different people learn in different ways.
Yeah but investment firms & HMO’s aren’t using graphical tools to create complex and intricate systems such as an operating system or an RTL design for the CPU.
Bottom line use the best tool for the job. But most people will find that textual-input is better and easier to maintain when the job gets really complicated.
“whatever else MIT was coming out with in the early ‘aughts.”
https://mitpress.mit.edu/sites/default/files/sicp/index.html
Shitty site. Slow loading. 400×300 blurry png sceenshots. Top bar that takes up 1/3 of a mobile screen in landscape mode… I could probably find more issues if I looked at it for another 30 seconds.
Dunno about the rationale for this stuff targeting the hobbyist. As a (reluctant) user of LabView for over 25 years, have come to really hate this ‘visual’ programming. Quick to write, difficult to support.
The core argument is NOT graphical vs. textual; it is dataflow vs. imperative. It is, to many, quite wondrous to encapsulate concurrency in pretty boxes on your screen and feel that you understand and control the process. But this works only for a very small set of states and inputs.
Code maintenance and troubleshooting LV is, for any system that actually does something useful, difficult. While this Visuino stuff may allow you to see the resultant C++ code and enable debugging, it defeats its reason for existence – non-programing programmers.
Textual programming is not ‘hard’. Writing code, other than lunch, is my most easy task during work hours. The hard stuff is design and test.
+1
To paraphrase Anton Ego in Ratattouille, citing chef Gusteau: “Not everyone can be a great programmer, but everyone is a programmer in some point in his life. You probably don’t even realise it, but you finished your first, extremely complex, program before you learned to say you first word, and completed the most difficult programming project of your life before you went to school. Yes, I mean you learned and programmed your own body to do what you want it to do, and take you where you want to get. And there is probably no problem more complex and more difficult to program, than learning to understand spoken word, understand what you see, interpret it, and decide upon all this information your senses provide you with. In comparison, getting a probe to Mars looks like a piece of candy”.
Visual is not versus Text based data flow or other programming languages. To use another standard line, like some of you have used Standard lines before me in this comment section “the only constant is change” and visual will be one day the next programming paradigm, replacing text based any day why ? simply most programmers program in C or Java why not Assembler or even one step before that machine code? The abstraction is highest with C and Java a bit less in Assembler and even less in machine code, there the abstraction is assumed to be zero as built in the language, for this comment.
So what will be the next abstract level …… well visual, really visual is at a higher level of abstraction, welcome to the next level !
Historically, monarchy gave away to dictatorship, dictatorship gave away to democracy, in some cases democracies go back to dictatorships, so you can see we are moving at physical and metal levels as people and as society if you like it or not, so visual programing will come to general application server development as sure as the change between live and death. The programmers are elite, that was stated in one of the comments, the elite has to lead as the elite stays flexible looking for new ways.
If you say you are the elite you might already have past your zenith of your elitism and you like all of us are back to -ism’s.
From my -ism point of of view visual programming works 2 to 5 and in turbo mode about 20 times faster and can be done like documenting by a very large group of people …
Like it was stated in Visual programming by Nan C. Shu in the book by the title ‘Visual Programming” on page 149, visual programming folds documenting together with programming into one step, yes it does work and it works completely different not just better.
You might like this story about some of my programming errors, how they arose, and how programming “people” and programming computers are similar and different. https://petersironwood.wordpress.com/2018/07/26/buggy-whips-to-fingertips/