5 ms·

I spent the first years of my career writing "no code" signal processing platform. It had it's ups and downs. We indeed had a lot of non-coder users and it made

by yoz-y 6y ago

I spent the first years of my career writing "no code" signal processing platform. It had it's ups and downs. We indeed had a lot of non-coder users and it made prototyping simple to moderately complex pipelines quickly. However relatively soon for anything actually useful we had to write more components, some of which were not really reusable because it's non trivial to hide the complexity. At some point most workflows ended up in a "python script executor", because in the end code is always more expressive. Also, no version control. Or, in our case since we used XML for output: poor version control. Reading horror stories about Excel also confirm this, it is hard to do correct complex programs in visual environments.

Wowfunhappy 6y ago
> Also, no version control. On Mac, Apple apps and other "Mac-native" programs save revisions automatically in the background. At any point, the user can select "Show Revision History" and scroll through a timeline of changes. I'm not sure if this works with Excel, but it does with iWork/Numbers, and I use it all the time. Now, Apple's implementation is just a simple timeline—there's no equivalent of version tagging, or git blame. But all of that could be done within a graphical environment similar to Apple's. It wouldn't be as advanced as Git, but I bet it could do what 95% of people actually use Git for.
- quietbritishjim 6y ago
  You can also commit Excel files to a git repo. That lets you get back to old revisions and look at the commit messages. But you're not going to get a diff or git blame, which is what the parent comment really meant.
  - Wowfunhappy 6y ago
    > But you're not going to get a diff or git blame, which is what the parent comment really meant. You could though. Microsoft (or anyone else creating a "no code" platform) could absolutely build that into a graphical timeline view. Select these two snapshots, and show which cells changed.
    - ayende 6y ago
      This exists, at least for Word and likely for Excel as well It is also horrible,hard to understand and not useful for most tasks you will use source control for
      - Wowfunhappy 6y ago
        But is that inherent in any GUI-driven solution, or is it because Microsoft has never prioritized it as a first-class feature? I'd argue it's the latter. It's certainly not trivial (as Git wasn't trivial), but conceptually, version control strikes me as one of the easier things to translate to a GUI-driven environment. And it's something that should be translated, because version control is a major problem even in domains which have nothing to do with code, e.g. graphic design.
        theamk 6y ago
        It is not clear to me at all how to make a good version control at GUI apps. Let’s start with diff - If this is a text doc, diff seems easy. Show old and new text next to each other, somehow highlight new and old version. Immediate problem: what if you choose to highlight “new” with purple + underline, but user is already using purple + underline as a part of their text. Do you choose a different color? Or just hope it is “clear from context”? Now for spreadsheets: the formula has changed, how do you show this? You can expand the cell to show formulas, but those can he huge, so your document can become unreadable. Or maybe just highlight the cell and let user click on it to see the formula difference - but then you can no longer see the changes at a glance. What about things with no text representation, like conditional cell format? Are you going to come up with text representation just for display purposes, or are you going to design special text formatting dialog which shows “new” and “old” values? There are hundreds of questions about GUI diffs which simply do not exist in texts.
        neolog 6y ago
        I found your response very interesting. It actually makes me think this is doable because "hundreds of questions" doesn't sound too bad. Many projects answer hundreds of questions.
  - ryukafalz 6y ago
    Well... diffing at least is possible :) https://programmaticallyspeaking.com/git-diffing-excel-files.html https://programmaticallyspeaking.com/git-diffing-excel-files... Git is flexible!
  - sidpatil 6y ago
    TortoiseGit had Excel diff available out of the box the last time I used it. [1] The official tool would be Spreadsheet Compare [2], which looks like it does a better job than TortoiseGit's Excel diff. But it seems to be only available for specific versions of MS Office, according to the website. The best of both worlds would be to write a version of diff-xls.js that used Spreadsheet Compare. [1] https://github.com/TortoiseGit/TortoiseGit/blob/master/contrib/diff-scripts/diff-xls.js https://github.com/TortoiseGit/TortoiseGit/blob/master/contr... [2] https://support.microsoft.com/en-us/office/overview-of-spreadsheet-compare-13fafa61-62aa-451b-8674-242ce5f2c986 https://support.microsoft.com/en-us/office/overview-of-sprea...
    - phonon 6y ago
      https://www.xltrail.com/ https://www.xltrail.com/
