> Anytime you're trying to color outside the tool's predefined lines you'll be hurting and spending ridiculous amounts of time. This is exactly my experience.

> Anytime you're trying to color outside the tool's predefined lines you'll be hurting and spending ridiculous amounts of time. This is exactly my experience. This comes up a lot when someone tries to take a 'DSL' approach to solve a general problem. "Look what you can do in just one simple line!", and it's true, one line and you've got something working. Then you ask questions that weren't anticipated. How do I reuse the 5 lines I wrote here in another place? How do I write a test for those 5 lines? Can I log outputs in-between lines? Those aren't exactly scary questions for any programming language - the answer is trivial, and what those languages solve for. But in these fancy no-code systems the answer is "you can't", more often than not. I care way more about how a system is going to evolve and how it will be maintained than solving trivial problems in one line. They end up being completely unmaintainable and you lose more time than you save. Frankly, coding isn't that hard. You don't need to be an expert to be effective, and there's a massive amount of tooling, knowledge-sharing, and investment already there. All of this no-code shit is such a waste of time.