I often use the code from the standard library that renders array output as an example of real world Kap code that is written in what I would consider regular style.

https://codeberg.org/loke/array/src/branch/master/array/stan...

In my code I'd sometimes write assertions in the beginning of a function to not only ensure it's called with the right shape but also as documentation.

Also, in practice really high rank arrays aren't used much. Even 4 is pretty rare.

You can ofcourse removethe capability to do thatand you'll effectively force the programmer to write more venous code, but then its strength as an interfacing tool is very much reduced.

The Iversonian languages has the capability to write incredibly terse code which is really useful when working interactively. When you do, your code truly is write-only because it isn't even saved. This is the majority of code that at least I write in these languages.

When writing code that goes in a file, you can choose which style you want to use, and I certainly recommend making it a bit less terse in those cases. The Iversonian languages are still going to give you organs that are much shorter than most other languages even even it's written in a verbose style.

Even today, after having worked in these languages for years, I am still put off a bit by the walls of code that some array programmers produce. I fully understand the reasoning why it's written like that, but I just prefer a few spaces in my code.

I've been working on an array language based on APL, and one of my original goals was to make "imperative style" programming more of a first-class citizen and not punish the beginner from using things like if-statements. It remains to be seen how well I succeeded, but even I tend to use a more expressive style when terseness doesn't matter.

Here's an example of code I've written which is the part of the implementation that is responsible for taking any value (such as nested arrays) and format them nicely as text using box drawing characters. I want to say that this style is a middle ground between the hardcore pure APL style found in some projects and the style you'll see in most imperative languages: https://codeberg.org/loke/array/src/branch/master/array/stan...

It's a useful thing to learn though. And dare I say it, fun. Even if there was zero benefit to it, it'd still be fun. As it turns out, there really are benefits.

For me, the biggest benefit is when I'm working with data interactively. The syntax allows me to do a lot of complex operations on sets of data with only a few characters, which makes you feel like you have a superpower (especially when comparing to someone using Excel to try to do the same thing).

The problem is that most people who are unfamiliar with APL usually don't see the larger picture, and you need to learn the language before understanding the reasoning. But once you understand it, you don't really need to hear the arguments anymore.

One argument that may be easier to digest is that the very optimised syntax allows you to easily work with the data in an interactive fashion. This is similar to how a calculator that forced you to write 1.add(2) would be rather painful to use, even if it functionally is the same as 1+2.

In programs that you save to a file and is part of a larger project, this benefit is of course less relevant.

You can read more about it here if you're interested: https://www.aplwiki.com/wiki/Grade

And here's a silly example where a random array is created, then an array lookup is performed on the sorted indexes:

https://kapdemo.dhsdevelopments.com/clientweb2/#a%20%E2%86%9...