apcragg 6y ago
Going to guess GNURadio based on calling it a Python script executor that outputs xml. If that's true, I'd that it really starts to break down when the desired logic breaks from the "apply sequential steps to a stream of contiguous data" paradigm.
- yoz-y 6y ago
  It was OpenViBE, but looking at GNURadio it looks fairly similar so I expect limitations would be also quite comparable.
- Spivak 6y ago
  I would have assumed that no-code tools would have actually shined with weird non-linear dataflows since they’re usually all graph based. Kind of a shame really since having a dependency solver as core part of the language structure sounds really cool.
bmitc 6y ago
> Also, no version control. Or, in our case since we used XML for output: poor version control. Reading horror stories about Excel also confirm this, it is hard to do correct complex programs in visual environments. Just because some visual systems don’t have version control doesn’t mean they can’t exist. It isn’t like text-based diffing just poofed into existence. Someone had to build them, and even then they aren’t all created equal. For example, I use P4Merge to diff and merge from Git instead of using the poor UX of the built-in terminal tools. I would argue that visual programming languages are much more ready to be diffed and merged than text since they usually already represent a graph.
- yoz-y 6y ago
  Graph annotations matter a lot for diffing I think. I think this is actually a good space to explore as it is a hard problem, and would require some serious UX research on how to handle this. I feel that the one-dimensionality of text makes merging and reasoning about diffs simple, because they are easy to represent side by side. To diff something like an image, or a graph, you probably want to see them on top of each other, however that makes it harder to see the whole.
  - Wowfunhappy 6y ago
    > To diff something like an image, or a graph, you probably want to see them on top of each other I look at revisions of Keynote slides this way (side by side) via Apple's "Show Revision History", a feature I'm frankly much too reliant on. The only difference is that with code, editors actually highlight the changes between snapshots. Ideally, you'd want to add that.
  - endergen 6y ago
    Abstract has pretty impressive diffing for Sketch assets and is basically Git/Github for designers
  - HPsquared 6y ago
    For Excel there is Microsoft Spreadsheet Compare, which shows the files side-by-side, highlighting differences in data/formulas/properties, and also shows the differences as a list. It can be quite clever, e.g. figuring out that columns or rows have been added or deleted (much like a diff on a text file).
ktta 6y ago
I have a similar experience as you. I worked on a Neuroscience/BCI focused signal processing platform, and also came up with the idea of having a "Python script executor". We used YAML though to store the pipelines. Seems like a very recurring problem.
- yoz-y 6y ago
  Mine was also a BCI processing platform actually (OpenViBE).
  - ktta 6y ago
    The software I worked on has striking similarities to OpenViBE. I am surprised we didn't find the software you worked on when we were looking around. There are also other programs you might find similar - NeuroPype & Open Ephys. Our first milestone was a speller similar to yours however we worked with MEAs rather than EEG. Small world!
enraged_camel 6y ago
I run a no-code agency, and my conclusions match yours: no-code tools are great for getting up and running, and for involving less technical people in process development. But sooner or later you'll need to do something that is outside the boundaries of the no-code platform's feature set, at which point extending it becomes a huge mess, because you then are forced to write code and hook it up to the no-code process in very strange and awkward ways. Like you say, lack of source control is the biggest pain point.
- code-scope 6y ago
  Agree, Remind me of GWT (google web toolkit) - Marketing message sounds very good: Let your Java Developer write java, GWT compile it into Javascript and run it on the webpage. In reality, it only works for "hello world" with 2 buttons. Anything non-trivial requires developers who are experts in Java, Javascript and GWT compiler/translator which translate JAVA to javascript. Debugging machine generated code was hell.
  - acemarke 6y ago
    Eh, I built one GWT app by myself in 2011-12, maybe 40K lines of GWT code. First web app I'd ever worked on - all my existing experience was desktop (C#, C++, Java, Python). It worked as advertised, and let me build something useful. Another team has a GWT app that we are just now finally working on migrating. Anecdotally, I've seen user group discussions of very large enterprise GWT apps. So, the technology does actually work as advertised. Having said that, GWT stagnated while the modern JS ecosystem evolved. GWT's debugger plugin died, and JS build and debug tooling kept getting better. React is a fundamentally superior approach to building UIs. And, while I'm biased, the React+Redux+TS combo is a solid toolset for building apps, and the ability to actually develop and debug code is way better than what GWT ever provided.
