lokedhs

Dyalog APL, along with other modern array languages that are related to it can all do imperative programming with loops etc.

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.

Thanks, that makes sense. I guess most CSV data you see in the real world do have headers. Perhaps I was looking too much about thr default CSV export format from Excel, focusing on making sure it can always be parsed. And Excel doesn't have column headers.

I see. Kap tries to be as generic as possible, so assuming that the table has headers doesn't feel right. If the table dont have headers, and the reader assumes it does, then you'll potentially silently lose the first row of data.

The string to specify the column types is not a terrible idea. Does it have other configuration options, like whether or not to assume the first row is the headers, or specifying the separator character?

That wouldn't help much. People who don't use these languages doesn't understand that what makes the language different isn't the syntax. There are plenty of dialects that use English words instead of symbols (check out Ivy by Ron Pike for example).

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.

Which would have been fine. In fact, if you read the notes from the very first implementation of APL you'll find that it was noted that they considered the lack of proper flow control as a gap that needed to be filled later.

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.

That list is incomplete. Those are things that Lisp invented but is now commonplace. What it also invented but rather few languages also support is the capability of metaprogramming, being able to treat code as data.

This is a good article to understand the thinking behind array languages in general, and APL in particular.

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.

To be fair, most languages in use today are just FORTRAN with diffrent syntax.

Both Lisp and array language programmers are sadly somewhat rare.

That depends on the specific code. Some code is written to be agnostic to the rank, while others make certain assumptions.

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.

Just because you can write everything on one line without any spaces doesn't mean you should.

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.