6 ms·

> But why do people keep coming back to visual programming? Because real programming languages are free. That's it. That's the main reason. Sure, there are ho

> But why do people keep coming back to visual programming? Because real programming languages are free. That's it. That's the main reason. Sure, there are hobby projects, yes, but almost every visual "programming language" in use in the industry, is a proprietary product, being licensed or sold. It's a way to make money, and a pretty smart one to be honest: Once people invest time, resources, training, and build actual stuff in my proprietary system, they either invest a lot more money to get rid of it, or keep using it. And inertia in businesses being what it is, they usually chose the latter. What better vendor lock-in than a programming language? ----- IMHO, no, we don't need "visual programming". I have worked with several such systems in professional settings. There is one thing they all have in common: They suck. No exceptions. It doesn't matter what level they abstract at. They are all sold on the simplest of use cases, and to be fair: They can manage them very well. And some even look pretty and are a pleasure to work with. At the start, that is. Then the honeymoon is over, and you hit the first snag. The first thing the devs of it didn't anticipate, or anticipated but implemented badly. And you build around that. And then the next thing happens. And then next. And the next. And very soon, you keep running for the escape-hatch constantly, like calling into library code, or making HTTP requests to some server to do things that would have been a breeze in a real programming language. Congratulations, we are right back to "non-visual-programming", only now our real code is tangled up in this mess, having to waste precious clock cycles pandering to the ideosyncracies of a less capable system, for no better reason that to not get rid of said system. And god help you if you have more than one of these things having to talk to each other. Now you can write glue-code between to pseudo-programming systems! FUN! And, of course, these things are usually not accessible to any established tooling: There either is no version control at all or some vendors pet project idea of what a cool (read: bad) git alternative should look like. There usually is no way to unit- or integration-test anything. The only "IDE" that can deal with them, is the one the vendor provides. Also, `grep`, what's that? Never heard of it. "But why do people keep coming back to visual programming?" Allow me to ask an alternative question: Why do people stick with textual programming, despite decades spent on trying to make visual programming happen?

mapcars 2y ago
> The first thing the devs of it didn't anticipate, or anticipated but implemented badly. And you build around that. And then the next thing happens. And then next. And the next. Its interesting to get a perspective from someone who actually has experience with these things. Do you think there is a middle ground where the flexibility can be kept, like allowing manual code edits or use visual part for larger structural things like functions/classes? > Why do people stick with textual programming, despite decades spent on trying to make visual programming happen? One of the reasons is it just happened to come first with technology progress and the tools you mentioned like search, testing, version control all were developed around to support text. To achieve parity just in that will take a lot, but text has its own problems too, its hard to understand large code bases, follow all relations, design patterns etc. There is a reason we draw diagrams during development process and they are pretty hard to map into actual code.
- usrbinbash 2y ago
  > like allowing manual code edits That's just another escape hatch tbh. Don't get me wrong, if the system actually allows me to define what some of them call "code blocks", "logic blocks", or whatever, where I can run actual, arbitrary, code, I am the first whos gonna thank the developer, regardless what it runs, python,lua,js,ruby, whathaveyou. (Not that it is all sunshine and rainbows with these, they usually have other limitations, like not being able to deal with actual packages, have weird ideas how external libraries can be installed, or not allow them at all...) But while this is a really good escape-hatch, it still is just that: An escape hatch making up for a fundamental limitation of the idea behind the whole thing, and that is inflexibility. If I have to write parts of the logic in arbitrary code anyway, then usually it's more work to do that and integrate it with the rest of the flow, than just simply writing the whole thing as a python or go service. So as for an answer to your question: No. I don't think so. If someone makes it happen somehow, I'll be very interested in how they do it, because I don't see how, other than making the exact visual-proglangs the article talks about where where we put a GUI on an actual proglang, and at that point the question is "what's the point". > One of the reasons is it just happened to come first with technology progress Sure, but a long time has passed since visual programming was first tried as a concept, and IMHO, if it were possible to build that tooling, it would have been done by now. The problem, I think, is that textual code, for all the differences between languages, still shares common properties between all languages, that make it much much easier to develop tooling for it. For example: `git` works for every kind of plaintext. No exceptions. LSP needs to be implemented for different languages, sure, but it is a common concept, relying on commonalitis between languages; e.g. all programming languages have some kind of identifiers, subroutines, types, etc. The same is true for a lot of other tools as well, e.g. patchfiles and diffing. Visual Proglangs do not share these commonalities, not just with textual code, but with each other. Every one of them brings entirely new and different ways of doing things, and while that is beautiful on the one hand, it makes it really (and I actually think impossibly) hard to develop common tools to deal with them.

mapcars 2y ago

> The first thing the devs of it didn't anticipate, or anticipated but implemented badly. And you build around that. And then the next thing happens. And then next. And the next. Its interesting to get a perspective from someone who actually has experience with these things. Do you think there is a middle ground where the flexibility can be kept, like allowing manual code edits or use visual part for larger structural things like functions/classes? > Why do people stick with textual programming, despite decades spent on trying to make visual programming happen? One of the reasons is it just happened to come first with technology progress and the tools you mentioned like search, testing, version control all were developed around to support text. To achieve parity just in that will take a lot, but text has its own problems too, its hard to understand large code bases, follow all relations, design patterns etc. There is a reason we draw diagrams during development process and they are pretty hard to map into actual code.

usrbinbash 2y ago
> like allowing manual code edits That's just another escape hatch tbh. Don't get me wrong, if the system actually allows me to define what some of them call "code blocks", "logic blocks", or whatever, where I can run actual, arbitrary, code, I am the first whos gonna thank the developer, regardless what it runs, python,lua,js,ruby, whathaveyou. (Not that it is all sunshine and rainbows with these, they usually have other limitations, like not being able to deal with actual packages, have weird ideas how external libraries can be installed, or not allow them at all...) But while this is a really good escape-hatch, it still is just that: An escape hatch making up for a fundamental limitation of the idea behind the whole thing, and that is inflexibility. If I have to write parts of the logic in arbitrary code anyway, then usually it's more work to do that and integrate it with the rest of the flow, than just simply writing the whole thing as a python or go service. So as for an answer to your question: No. I don't think so. If someone makes it happen somehow, I'll be very interested in how they do it, because I don't see how, other than making the exact visual-proglangs the article talks about where where we put a GUI on an actual proglang, and at that point the question is "what's the point". > One of the reasons is it just happened to come first with technology progress Sure, but a long time has passed since visual programming was first tried as a concept, and IMHO, if it were possible to build that tooling, it would have been done by now. The problem, I think, is that textual code, for all the differences between languages, still shares common properties between all languages, that make it much much easier to develop tooling for it. For example: `git` works for every kind of plaintext. No exceptions. LSP needs to be implemented for different languages, sure, but it is a common concept, relying on commonalitis between languages; e.g. all programming languages have some kind of identifiers, subroutines, types, etc. The same is true for a lot of other tools as well, e.g. patchfiles and diffing. Visual Proglangs do not share these commonalities, not just with textual code, but with each other. Every one of them brings entirely new and different ways of doing things, and while that is beautiful on the one hand, it makes it really (and I actually think impossibly) hard to develop common tools to deal with them.