There are certainly valid arguments that you hive certain things up when moving to an array language, but loops are not one of those.

That said, you won't use loops as much, but that's not because loops are not available.

The difference is much deeper, but the best way to understand it is probably to check out an introduction (there is a lot on youtube).

I'd personally be happy to give an introduction to anyone willing to listen, but this comment field is not the place to do it.

Yet, even as the 90's rolled around you could find people writing articles in Quote Quad arguing that suggestions to add structured programming constructs to APL was somehow going against the spirit of the language.

Kinda sad it took 50 years for that attitude to change.

However, I disagree with some points made. In particular, this one:

> Some people say the most important issue at hand is to improve the data structures of APL. Others say what APL needs is a little bit of Franglais, which in our terms is APLGOL. “If APL only had the while-statement, or the if-then-else, or the for-statement, it would become such a perfect language.” That’s ridiculous. And it’s silly to say that if APL had arrays of arrays, all of our troubles would disappears. In point of fact, what will happen is that the amount of troubles would just grow almost exponentially if that happened.

This turned out to be untrue. And the resistance in the community to do this is partly what lead to its loss of popularity.

Modern array languages, and indeed most APL implementations, have these things and they did not create troubles. In fact, it made them practical and easier to learn, because it allows users to use the style that suits the problem at hand the best. And in some cases, a pure array solution is just not appropriate.

Both Lisp and array language programmers are sadly somewhat rare.

Comments URL: https://news.ycombinator.com/item?id=43181178

Points: 1

# Comments: 0

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...

Comments URL: https://news.ycombinator.com/item?id=42004159

Points: 1

# Comments: 2

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...

As for the language, the longer version looks like an imperative solution please it is an imperative solution. Kap allows you to write code that looks mostly like your average scripting language:

    a ← 0
    sum ← 0
    while (a < 10) {
      sum ← sum + a
      a ← a + 1
    }
    sum

Of course, an actual Kap programmer wouldn't write the code above like that. They'd write it like this instead: +/⍳10

There is a perfectly valid argument that the ⍳ in the example above could be written in a different way, and sure, Rob Pike chose to use actual words in his version of APL, or you could use J where the example would be written as +/i.10

But none of that is really important, and most people in the array programming community doesn't care whether you write "plus reduce iota 10", or +/⍳10. What they really care about it how the idea of using array operations completely eliminates loops in most cases. That's what is interesting, not the choice of symbols.