xmprt 6y ago
Difficulty in version control and testing is one of the reasons I don't think I could ever work in a no-code environment. It's an issue that I'm sure many people don't care much about but it's also a big reason I doubt no-code will ever overtake custom code solutions.
treeman79 6y ago
15 years ago I had a business try to force a group of us into such a system. Almost everyone that agreed are still there. Great way to kill a career.
- recursive 6y ago
  Different people value different things. Some people would seek out that degree of stability.
  - murukesh_s 6y ago
    Second that.. while some others prefer to join the rat race..
rajinl 6y ago
I worked for a startup that built a no code platform. The experience you had, was the same experience that the majority of our customers had. Its a general problem with low code. We tried to make the software easily extendable so that developers could refactor away the complexity, by easily adding new tools to the design surface. The approach worked quite well for internal projects, but was at odds with the marketing approach to the product, so it was never pushed to clients. Clients were sold a utopia of business analysts dropping some components onto a designer and hey presto. Low code can work, but in the same way as traditional dev, where code should be refactored into components that's are easy to reason about. The problem is that this is hard to sell. There is a very nice balance to be had with combining low code with traditional dev. Its just very hard to find that balance. Its far easier to write good code in a traditional language that in a low code environment. If you add to that the expectations created from low code demos, its mostly a recipe for disaster.
murukesh_s 6y ago
I started building "no code" tools since 2004. I am also the author of codeflow - a not yet open sourced visual programming platform. I wish no code distinguishes between frontend no code(webflow, wix etc), backend no code(codeflow, mulesoft etc) and full stack no code(outflow, mendix etc). First of all this "no code" is being used for decades in fortune 500 companies and many of their major backend services are run on yesteryear no code. In fact it wouldn't be wrong if to state that all big financial companies use no code as part of their major backend stack (its called in different names such as middleware/soa/integration/etl etc), but they are all visual, drag-and-drop backend/business logic builders that would have required complex coding without them. In my decades of experience there are of course many ups in no code, but as with any paradigm, the downs are highlighted the most and especially when you want to disrupt the text-based programming world that existed for almost a century now. The major complaints about visual programming environment (backend) are: 1. Code is more expressive for experienced devs Its true that code is much more expressive than generic graphical programming platforms for writing algorithms.. But how many of us write algorithms on daily basis?. What all of us do is glue various reusable pieces together to build the business logic. And for gluing graphical programming is actually superior - you can discover easily, dependent fields can be expressed easily etc. You need to use code in a properly designed no code system, but it's only 5% of the project. Now coming back to code being more expressive, if you look at algorithmic visual programming platforms designed for expressive coding like DRAKON (https://en.wikipedia.org/wiki/DRAKON https://en.wikipedia.org/wiki/DRAKON), you can see that they are equally good or even better than coding. 2. No or degraded version control experience. This is true as visual programs are still written to file as xml or json and there is disconnect between committing that vs seeing actual programs as graphs. This is a difficult problem to solve. 3. Incompatible or poor tooling This is related to above point. Because visual programming tools need to distribute with a custom made IDE, the common tooling and CLI other available for generic text based programs can be lacking. 4. Hitting a wall This is one of the biggest drawback I have heard from the devs so far. To be honest which programming platform have not made you hit a wall? In node.js you hit the multi-thread wall, in Java you hit the thread safety/performance(high memory usage) wall. In python you hit the performance wall. How do you solve it? Well in python you solve it using C or ASM libraries - and expose it to python. but you seldom hear a cry from python devs saying they reverted to C because python is slow or lacking.. Cos you learn to use the right tool for the right purpose. Similarly a well designed visual tool will let you do few things extremely well, but like no single programming platform can do everything extremely well, same is with no code or visual tools - for e.g. see DRAKON for writing expressive or algorithmic code. 5. Performance not on par. Most of visual programs tend to not focus on performance as the priority is different. However this can be solved with compiling the graphs to native code. When we built Codeflow, we tried to solve 4 and 5 and in our opinion we succeeded to good extend. 2 and 3 requires more effort from the vendor and the community (which is hard because every visual tool is unique). and 1 is possible but require more research. One way to think about visual programming is this way - imagine a world where graphical vector image editing tools evolved without mouse - i mean you literally have to code everything - right from the pixel you need to edit, the selection - everything. Smart designers (or more of coders) became experts in it and they can produce some great quality images. The tooling is also great as the tool existed for decades with hundreds of libraries and ecosystem surrounding it. Now you come up with a new paradigm where you can use mouse and make it easy for novice designers to use it - there are two benefits you tout - More artists as opposed to coders can now create images - its much more easy to build the images. The coders on the other hand are not in favour of the new tool both subconsciously and consciously. Consciously because the new tool, while better in many aspects are no where near the previous precise tool in expressing the image - and tooling as well (version control, transformations, plugins etc). Subconsciously because somewhere they feel their decades of experience is not relevant anymore.. this is controversial but i have felt it when interacting with senior devs. (Similar to how many don't want to move away from vi/m to vs code for e.g).

by yoz-y 6y ago

Wowfunhappy 6y ago

> Also, no version control. On Mac, Apple apps and other "Mac-native" programs save revisions automatically in the background. At any point, the user can select "Show Revision History" and scroll through a timeline of changes. I'm not sure if this works with Excel, but it does with iWork/Numbers, and I use it all the time. Now, Apple's implementation is just a simple timeline—there's no equivalent of version tagging, or git blame. But all of that could be done within a graphical environment similar to Apple's. It wouldn't be as advanced as Git, but I bet it could do what 95% of people actually use Git for.

quietbritishjim 6y ago
You can also commit Excel files to a git repo. That lets you get back to old revisions and look at the commit messages. But you're not going to get a diff or git blame, which is what the parent comment really meant.
- Wowfunhappy 6y ago
  > But you're not going to get a diff or git blame, which is what the parent comment really meant. You could though. Microsoft (or anyone else creating a "no code" platform) could absolutely build that into a graphical timeline view. Select these two snapshots, and show which cells changed.
  - ayende 6y ago
    This exists, at least for Word and likely for Excel as well It is also horrible,hard to understand and not useful for most tasks you will use source control for
    - Wowfunhappy 6y ago
      But is that inherent in any GUI-driven solution, or is it because Microsoft has never prioritized it as a first-class feature? I'd argue it's the latter. It's certainly not trivial (as Git wasn't trivial), but conceptually, version control strikes me as one of the easier things to translate to a GUI-driven environment. And it's something that should be translated, because version control is a major problem even in domains which have nothing to do with code, e.g. graphic design.
      - theamk 6y ago
        It is not clear to me at all how to make a good version control at GUI apps. Let’s start with diff - If this is a text doc, diff seems easy. Show old and new text next to each other, somehow highlight new and old version. Immediate problem: what if you choose to highlight “new” with purple + underline, but user is already using purple + underline as a part of their text. Do you choose a different color? Or just hope it is “clear from context”? Now for spreadsheets: the formula has changed, how do you show this? You can expand the cell to show formulas, but those can he huge, so your document can become unreadable. Or maybe just highlight the cell and let user click on it to see the formula difference - but then you can no longer see the changes at a glance. What about things with no text representation, like conditional cell format? Are you going to come up with text representation just for display purposes, or are you going to design special text formatting dialog which shows “new” and “old” values? There are hundreds of questions about GUI diffs which simply do not exist in texts.
        neolog 6y ago
        I found your response very interesting. It actually makes me think this is doable because "hundreds of questions" doesn't sound too bad. Many projects answer hundreds of questions.
