4 ms·

Array languages come up a lot on HN so I’ve looked into them a few times. I think it’s a hard thing to gauge without trying to use them in anger for a while. On

Array languages come up a lot on HN so I’ve looked into them a few times. I think it’s a hard thing to gauge without trying to use them in anger for a while. One of the core arguments for them that resonates with me is that once you understand the operators, many patterns become so terse and repeat so often, you can refactor large portions of code very rapidly. I use a lot of F#, and can see the beginnings of this where translating from C# to F# often shrinks the code size to the point where I see patterns that weren’t obvious before. I believe APL, K, J, Nial, BQN, etc all have more extreme versions of that happening. It also makes differences stand out so logic bugs are more visually obvious.

ParetoOptimal 3y ago
I can corroborate: That same feeling of as simple and terse code as possible happens in Haskell too. However the most popular professional style of Haskell code is far too verbose for me to be able to "see the essence" in many cases without a round of refactoring. Its far worse and far more grating for Java code that makes you do so much for so little.
steveBK123 3y ago
Sometimes the benefit of shorter codebases is that you can actually see the code. Understanding that your logic bug is obviously somewhere within a handful of lines of K/Q/etc that fit neatly on a single screen vs scrolling through 200 lines of logic in Python/Java/whatever is focussing. Sure each line is more compact and may take more time to digest, but that is a reasonable trade-off in most cases. For me, 10 lines you need to read carefully beats 100 lines of having your eyes glaze over and repeatedly skip over the bug because you are so dulled to all the boilerplate.