> Do they? As I see it, they make it worse.That may be because your development needs are well served already if you're a developer, so you won't see the value in such system. For people who rely on others to build every single piece of automation they need, being able to create their own small automatisms would be priceless.
> all in all they have more problems and limitations than a proper general purpose language with a good API
End users don't need a general purpose language with a good API - at least not as someting that they will handle directly. They need small, self-contained domain-specific languages that they can expand in areas where they fall short, but without the full power of a general programming system (which would overcomplicate the development environment and provide too many opportunities to shoot themselves in the foot).
> So the problem is not the language, but the support?
For me yes, partially, because I already know programming. I could work with a programming environment with complex syntax that autocompleted the required syntax to match my thoughts (something like GitHub copilot works in that direction). But that's still two points of complexity above the system I envision as possible.
Something like the classic Hypercard could be a good starting point for the mental model of such tools. A simple data model, integrated storage, and interactive processes using a programming language with minimal syntax. Expand it with hierarchical storage, expanded integration with other systems and a modern declarative language, and you're set.
Someone today pointed me to a system like this[1], Lepiter, which looks a lot like the solution end users could manage to create on their own on top of their knowledge systems: like a browser with separate cells, where each cell can run a different runtime, hyperlinked and with a simple storage mechanism.
[1] https://lepiter.io/feenk/introducing-lepiter--knowledge-mana...
> More autocompletion, documentation, automation, etc.
Those are good things but not enough. What end users are lacking the most is the possibility to create their own automated processes; most tools only allow them to choose among a library of predefined ones, without allowing them to grow the library.
> Another solution could be integrating an interface like Node-RED offers it. This seems to be quite accessible for casual experts.
Unfortunately, graph-based flow visual tools have proven to be useful only for a small subset of automation tasks largely consisting on data transformations using pre-defined functions. The most promising results in End-User Development point out that reactive, rule-based runtime environments like the spreadsheet seem to be better abstractions for allowing users to define their own computations.
> And Excel has good access for new users?
Yes, spreadsheets have a low learning curve and high ceiling. And compared to imperative programming languages, they're like walking up the slope of your house vs. extreme rock climbing.