Lutetium-
Graphical Programming Language HackChat Transcript
08/18/2017 at 18:02 • 0 commentsOkay, let's get started!
@Boian Mitov Can you start us off with a short bio about yourself
and what you do and have created? :)
Sure...
I got hooked on electronics, when I was about 14 or so
It was back in Bulgaria where I was born
I have some questions on visual programming in general
My father was mathematician, but he was also hooked on electronics, and used to do some cool projects at home
This got my attention, and I asked him to teach me
As a typical mathematician, he refused, and instead gave me a bunch of books to reed :-D
more questions relating to your outlook and opinion as to what role you think visual programming will play in development: can it be used to augment learning of tradtional programming or will 'replace' traditional programming roles and put engineers into more complicated roles, etc.
@Bossman Please add it to this sheet: https://docs.google.com/spreadsheets/d/1L54ps__sTScIQqamefYh95n4K9Ldz0UBSbx4_miYEq0/edit#gid=0
I guess the idea was, if I survive through them I will never give up...
What are your thoughts?
Well... it took the 3th book or so before I really found something interesting. It was a book called "Electonics- the modern hobby" ( Kind of resonates nowadays too :-D )
And this is how I got hooked
but lets go to the question
For the last 200 years, since the Charles Babbage mechanical computer, and Ada Lovelace, the computing hardware has made some considerable advances....
However we still program computers the same way as she did 200 years ago...
The modern computer architectures are quite different than the early days and traditional programming approaches do not map well in programming GPUs with thousands of micropores, and even less so when programming FPGA for computing unless we burn a virtual CPU in the FPGA, effectively negating its advantages
The problem is that traditional computer languages with few exceptions are designed for sequential execution. This is fine for a single CPU core, but completely inadequate for a parallel system, GPU, FPGA or a computing cluster
To be able to utilize this type of modern computing platform, we need to change the way we describe the problem and teh solution
instead of describing it as a sequence of operations, we should describe it as a flow of data, and processing performed on that data, and let the computer distribute the task of the execution, the way a compiler converts high level code to assembly
Added bonus to this approach is that it is quite easy to visualize
In addition it is much more intuitive. Lets think of a large organization versus a single person
A single person will write a list of things he/she needs to do to achieve something
when you have a large organization however this approach does not work any more
instead the organization creates a product/document etc. flow, and describes what each unit in the organization will perform over the product.
Fantastic explanation. As someone that uses visual programming on other projects (web apps, mobile, etc.), the question many of us have is "what are we learning?" / "what skills are we really developing here that can be put to use at an organization outside of this project"
So now we have the 2 approaches. The sequence programming and the dataflow programming
@Bossman Thank you! :-)
@Bossman The short answer is that we learn "the future of programming" ;-)
We have another question
Make no mistake. The switch to dataflow and graphical programming is no less of a conceptual and productivity switch as the one from Assembler to C or from C to C++ and object oriented programming
from Nate Byrnes: I've been thinking about and using graphical means of SW development for a while now. One problem I keep butting my head against is how to balance text content from graphical. My goal is to reduce the needed text input to as close to zero as possible. What has your experience been with this issue?
Personally I am on a mission to eliminate text coding :-D
What about functional programming as to how it relates to visual programming languages?
To add to both questions... I remember 22+ years ago, I had argument with people that we should develop in C++ not Assembler
Nowadays very few people will try to convince you that you should use Assembler as your main programming language
I am sure in 20 years, few people will be using the argument that we should use sequential programming, or text based programming ;-)
The sad story is that couple of years ago I watched an old presentation by one of the original PARC researchers
He was making the case for graphical programming, and his arguments were solid
It is sad that here we are so many years later, and we are just starting to use it... It goes without saying... everything in modern computing starts with PARC...
If you watch computer history, you will notice that PARC discovered virtually everything, and then the ones that came after it simply took the concepts and created products on them...
Nice to see you Boian. Almost 10 years ago I purchased your VideoLab software for Delphi and we exchanged some emails back in the day. I am glad to see your newer project here.
Apple took the GUI
Thank you @AB :-)
3Com took the networking
I am also appalled by the fact we still use text editors to code.
C++ etc. took the object oriented programming
And Microsoft and Apple took document linking and embedding
Apple took the mouse...
Now it is time to bring to life their graphical programming concepts... they are long overdue... ;-)
Yes... it is strange that we still use text editors to program... especially impractical in the age of touchscreen mobile devices :-D
Sorry if I am asking a newb question, but, how is the discussion supposed to happen with the questions on the google sheet? Will there be a dialogue in this forum? Are questions intended to be discussed by all participants? Sorry, as I said, newb to hackaday....
You can type questions in the sheet
It makes much sense to do graphical programming for embedded platforms. The graphical display is visually very close to the hardware, eliminating abstraction levels in our brains.
Hi Nate, I have been posting the questions on here for Boian
He just answered your question if you scroll up a little
and there will be a transcript, at the end. :)
@Boian Mitov , next @Bossman has another question: As someone that uses visual programming on other projects (web apps, mobile, etc.), the question many of us have is "what are we learning?" / "what skills are we really developing here that can be put to use at an organization outside of this project"
There is another aspect to it... In general anything that can be presented in HW can be presented in SW. Translating HW concept to SW is easy, the opposite is not. There is no straight way of taking sequential algorithm, and converting it to HW execution
@Shulie Tornel I think I covered this question :-)
Jose asks: There are several learning platforms that use visual programming today, as today's projects are mostly created in a text based programming language, do you think it is a good approach for a person to start with a visual programming tool or should we start directly with a text based one? What are the skills these starting tools should encourage?
Is this webinar just text based without audio or video?
@SimonAllen chat based, yes!
personally I believe that text based and sequential programming are obsolete, and in the future will serve the same role as Assembler programming serves today
There will always be some occasional need to write in Assembler, so there will probably always be need for those languages in some case
but they represent severely limited method of programming (limited in terms of productivity and easy of describing problems not what you can do with them), the same way as Assembler is very limited in describing higher level concepts
To me the traditional programming languages are simply lower level languages, and limited to sequential single CPU execution
But back on the HW vs SW topic
As I said it is easy to take HW concept and do in SW, not easy the other way around
Data Flow diagram however translates directly into both
It also translates directly in parallel and distributed computing
So if you write code in C++ as example, it will compile just fine for CPU, but you can't use it on GPU, and on FPGA you can use it only if you burn a virtual CPU losing the advantages of the FPGA altogether
Am i right if i say LabView or matlab simulink is very much like graphical programming?
and it usually will not work on multicomputer cluster
yes, LabView, and simulink are exactly this type of solutions
Visuino is designed the same way
There is another aspect of this. Sequential programming in microcontrollers presents its own set of issues
There you have actual hardware that you need to control. If you control as example one stepper motor with Arduino
that's fine... make a step... delay... make a step... delay
but what if you have 2-3 stepper motors that you need to control simultaneously... ?
you can't just delay on one motor, because at the same time you have to control the other etc....
This is where data flow programming and Visuino make really shine
in Visuino you just need to add 2 stepper motor components and you are done
Okay, here's another question by Bossman: I recall other visual IDEs like Labview about a decade ago in Uni, why didn't that take off? How you feel the landscape of programming has changed since then? Why is there such an emegence of dataflow/graphical langauges these days?
Our group (nonprofit teaching to underprivileged areas in Houston) taught Scratch for free in a library in South Houston. We used the version that has hooks into Arduino. The kids LOVED it and really took off.
And there is no queseiton they "got it". I don't think they would have been nearly as excited if we only had done text-based stuff.
In my opinion there are many reasons shy LabView did not take over
1. LabView was developed specifically for NI equipment, and as a very proprietary quite closed framework
Is there any other pro that graphical programming provides other than making it more intutive & graphical (hence easy to understand)
2. LabView actually is only very partially dataflow. It uses a lot of sequential concepts like loops etc. completely negating the advantages of dataflow
By the way, WRT dataflow languages & concepts go look at BI (Business Intelligence) tools. For example Pentaho (see http://community.pentaho.com/projects/data-integration/ ).
In some sense LabView is its own enemy in terms of success... when it introduced the deep concepts of sequential execution it cut its own branch
And on Labview: I used it when I was at a Robotics Institute at UT Arlington in Texas. Besides the dataflow back end it allowed you to build instrumentation UIs in minutes.
probably it's just a feeling...because humans resist the change...but graphical programming gives the feeling that "there is some detail that I am missing". Though I can be completely wrong.
3. The LabView NI people had patent on any Graphical Programming.... and they worked to shut competition through it until it expired few years ago...
NI is one of the main reasons graphical programming did not take off earlier.
As example the graphical core used in Visuino was developed by me about 15 years ago. I did not make it public out of fear that NI will be going after me the way they went after Mathlab
Didn't know about the patent thing...
I released the first version of my graphical environment about a year after their patent expired ;-)
http://www.openwirestudio.com (Mitov Software - OpenWire Studio)
OpenWire Studio is still mainly a technology demonstrator. You can develop Video, Audio processing, DSP, Computer Vision, AI and a bunch of other stuff in it
but it mainly serves to test and experiment with my Data Flow ideas
Visuino is a spinoff from the OpenWire Studio with much more specific purpose - to make it easy to Arduino users - Artists, Makers, Kids to program their Arduino boards and other microcontrollers...
Another question from Bossman: Are there peformance tradeoffs to using programming at scale? Is this intended for rapid prototyping or can it be safely used in production development? (speed, concureny, etc.)
In the future I may do more spinoffs from OpenWire Studio in other areas.
Graphical programming when properly implemented leads to significantly higher performance with very few exceptions
The reason is that the system can optimize parallel execution whenever needed
The later versions of Visuino also automatically remove unused and unneeded code from the underlying libraries when some features are not needed
and I am am further enhancing this
Finally, by focusing on the big picture, you can optimize the high level design better, leading to improved performance
So what you're doing is similar to (or identical) to compiler optimizations?
"local optimizations" have less effect on performance than "global optimizations"
ah. OK.
Compiler can optimize only what the compiler knows about your intentions... ;-)
"Why isn't there a decent 3D visual programming language that is based on lamda functional programming concepts "
When you present it with C++ code it assumes that whatever you wrote, it must be executed as you wrote it
Not necessarily. Loop optimization in compilers goes back decades ...
When presenting dataflow, you tell the computer what you want to be done, and leave it full freedom to decide on the best approach ;-)
Agreed on letting the computer decide (for the most part).
It is the same as if you tell someone:
1. you go straight 10 steps
2. turn left
3. go straight 3 steps
4. turn right....
vs.
Yo go from point A to point B
"What do you consider the most advanced tools for visual programming today? I mean, current environment are completely based on text programming (diff tools, source control, text editors...), any comparable visual versions of these?"
the first is how you program sequentially, the second is dataflow programming
in the second case the "compiler" can optimize much better ;-)
gottit. But the same argument could be made for OOP and "functional programming" as well (not specific only to dataflow languages). As a LISPer I am all about polymorphism :-)
We have three more questions on the sheet, and then last call for questions! :)
Charlie: "Do you have an opinion about SNAP? I am deploying it in small classrooms; it is very useful to have a totally browser-based visual programming language/environment available (SNAP is Berkeley interpretation of SCRATCH, see http://snap.berkeley.edu/)."
On the best tools question... I am biassed. For Arduino, ESP6266, ESP32, Teensy, chipKIT etc. I believe that Visuino is the best choice....
Thanks for your work on OpenWire. I only discovered it last week, am glad you did this talk. I will be experimenting with it next week. Gotta scoot now though.
thanks for running the chat.
for everything else there are solutions, and I hope there will be more...
and I hope some of those "more" solutions will be from me... ;-)
Scratch is no different than traditional text based programming. It is sequential, and has exactly the same problems and limitations. Difficult to implement anything more complex than controlling single sensor/actuator, and time consuming
I don't see any advantages of Scratch over writing direct C/C++ sketch... it is practically the same
I see some unanswered questions in the spreadsheet ?
Do you post them @Shulie Tornel ?
well here is mine (1/2 of the questions): let's say that Visuino becomes succesful and eventually aquired by a large comany. If that large company decides to shutdown Visuino (as is often the case...Parse, etc.). What happens to everyone that invested time to learn Visuino? How will we translate our skills to another language/platform or update our hardware?
@Bossman A larger company attempted to take over the IP few years ago. I refused to sell... I plan to refuse the next offer too... ;-)
thanks for the answer, but just as a word of prgamaticism
what happens if it gets shutdown?
I do not develop this in order to get rich. This is the reason I priced it as low as I could, I I tried to go even lower, but processing fees... :-(
will the source code be opensourced, our are we sH@ out of luck
(just as a word of pragmaticism)
1. If it gets shut down... I will plan to make it open source
Question from @morganrallen
"What are recommendations for someone who wants to implement a visual programming language in their software? In the past, Blockly appeared to be the only option, but it was very difficult to embed in my own software."
Awesome
2. The Arduino libraries that it uses for the code generation are already Open Source
in general I try to open source as much stuff as I can without going bust :-D
I also make the SDK available for free
you have to take of yourself, I don't think anyone would complain if you had monetization strategies in place, as long as its transparent
and the SDK sources are available by simply signing NDA at present :-)
excellent, thank you for answering that question
The fight is mainly to change the programming mindset. Even if Visuino one day dies... hopefully it would have paved the way for the future of programming
@Bossman You are Welcome! :-)
I agree, it is almost like the wild west.....quite a number of visual IDE available
if they shutdown
there is no central platform to fallback on
I suppose the dataflow logic is universal
@Bossman We are still exploring completely new concepts
Visuino as example introduces a large number of completely new concepts not available in other environments. A lot of R&D and experimenting goes into it
I am sure some of those will be copied over time... ;-)
super interesting, do you feel that the 'logic' one learns in visuino is translatable into other IDEs as well?
100%
its kind of an ambigious skillset at the moment
not only that. It teaches you high level design concepts ;-)
Any last questions for @Boian Mitov ?
any suggestions on parrallel learning that we might do while using Visuino, to better ourselves as 'developers' of the future?
Look into GPU, FPGA programming and Cluster/Distributed network programming....
and keep thinking... ;-)
Look into VHDL Verilog... ;-)
This is a fast evolving field, and it is just the beginning.... ;-)
I am already exploring the possibilities to program both Arduinos and FPGAs with Visuino and to move designs between the 2 ;-)
That's all the time we have for this HackChat! Thank you so much, @Boian Mitov!
You are more than welcome to stay and continue answering any questions anyone may have
or just to hang out :)
Thank you, @Boian Mitov
Thank you @Shulie Tornel !
Graphical Programming Language Hack Chat
Love blocks and graphics? Hate coding in words? New to coding? We'll be discussing graphical programming in this chat!