I would consider coding these things by hand in the following non-exhaustive cases:
- I am writing the thing you are asking someone to write
- I have performance/memory constraints that existing high-level abstractions can’t adequately deal with
- I have legal or other business constraints preventing me from using existing high level tools (eg company prefers to build in house to minimize dependency risk exposure)
- I want to learn how that stuff works
- I am working on new technology that does not fit cleanly into the prescribed mold of the high level implementations
RE: your second point, it can easily be covered by a declarative DSL with a few conditions (in macros / code generating constructs).
Example: in Elixir you have the so-called streaming functions you can pipe to each other that can do e.g. filtering, mapping, chunking and what not. But they don't actually operate on the data you passed them; they generate further functions and produce chains that only start working when you put a certain command at the end of the command pipe.
This works really well if you work with a collection of 100_000 elements. Since Elixir is an FP language, you don't want to copy this huge list, say, 7 times one after another (assuming your transformation pipe has 7 stages). By using the streaming functions you only use the original list and produce a final list. Just one roundtrip to the memory.
But... it has a performance impact and it's definitely not worth doing if your collections are e.g. less than 1000 elements, maybe even 2000.
A declarative DSL can easily cover for such cases and have separate code branches addressing them.
RE: tinkering, obviously. I am not saying normal programming should be "banned". But it's about time we have higher-order programming, man. We're all collectively slacking off on that and should be really ashamed!
The rest of your points I don't see how to automate and that's OK. Like any tool, declarative programming should be used sparingly and only where it truly applies.
