>other times you just need a database with a front end and a low-code solution is best

Until you need it to do something slightly beyond its capabilities and then you are trapped with an app that needs to be rewritten with data that needs to be migrated in order to implement one small feature.

That's the same thing with all technology choices though - if requirements change substantially you always risk a rewrite. If write a full-code application with all your logic in server-side .NET and suddenly your users have a requirement to use it offline, and then you are trapped with an app that needs to be rewritten with data that needs to be migrated in order to implement one feature

This is all part of having a good level of intuition for what capabilities you are likely to need, and then picking appropriate technology.

There is a vast difference between the things which are blocked because youre not using a turing complete programming language and things which are blocked because of the nature of that language though.

You'll probably run up against the former quite quickly. The latter possibly never.

Yeah but ‘Turing complete languages’ have their own limitations compared to no code, like being comparatively slow to develop in.

(In quotes because many/most no-code environments are Turing complete, but you still wouldn’t want to develop certain apps/logic in them)

> Why take something out of your toolbox?

I completely agree with you and this is the crux of it. Even if you know how to code, there situations where a nocode tool (like retool) is the best tool for the job

> Why take something out of your toolbox?

The problem isn't my toolbox.

The problem is someone elses toolbox, who often isn't an engineer, when that someone hits the limits of that shiny, sparkly tool he put in his box.

Because at that point, software engineers have to figure out how to interface some extension with that thing. Which may be easy. Or it may be next to impossible, because the tool usually doesn't have things like version control, standard interfaces other than outgoing HTTP (if it even has that), compatibility with common IDEs or the ability to unit test. Bonus points if it doesn't even store the box-and-line-diagrams in something vaguely grep-able like XML, but uses a proprietary binary format...or stores them on the vendors servers making them completely inaccessible other than through the vendors interface.

Right tool for the right job? No problem with that. If it "empowers" someone to do something he couldn't do otherwise...great, full support.

But as soon as someone wants me to interface my toolbox with it, I will demand that it offers the same qualities that I expect from every other tool that I use. Because these qualities aren't arbitrary, they evolved over decades of hard earned lessons in software engineering.