Funnily enough, I’ve been quoted in this. ;) To expand on modularity, it is indeed curious to me why many will often throw it out that visual programming someh

Funnily enough, I’ve been quoted in this. ;) To expand on modularity, it is indeed curious to me why many will often throw it out that visual programming somehow doesn’t scale for complex and large programs and fails at modularity. Let’s look at LabVIEW as compared to F# and Elixir, two text-based languages that are wonderful to work in and generally well loved, where LabVIEW is well loathed. In LabVIEW, you have projects to organize code, libraries to serve as modules or namespaces, the ability to create functions (including polymorphic and malleable VIs, which are a way to auto propagate types to make functions auto polymorphic), clusters (which are basically structs or records), immutable data, OOP with interfaces (value-based and not reference-based, which is a major plus and not found in many languages), concurrency features, and actors. F# has projects, namespaces, modules, immutable data, records, discriminated union, OOP (reference-based), pattern matching, concurrency features, and some actor frameworks. Elixir is similar with all its features with some small differences. Now, these are all essentially the same fundamental tools available to create programs and to modularize them and scale them. So where’s the rub? How is it that you can somehow create modular and large complex programs with Elixir and F# but not LabVIEW? Where’s the actual discrepancy? Throw in other languages to this discussion and you get hoards of inheritance hierarchies, memory access problems, and mutability, all of which are well known to cause issues with scale and complexity. So I’ve never understood the argument. (I actually do have arguments against LabVIEW for large complex problems but it’s not the arguments usually made and more relate to the IDE than the language). Anecdotally, I once interviewed with a place that was vehemently giving up on LabVIEW. They gave no real reason other than they hated it and said it didn’t work for large programs. So I asked to see one of their Python programs, which was their new language of choice. I was shown a single file that was something like 10,000-15,000 lines long with functions often having signatures taking 10-20 lines, meaning the functions had something like 10-30 function arguments. So at that point I knew that these people didn’t actually know how to properly architect software and that LabVIEW wasn’t actually their problem. They were their problem. As mentioned below my part that was quoted, it can indeed be argued that LabVIEW’s visual nature is a feature when it comes to showcasing poorly organized code. It makes it bare, right there in front of you and in more dimensions than what you get in text. You don’t necessarily get that with text, so people who write poorly organized code in any language but then use LabVIEW are greeted with a visual experience they’re unhappy with. They, incorrectly, see the problem as lying with the tool and not themselves and their programs. All that being said, there are absolutely problems with LabVIEW and other visual languages, just like there are with text-based languages. I’d just like to see more objective discussions of these things because I believe a text-only view holds things back. I’d love to see programming computers evolve beyond the languages, editors, and IDEs we have now.