- ryukafalz 6y ago
  Well... diffing at least is possible :) https://programmaticallyspeaking.com/git-diffing-excel-files.html https://programmaticallyspeaking.com/git-diffing-excel-files... Git is flexible!
- sidpatil 6y ago
  TortoiseGit had Excel diff available out of the box the last time I used it. [1] The official tool would be Spreadsheet Compare [2], which looks like it does a better job than TortoiseGit's Excel diff. But it seems to be only available for specific versions of MS Office, according to the website. The best of both worlds would be to write a version of diff-xls.js that used Spreadsheet Compare. [1] https://github.com/TortoiseGit/TortoiseGit/blob/master/contrib/diff-scripts/diff-xls.js https://github.com/TortoiseGit/TortoiseGit/blob/master/contr... [2] https://support.microsoft.com/en-us/office/overview-of-spreadsheet-compare-13fafa61-62aa-451b-8674-242ce5f2c986 https://support.microsoft.com/en-us/office/overview-of-sprea...
  - phonon 6y ago
    https://www.xltrail.com/ https://www.xltrail.com/

apcragg 6y ago

Going to guess GNURadio based on calling it a Python script executor that outputs xml. If that's true, I'd that it really starts to break down when the desired logic breaks from the "apply sequential steps to a stream of contiguous data" paradigm.

yoz-y 6y ago
It was OpenViBE, but looking at GNURadio it looks fairly similar so I expect limitations would be also quite comparable.
Spivak 6y ago
I would have assumed that no-code tools would have actually shined with weird non-linear dataflows since they’re usually all graph based. Kind of a shame really since having a dependency solver as core part of the language structure sounds really cool.

