[ken]

I've played around with APL a bit, and I agree that it's not that hard to gradually get to a solution in the repl, but...

The problem I have is that when I gradually get to a solution in Lisp/Ruby/Python, I end up with something which is also close to lots of other problems I want to solve (or that my manager or users ask for). In solving the problem, I've naturally built up tools for that entire problem space.

In APL, I end up building a solution which is not at all close to other problems I might want to solve. I'll take an identity, flip this, zip it with that other array, reduce it with this function, and then poof, the final step slides all the puzzle pieces together and it's perfect (and only 17 characters!), but only for that problem exactly as stated. When I get a request for something slightly different, I almost have to start from scratch.

I assume this is what the "beautiful diamond" / "ball of mud" dichotomy referred to.

[olzd]

> When I get a request for something slightly different, I almost have to start from scratch.

You don't really start from scratch though (at least I don't): most of the time you can reuse idioms with minimal adaptation.

[sheepmullet]

> When I get a request for something slightly different, I almost have to start from scratch.

Do you start over from scratch in terms of your mental model or just in terms of the actual code?

I’ve found using APL helps me to generalize a problem but the underlying code will often look very different.

I have found I waste a lot of time in other languages trying to re-use components that aren’t necessarily a good fit just because I have already written them.

[girvo]

Your last point is something I fight my hardest to avoid. It’s hard, though, but leaning on small generic functional primitives and building solutions through those has helped a lot (see: Ramda, fp-ts, and others)