tag:blogger.com,1999:blog-15136575.post4466414098793371188..comments2023-10-17T12:00:16.772+01:00Comments on Code rant: Visual Programming - Why it’s a Bad IdeaMike Hadlowhttp://www.blogger.com/profile/16441901713967254504noreply@blogger.comBlogger37125tag:blogger.com,1999:blog-15136575.post-70331659232886071602020-06-16T05:22:25.204+01:002020-06-16T05:22:25.204+01:00My understanding is that the Large Hadron Collider...My understanding is that the Large Hadron Collider project was programmed using LabVIEW RT (-- perhaps not exclusively, but some key aspects). Furthermore, SpaceX employs a number of LabVIEW specialists.<br /><br />I myself have been developing large, complex automation systems using LabVIEW for many years. (One of my projects actually won a US national award for innovation. No one asked me what programming language I used. They were only concerned whether the technology worked.)<br /><br />I can imagine that there are better tools for business applications and web development, however with shrinking budgets, increased pressure for time-to-market, and a need to rapidly prototype, deploy, and modify, graphical LabVIEW is a great tool for many engineering applications.<br /><br />The points about source code control and difference-tracking are well-taken though. There have been several attempt at this over the years, and the results haven't been great. However, watching the execution flow in debug mode is a fabulous debugging tool that usually shortens debugging from hours to minutes. I know there are powerful debugging tools on the text side, but if you have a logical error (rather than a syntax issue), it's great to watch the values flip and evolve before your eyes. <br /><br />Am I technically a programmer? Perhaps not. (I have worked with assemblers, fortran, pascal and C compilers, compiled BASIC, and other "textual" tools in the past.) But for getting results, an advanced graphical programming environment is like any other tool -- the power comes from knowing how to use it effectively. <br /><br />There is good and bad in every approach. If you prefer text, then go with text. Many people process their world visually, and graphical programming languages provide advantages and disadvantages that are different from the advantages and disadvantages of text-based approaches.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-38330134992862474542019-04-01T17:38:07.813+01:002019-04-01T17:38:07.813+01:00Inevitably visual programming will be used even fo...Inevitably visual programming will be used even for server software, one day.<br /><br />Why, because when you try it, it has not only advantages! All the once who will not discover this will belong to the older generation of programmers.<br /><br />Why do I say this well I have discovered in more than one way … ;)Anonymoushttps://www.blogger.com/profile/02791817770488876180noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-44832258923147904192018-11-28T14:59:31.980+00:002018-11-28T14:59:31.980+00:00What a bad hot take. History is going to make fool...What a bad hot take. History is going to make fools of everyone who thinks like this. If I am selecting and manipulating code text directly with touchscreen, is that a Visual Programming Language? Okay, so what if there is a graphical element to represent the text, but just while I'm dragging it somewhere else? At what point is it a Visual Programming Language and not a better text editor?<br /><br />There are so many counterexamples disproving this author's proclamations that I don't want to waste my time arguing against this ridiculous rant.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-56607128504354283802018-11-21T09:15:27.122+00:002018-11-21T09:15:27.122+00:00To add to Andy's comment above, if we consider...To add to Andy's comment above, if we consider the visual language a DSL on top of a suitability flexible low-level language (ie. New visual extensions can be easily developed), the impedance mismatch between the DSL and the low-level language is an important consideration.<br />The better visual DSLs will have a low impedance, possibly to the point where the DSL can self-host, and few language features will need to be hidden away in dialog boxes.<br /><br />NodeRed is a good example. It's built on nodeJs and extensions can be easily developed (hence the plethora of nodes from opencv to twitter nodes, SQL database access, rpi i/o etc).<br /><br />It supports UI development through the dashboard plugin (though is missing a table plugin here) and runs cross-platform (see https://www.github.com/alexisread/noreml) so even mobile apps can be developed.<br /><br />To address the impedance match- visual primitives corresponding to language primitives help immensely eg. For Composita, basic malloc is handled via RAII (scoped object creation/destruction) and object communication via a fixed size queue. Both these can be modelled visually.Anonymoushttps://www.blogger.com/profile/01186897621192462181noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-11214786816861328832018-11-20T20:50:56.146+00:002018-11-20T20:50:56.146+00:00Pictures are great but from a pragmatic use in a r...Pictures are great but from a pragmatic use in a real. world scenario I've seen these types of tools fail. SAP B1 integration framework and SnapLogic use the same graphical representation of code blocks that can be linked together to create ETL integrations between systems. While the initial use and implementation looks good, over time you start to see the lack of good code development practices and catastrophic failures because it was so easy to slap a few blocks together that now your business partners are cobbling together integrations faster than IT can manage the overall platform. They are great for niche cases to quickly lay out a structure, excellent for an additional way to explain complex code dependencies but overall a poor choice for heavy use in an enterprise environment.Anonymoushttps://www.blogger.com/profile/09241966673321831800noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-8959799449733739752018-11-20T20:10:46.689+00:002018-11-20T20:10:46.689+00:00You lost me at "untypical"You lost me at "untypical"Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-46526265963999902372018-11-20T18:49:59.699+00:002018-11-20T18:49:59.699+00:00I suggest to learn Houdini. It may change your pov...I suggest to learn Houdini. It may change your pov on what [also] constitutes 'visual programming' and also what to think about it, specifically in the context in which it is used in Houdini but also generally.virtualritzhttps://www.blogger.com/profile/00558452573597221013noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-77851200635319402352018-11-20T18:44:23.587+00:002018-11-20T18:44:23.587+00:00Visual programming is not valuable because textual...Visual programming is not valuable because textual programming obfuscates a fundamentally simple process, it is valuable because textual programming does not elucidate a fundamentally complex process. Visual programming languages are valuable in domains where rigor and correctness are more important than simplicity. Even partial implementation in a visual domain with internal code aids in testability and interpretable encapsulation. As you say, good code may already decouple and abstract away in the proper ways, but generally not in easily interpretable ways. I think these goals are actually directly addressed by many visual programming tools, which clearly show dependencies between modules, and generally have nesting capabilities. It seems your gripes are more with the particular tools you have used than the state of the art and a priori possibilities of the technique.<br /><br />It is very difficult to show that code implements a specific, pre-specified formal structure without a diagram in the same (visual) language as that structure. If you create analysis tools to compute this diagram structure from textual code, it is not too difficult to begin progressively improving that tool into a tool for programming itself. At this point you have cut out the middleman and you are working in the interpretable domain directly. Even if you still write code in some places, the overall system is specified in a way that you can more easily evaluate for correctness.<br /><br />It is interesting that you fault visual programming languages for not being amenable to git diffs. Have you considered that git is in fact the tool that is failing in this process? It was designed for textual code. It is not surprising that extensions or different source control is necessary for non-textual code.<br /><br />Visual programming is not a be-all, end-all solution, but it has valuable applications, and the issues with it can be addressed. I have built visual programming tools and used them - while I believe they, like all systems, have many issues, none of those you raise in this article seem to be serious or meaningful. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-141607935496057222018-11-20T17:52:17.427+00:002018-11-20T17:52:17.427+00:00Last decade I spent a fair bit of time working wit...Last decade I spent a fair bit of time working with .NET Workflow Foundation - a visual programming abstraction. Many projects devolved into "abstract art" - this paradigm failed, and Microsoft has phased this API out after several iterative retries.Anonymoushttps://www.blogger.com/profile/02914970554397831060noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-68859030841518069342018-10-03T05:10:55.902+01:002018-10-03T05:10:55.902+01:00Its easier, because no need to worry about syntax ...Its easier, because no need to worry about syntax Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-688102261936494072018-10-03T04:41:00.036+01:002018-10-03T04:41:00.036+01:00After spending two years in labview I concur.
In ...After spending two years in labview I concur.<br /><br />In the end G-IDE systems are just as capable as traditional languages, the difference is a G-IDE allows people with minimal programming skills to create complex systems that are impossible to maintain.<br /><br />Today in Traditional languages, it honestly takes someone of high intelligence to create systems that are impossible to maintain. Typically working alone, without a program manager.<br /><br />No matter how much tinkering you do in the G-IDE it's not as functional as traditional code. I wrote a visa wrapper on one page of python code that does the same thing as five different VI that take up multiple windows.<br /><br />Which is easier to adapt to new systems? Which is easier to maintain?<br /><br />The python Visa wrapper. Elwood Buelhttps://www.blogger.com/profile/04439171142793810982noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-26753036346155572632018-10-03T04:06:52.125+01:002018-10-03T04:06:52.125+01:00I agree. It's a good intro to get something u...I agree. It's a good intro to get something up and running quickly and understanding basics.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-84500996169573315002018-10-03T03:34:11.645+01:002018-10-03T03:34:11.645+01:00Have you ever seen a textual language with multili...Have you ever seen a textual language with multilingual locale support?Samurai_Crowhttps://www.blogger.com/profile/05353238240678438707noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-6334419788443360912018-10-03T03:26:48.286+01:002018-10-03T03:26:48.286+01:00Here's my response. In general I greatly disag...Here's my response. In general I greatly disagree from an educational standpoint. https://blog.claycodes.org/2018/10/VisualProgrammingAResponse.htmlClay Smithhttps://www.blogger.com/profile/04829587514615567157noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-1883463779872563142018-10-03T01:10:59.370+01:002018-10-03T01:10:59.370+01:00I agree with you. Sometimes we need visual program...I agree with you. Sometimes we need visual programming but don't forget about the basic concept of the programming language. Achmad Solichinhttps://www.blogger.com/profile/10604198790299258948noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-22745435991612600322018-10-03T01:04:18.966+01:002018-10-03T01:04:18.966+01:00I agree with source control, the increased complex...I agree with source control, the increased complexity of one line of code mapping to multiple blocks and the complexity of abstraction. But why do you think it's necessary to define high-level blocks through textual code?<br /><br />A high-level block can represent a underlying visual function even defined in another file much like external higher-level functions in textual code. Like a Math.pow(2,4) isn't a single line of code, but in fact multiple lines just abstracted, you can have a Math.pow() block and it's underlying logic visually defined somewhere elseAnonymoushttps://www.blogger.com/profile/00395132803552958546noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-85673133084350051192018-10-03T01:00:42.118+01:002018-10-03T01:00:42.118+01:00I used to do seismic data processing before I beca...I used to do seismic data processing before I became a software Developer, and a most of the programs we used were very similar to the visual languages described by the author. We built processing flows (or program diagrams) out of blocks connected together with arrows, with most of the parameters of each block burried in the settings. All of this is to say it was a way of allowing non programmers to do programming like work, without training as coders on top of training as geophysicists. This is, to me, the correct application of visual languages. I dont think we ever should be using them as a primary tool to build software, but they are damn useful in allowing others to do very complicated tasks within software, especially when we are talking about data analysis.UrsulaMinorhttps://www.blogger.com/profile/13022298348016578457noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-36053956229873287312018-10-03T00:18:37.422+01:002018-10-03T00:18:37.422+01:00I agree that dialog boxes as an input mechanism ar...I agree that dialog boxes as an input mechanism are terrible. Anything that splits the code up at too fine a level of granularity and that gets in the way of fluid navigation is going to be terrible for usability and productivity, but I don't see this as a necessary result of trying to explore different representations of program logic.<br /><br />My personal preference would be to use YAML as a textual modelling language, combined with Python or C for functional components; with navigation and understanding aided by generating various visual representations of the system: Most usefully at the level of systems and components, but without limiting finer granularity representations (dependency graphs, control flow graphs, data flow graphs, parse trees, etc.. etc..) either.Willhttps://www.blogger.com/profile/16325301752282552046noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-51994493303859928182018-10-02T22:34:19.319+01:002018-10-02T22:34:19.319+01:00"Visual programming isn't for programmers..."Visual programming isn't for programmers."<br />He specifically discusses tools that were supposed to make professional programming visual using UML, so yes, visual programming was indeed at one point "for programmers." <br /><br />"So, it's not a bad idea in the situations where it works, then."<br />That's a statement that can be applied to literally anything. Zeppelins work when the gas bubble is totally secure and there are no ruptures or flames that go near it. Yet, for some reason, we don't use them any more. Just because an idea isn't applicable in every single situation does not mean it is "good."<br />"I'm not going to teach my robotics class to code in C--I want them to actually get something working."<br />Why not write a robotics library for C (or whichever language you choose) and allow your students to make robotics code that scales, while circumventing the issue of your students writing robotics firmware? Honestly if you told me a robot was designed using visual programming, I wouldn't buy it, let alone allow it to handle my things.CrazyEyesnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-55705119667292744062018-10-02T21:29:57.377+01:002018-10-02T21:29:57.377+01:00Simulink and Labview are both excellent visual &qu...Simulink and Labview are both excellent visual "languages" for certain tasks and people.Anonymoushttps://www.blogger.com/profile/00017547418259830771noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-31794292863045634202018-10-02T21:28:49.222+01:002018-10-02T21:28:49.222+01:00Using Scratch as a blanket for all visual programm...Using Scratch as a blanket for all visual programming seems a little disingenuous. I also doubt the creators of Scratch believe your misconceptions. It was created for a specific purpose and the underlying code is not simplistic.<br /><br />Take a gander at something like RFML from Red Foundry or the entire Mendux ecosystem for better examples of visual programming.<br /><br />One big reason why it is a good idea where possible is that it is clear. And in a world being swallowed by poorly written bug ridden software I think this reason is quite worthwhile.Greg Jhttps://www.blogger.com/profile/07137862433351984411noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-51289133451871068292018-10-02T20:19:18.078+01:002018-10-02T20:19:18.078+01:00This has to be a joke article, right...? This has to be a joke article, right...? Anonymoushttps://www.blogger.com/profile/14130086763890125594noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-88568439439479034462018-10-02T19:41:57.090+01:002018-10-02T19:41:57.090+01:00Visual Studio offers tools such as ADO.Net or Enti...Visual Studio offers tools such as ADO.Net or Entity framework designers which are excellent to quickly get the data structures and code to interact with a RDBMS. Another example is SSIS on MS SQL server. Workflow designers are also useful. I mean to say that hybrid is good.Tarik's Bloghttps://www.blogger.com/profile/04958712152389923707noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-70929649577455141292018-10-02T19:11:04.714+01:002018-10-02T19:11:04.714+01:00Yeah I don’t like codesYeah I don’t like codesehttps://www.blogger.com/profile/17831312256881997907noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-32881101656529487802018-10-02T14:52:58.235+01:002018-10-02T14:52:58.235+01:00While I agree that all these problems plague most ...While I agree that all these problems plague most visual programming languages, I disagree that these are inherent problems with visual languages. Perhaps they are inherent problems in visual languages that are representing imperative paradigms.<br /><br />Consider a functional dataflow language with haskell-like types - text dataflow languages are really just constructing a DAG - not mutating state in an imperative style.Now consider that you can either define that DAG via textual (parse->AST->DAG) or visual (directly manipulate DAG). If you could easily switch between these representations, have a solid type system, 1st class functions and use modules instead of a single text file it wouldn't have any issues. The problem with visual languages is that they are usually not very good languages and that "structural"/low-level things are easier to deal with as text, but (for dataflow languages at least) high-level structures are more suited to visual representations.<br /><br />Unreal's Blueprints are a pretty good example of how imperative programming language can work visually, your point about not being able to fully understand a program without looking at the corresponding c++ is totally right but in practice the intended audience isn't actual programmers so it's actually been really valuable - even at AAA studios.<br /><br />Perhaps a better example is LabView or Reaktor - both of which feature highly complicated, encapsulated code completely written in the visual language. The problem is that writing low level code in these languages is super complicated (for the reasons you listed in the article), but the payoff of being able to do the high level "business logic" visually is really big. If a language could be represented expressively in both text and visual formats, and diffed using the textual representation, I think it would be very powerful (of course for specific domains).Andyhttps://www.blogger.com/profile/01598926091668974284noreply@blogger.com