I think there's a lot of useful unexplored territory in this sort of tool. So much work nowadays is happening in maps/dictionaries/what-have-you, with a lot of work being, essentially, data shape transformation. Despite this, many languages aren't great at this! we have tools that work alright on first-order operations but fall apart on higher level things. Even really simple things like "conditionally include a key"…
>How many times have we all written A decent amount, but I'd rather have all of that separate because it makes the code easier to read. I'm not interested in how concise a block of JSON text can be with all of my transformations of conditionals and loops. That's going to be difficult to read without highlighting. I also can't put a breakpoint in the middle of some JSON text without the appropriate support from the la…
I think there's a bit of a conflict with regards to immutability. When I see a variable in the code, it's much easier to handle a single definition rather than a "half-definition" followed by a bunch of conditionals.
I've also seen some waaay to concise code that becomes super legible after just one extra line of code to split things up.
I've run into the opposite problem a lot though. Even if every operation is simple, the length of code makes the intent unclear, especially in cases involving aggregation. Death by a thousand cuts
results = []
for elt in other_array:
if elt is None:
results.append(0)
else:
results.append(f(elt))
results = [ f(elt) if elt is not None else 0
for elt in some_other_array ]
Clarity is the most important, and after a couple conditionals it makes sense to be more explicit about control flow. But many common tasks are not _about_ control flow, even if C-isms make us write them as if they do. "if" statements generate so many bugs, eliminating them is great.