One thing that your examples tend to have in common is that they deal with describing states (documents), not modelling processes. Maybe that has something to do with it. Describing actions ends up effectively requiring flowcharts, which is what visual programming typically ends up being, and that gets painful and slow tremendously quickly. That's why visual programming tools do not endure: because once you get skilled enough, you will find them annoyingly constrained.

I can just point out that my niche (accounting) is arguably one of the oldest in computing. Visual programming to address accounting challenges has been tried over, and over, and over, and it failed. every. single. time. It's a massive target that everyone hopes to hit, because the jackpot is massive, but I would argue that it will never happen. Excel keeps winning because it doesn't even try to play that game: if you want to do anything beyond instant calculation, it gives you VBA and off you go. That's what people really want: if they are smart enough to want advanced process modelling, they are smart enough to learn how to write an "if" block.

> it is difficult to get a man to understand something when his salary depends on his not understanding it.

Believe me, there is also a large industry of programmers invested in visual paradigms; and their salary depends directly on not understanding the lessons of the past.

Just because your particular niche has certain complexities that make it more resistant to visual representation with current methods, doesn’t mean we throw out the whole no code movement.

After 20+ years of various companies trying to create a good no-code tool for html/css (eg dreamweaver, frontpage, etc), Webflow finally solved it IMO. So it can take a long time.

But I see no reason why this won’t travel further down the software stack eventually. And we shouldn’t be afraid of it like it’s a threat to us.

Some tasks are inherently complex. Take data modelling as an example. Properly designing a database requires formal training. There's no way around it, and when you mask database design with a UI, you get the worst of both worlds. The complexity is there, unskilled users won't be able to tackle it, and the UI gets in the way of professionals with formal training.

Naturally, there is a continuum of tasks to be done, some can be solved with a poorly designed solution. If a user is empowered to generate a subpar solution, it is still better than no solution at all. That's the secret for Excel being the second best tool for any data manipulation task (for each task there is a better tool, but excel gets the job done in all of them).

The error here is selling visual programming tools as the next evolution step, which will phase out text UIs. It's not. It's a different tool, for a different use case, to be used by a different cohort of users.

My point isn’t that no code tools remove complexity. My point is that they make complexity easier to learn and deal with.

For example, Webflow, which is a no code tool for front end development of static sites, doesn’t eliminate any of the complexity of HTML and CSS.

It’s not easy or dumbed down at all. Most users need to watch tons of video tutorials to get started (if they don’t already know html/css).

But what the UI does do, is make it easier to learn those complexities.

It’s not offering a simplified set of dumbed down options. It’s offering a visual way to deal with all the complexities of HTML/CSS.

Personally, I’ve transitioned to building all marketing sites on webflow, not because it removes complexity (I want complexity!) but because dealing with the complexity is faster and easier with the tool.

Uhm, a visual HTML designer, a field where we've not had any tool before (/sarcasm). But this is different! And you're totally not going to drop it once you've learnt the complexity and discovered all limitations. But hold on...

> to building all marketing sites

Ah yes. So the really complex stuff you'll still do with text. Got it.

There’s other no code tools for things like mobile apps and CRUD.

Ultimately, I think there’s a lot of fear in these comment threads when no code is mentioned, and it’s misplaced.

A rising tide raises all boats. The more we can empower people to create things and solve problems for people, the better off we’ll all be.

You're joking, right? There are loads. They all suck to various degrees, which is why they are not popular.

> Ultimately, I think there’s a lot of fear

Mine is not fear as much as frustration for having to waste cycles on stuff that will not endure.

Take Power Automation (aka MSFlow): it's very powerful, but not because it's a graphical environment; it's because we have an environment with a lot of APIs available without having to do anything. If MS gave me a blank editor with all those APIs preloaded, I would be 1000000x more productive than I am fighting with this goddamn half-broken flowcharty thingie. Meanwhile, nobody else in my team (all non-devs) want to even consider look at it. They'd rather brush up on VBA if they really need to do complex stuff. And it's a shame, because the API wiring is amazing and when things eventually run it's magical.

Repl.it with all those APIs preloaded would be so much more popular than PA, which I fully expect will eventually die a slow death like Yahoo! Pipes and friends.

Visual tools don't inherently mask complexity. They can do, and many do, which is useful for some use cases. And they can also make things visible that CLI or text based tools generally don't. In that regard, they can support developers to complete higher complexity tasks.

Both projects followed the exact same trajectory: users ultimately rejected the no-code platforms and sent all of the programming work back to professional developers. Now the professional developers were hamstrung by layers of abstraction designed for non-developers and both parties were miserable.

Excel is the shining example of no-code enabling non-professionals to create powerful tools on their own, but it may be the exception and not the rule. Ultimately the challenges of programming are not the code, but thinking abstractly about data, and that's a real skill that developers have trained and non-developers have not, and I don't think it is solvable with tooling.

So one might say the issues were more largely organizational. But these weren't lazy people, they were always looking at new tools and techniques. And they were struggling to get any payoff with the tools we had. Sadly the focus of the project was not visual programming, so we were not focusing on the users issues.

The incentives might line up better for departments that can't get tech's attention.

Is there an upper bound to the benefits of visual information in comparison to textual information when handling complex tasks so that when a task reaches a certain level of complexity it becomes easier to represent it in text as opposed to visually? The history of human communication would strongly suggest that there is.

The photo-based system would no doubt work great if the town had only a dozen people (all of whom know each other by sight), and probably work acceptably well for up to a few dozen. It's going to suck for a town with a thousand people, though, and be utterly unusable for a city of a hundred thousand.

Textual information reaches its upper bound far before visual information.

Think reading a recipe from a cookbook vs following along with a well done YouTube recipe.

The density of information delivered via video (visually) in addition to the word messaging (via audio) is roughly 10-100X that of an all text recipe.

...and with zero added effort from the human receiving the information, because our brain natively does the visual processing.

Sure, it’s faster to follow a recipe if you’ve spent ten years learning everything about cooking and food science.

Just as it’s easier to just code something if you’ve spent years learning how to code!

The point is to lower the barrier of entry, and deliver people a higher density of information faster and easier.

For example, you can't write most useful programs without knowing what a pointer/reference is. Doesn't matter if you use visual programming or textual code.

I think you need to show your work on that calculation - because I'm worried it's going to be one of those 'a video has so many bytes of information per frame etc. etc.' claims at which point I would have to wonder why I care what color Julia Child's blouse is when preparing an omelet.