Ever since the Intrinsic launch event a few weeks back, I wanted to write a long article on how the shown approach of visual programming for robotics is likely to fail. This prediction is based on forty years of experience with visual spaghetti in software engineering. I never got around writing a long blog post, so here is a short one.
Intrinsic (an Alphabet / Google company) recently acquired the main organization behind ROS, a popular robotics middleware. Now they doubled down with a commercial strategy by launching (in beta) a development environment for programming robots. The demo showed that they took a visual programming approach with drag and drop of program blocks etc.
Past experience shows that sooner or later such visual programs become unmaintainable; the only successful visual programming approaches reside in niches, and robotics is too big for that; it requires general programming powers.
The presenters acknowledged that if you run into the limitations of this programming approach, you “can drop down to Python code” (quote from memory). Being able to escape to a general programming language is not a solution, it is is a dead giveaway for troubles ahead. The minor problem is the obvious impedance mismatch high-level visual low-code programming and system-level programming. It is ripe for introducing bugs, even with a well designed plug-in system.
The major problem, however, is what it tells us about the implementation of the visual programming system. In all likelihood, the visual programs are instantiations of an underlying framework implemented in some language, and programs are written by creating and combining instances from classes/types in the underlying framework. I have never seen such a framework implementation that wasn’t riddled with subtle bugs, inconsistencies, race conditions, etc.
There is a reason why software engineering invented language engineering. You need a semantics definition independently of an implementation. You want a syntax specification so that you can have multiple competing implementations. This empowers a community of language designers and vendors. And only if you have this community and those competing implementations will you get a robust language to build systems with. Even today, the C language community finds bugs in the language definition and hence inconsistencies in compilers.
Now, Intrinsic is making a play for developers with a fabulous looking visual programming approach. This system is obviously proprietary. Maybe they will succeed, maybe they won’t. I expect them to be limping along. There is a better approach, though: A truly open ecosystem would make the language specification public domain and allow for competing implementations. Google previously gave it a go (pun intended), but it remains one of the hardest undertakings in software engineering.
Leave a Reply