bmitc 6y ago

> Also, no version control. Or, in our case since we used XML for output: poor version control. Reading horror stories about Excel also confirm this, it is hard to do correct complex programs in visual environments. Just because some visual systems don’t have version control doesn’t mean they can’t exist. It isn’t like text-based diffing just poofed into existence. Someone had to build them, and even then they aren’t all created equal. For example, I use P4Merge to diff and merge from Git instead of using the poor UX of the built-in terminal tools. I would argue that visual programming languages are much more ready to be diffed and merged than text since they usually already represent a graph.

yoz-y 6y ago
Graph annotations matter a lot for diffing I think. I think this is actually a good space to explore as it is a hard problem, and would require some serious UX research on how to handle this. I feel that the one-dimensionality of text makes merging and reasoning about diffs simple, because they are easy to represent side by side. To diff something like an image, or a graph, you probably want to see them on top of each other, however that makes it harder to see the whole.
- Wowfunhappy 6y ago
  > To diff something like an image, or a graph, you probably want to see them on top of each other I look at revisions of Keynote slides this way (side by side) via Apple's "Show Revision History", a feature I'm frankly much too reliant on. The only difference is that with code, editors actually highlight the changes between snapshots. Ideally, you'd want to add that.
- endergen 6y ago
  Abstract has pretty impressive diffing for Sketch assets and is basically Git/Github for designers
- HPsquared 6y ago
  For Excel there is Microsoft Spreadsheet Compare, which shows the files side-by-side, highlighting differences in data/formulas/properties, and also shows the differences as a list. It can be quite clever, e.g. figuring out that columns or rows have been added or deleted (much like a diff on a text file).

ktta 6y ago

I have a similar experience as you. I worked on a Neuroscience/BCI focused signal processing platform, and also came up with the idea of having a "Python script executor". We used YAML though to store the pipelines. Seems like a very recurring problem.

yoz-y 6y ago
Mine was also a BCI processing platform actually (OpenViBE).
- ktta 6y ago
  The software I worked on has striking similarities to OpenViBE. I am surprised we didn't find the software you worked on when we were looking around. There are also other programs you might find similar - NeuroPype & Open Ephys. Our first milestone was a speller similar to yours however we worked with MEAs rather than EEG. Small world!

enraged_camel 6y ago

I run a no-code agency, and my conclusions match yours: no-code tools are great for getting up and running, and for involving less technical people in process development. But sooner or later you'll need to do something that is outside the boundaries of the no-code platform's feature set, at which point extending it becomes a huge mess, because you then are forced to write code and hook it up to the no-code process in very strange and awkward ways. Like you say, lack of source control is the biggest pain point.

code-scope 6y ago
Agree, Remind me of GWT (google web toolkit) - Marketing message sounds very good: Let your Java Developer write java, GWT compile it into Javascript and run it on the webpage. In reality, it only works for "hello world" with 2 buttons. Anything non-trivial requires developers who are experts in Java, Javascript and GWT compiler/translator which translate JAVA to javascript. Debugging machine generated code was hell.
- acemarke 6y ago
  Eh, I built one GWT app by myself in 2011-12, maybe 40K lines of GWT code. First web app I'd ever worked on - all my existing experience was desktop (C#, C++, Java, Python). It worked as advertised, and let me build something useful. Another team has a GWT app that we are just now finally working on migrating. Anecdotally, I've seen user group discussions of very large enterprise GWT apps. So, the technology does actually work as advertised. Having said that, GWT stagnated while the modern JS ecosystem evolved. GWT's debugger plugin died, and JS build and debug tooling kept getting better. React is a fundamentally superior approach to building UIs. And, while I'm biased, the React+Redux+TS combo is a solid toolset for building apps, and the ability to actually develop and debug code is way better than what GWT ever provided.

xmprt 6y ago

Difficulty in version control and testing is one of the reasons I don't think I could ever work in a no-code environment. It's an issue that I'm sure many people don't care much about but it's also a big reason I doubt no-code will ever overtake custom code solutions.

treeman79 6y ago

15 years ago I had a business try to force a group of us into such a system. Almost everyone that agreed are still there. Great way to kill a career.

recursive 6y ago
Different people value different things. Some people would seek out that degree of stability.
- murukesh_s 6y ago
  Second that.. while some others prefer to join the rat race..

rajinl 6y ago

