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.
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.