I worked for a startup that built a no code platform. The experience you had, was the same experience that the majority of our customers had. Its a general problem with low code. We tried to make the software easily extendable so that developers could refactor away the complexity, by easily adding new tools to the design surface. The approach worked quite well for internal projects, but was at odds with the marketing approach to the product, so it was never pushed to clients. Clients were sold a utopia of business analysts dropping some components onto a designer and hey presto. Low code can work, but in the same way as traditional dev, where code should be refactored into components that's are easy to reason about. The problem is that this is hard to sell. There is a very nice balance to be had with combining low code with traditional dev. Its just very hard to find that balance. Its far easier to write good code in a traditional language that in a low code environment. If you add to that the expectations created from low code demos, its mostly a recipe for disaster.

murukesh_s 6y ago

I started building "no code" tools since 2004. I am also the author of codeflow - a not yet open sourced visual programming platform. I wish no code distinguishes between frontend no code(webflow, wix etc), backend no code(codeflow, mulesoft etc) and full stack no code(outflow, mendix etc). First of all this "no code" is being used for decades in fortune 500 companies and many of their major backend services are run on yesteryear no code. In fact it wouldn't be wrong if to state that all big financial companies use no code as part of their major backend stack (its called in different names such as middleware/soa/integration/etl etc), but they are all visual, drag-and-drop backend/business logic builders that would have required complex coding without them. In my decades of experience there are of course many ups in no code, but as with any paradigm, the downs are highlighted the most and especially when you want to disrupt the text-based programming world that existed for almost a century now. The major complaints about visual programming environment (backend) are: 1. Code is more expressive for experienced devs Its true that code is much more expressive than generic graphical programming platforms for writing algorithms.. But how many of us write algorithms on daily basis?. What all of us do is glue various reusable pieces together to build the business logic. And for gluing graphical programming is actually superior - you can discover easily, dependent fields can be expressed easily etc. You need to use code in a properly designed no code system, but it's only 5% of the project. Now coming back to code being more expressive, if you look at algorithmic visual programming platforms designed for expressive coding like DRAKON (https://en.wikipedia.org/wiki/DRAKON https://en.wikipedia.org/wiki/DRAKON), you can see that they are equally good or even better than coding. 2. No or degraded version control experience. This is true as visual programs are still written to file as xml or json and there is disconnect between committing that vs seeing actual programs as graphs. This is a difficult problem to solve. 3. Incompatible or poor tooling This is related to above point. Because visual programming tools need to distribute with a custom made IDE, the common tooling and CLI other available for generic text based programs can be lacking. 4. Hitting a wall This is one of the biggest drawback I have heard from the devs so far. To be honest which programming platform have not made you hit a wall? In node.js you hit the multi-thread wall, in Java you hit the thread safety/performance(high memory usage) wall. In python you hit the performance wall. How do you solve it? Well in python you solve it using C or ASM libraries - and expose it to python. but you seldom hear a cry from python devs saying they reverted to C because python is slow or lacking.. Cos you learn to use the right tool for the right purpose. Similarly a well designed visual tool will let you do few things extremely well, but like no single programming platform can do everything extremely well, same is with no code or visual tools - for e.g. see DRAKON for writing expressive or algorithmic code. 5. Performance not on par. Most of visual programs tend to not focus on performance as the priority is different. However this can be solved with compiling the graphs to native code. When we built Codeflow, we tried to solve 4 and 5 and in our opinion we succeeded to good extend. 2 and 3 requires more effort from the vendor and the community (which is hard because every visual tool is unique). and 1 is possible but require more research. One way to think about visual programming is this way - imagine a world where graphical vector image editing tools evolved without mouse - i mean you literally have to code everything - right from the pixel you need to edit, the selection - everything. Smart designers (or more of coders) became experts in it and they can produce some great quality images. The tooling is also great as the tool existed for decades with hundreds of libraries and ecosystem surrounding it. Now you come up with a new paradigm where you can use mouse and make it easy for novice designers to use it - there are two benefits you tout - More artists as opposed to coders can now create images - its much more easy to build the images. The coders on the other hand are not in favour of the new tool both subconsciously and consciously. Consciously because the new tool, while better in many aspects are no where near the previous precise tool in expressing the image - and tooling as well (version control, transformations, plugins etc). Subconsciously because somewhere they feel their decades of experience is not relevant anymore.. this is controversial but i have felt it when interacting with senior devs. (Similar to how many don't want to move away from vi/m to vs code for e.g).