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.

Interesting observation. The fundamental syntax of Kap is the same as APL. The imperative style is added on top, and isn't really the way you'd normally write code. The examples were written that way in order to make a point the the code can he as verbose as you want.

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

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.

It's likely a combination of both. It's certainly possible to write Kap in a much more condensed form. But things like if-statements and hash maps does allow for a more imperative style.

You're not wrong. It's very easy to get that impression when trying to learn the array languages. It's very easy for someone who's used these languages for a long time to look at a problem, and say "why did you use that really elaborate solution, when you can just use ⍸⍣¯1?". No one probably ever told you that ⍸ has an inverse, and how you could use it.

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

"More efficiently"? Maybe. It opens up a new way to think about solutions to problems. Sometimes those solutions are more efficient, and sometimes they are just different.

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 short answer is yes. There have been many presentations on this topic that tries to explain it in various ways.

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.

It's not sort. In Kap, sort down is ∨. The grade functions returns a sorted index. Basically ⍒ 3 1 2 1 1 returns 0 2 1 3 4. So yes, it performs a sort, but it returns an index that can be used to later look up the respective elements.

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

I am the author by the way. The intent wasn't really to try to sell the language. The language is what it is, but the thing I wanted to highlight was that the entire solution (language combined with the user interface) provides a better foundation for working with arrays of data than a spreadsheet. Perhaps that point would have been more clear if I had removed the actual code since it takes away from the more interesting point.

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.

Well, it's for the JVM, JS or Linux native. :-)

Point taken about the tutorials. It's still a work in progress.

That was not the point of the statement. The argument (possibly poorly phrased) was the there are people people out there that are comfortable with manipulating arrays of numbers than there are programmers who are capable of writing a Java program.

So, if the goal is to make it easier for someone to take the leap from a spreadsheet to a programming language, array languages are likely an easier hill to climb (people already familiar with, say, Python, might struggle, but they are not likely to be interested in learning a new programming paradigm anyway).

I'd argue it's partly because of tradition. If you look at early APL code, including Iverson's earliest papers, it's written with pretty much zero spaces (well, except for where spaces are required).

A lot of APL programmers continue this tradition, and it works for them. Not everybody does it though. I'm one of those people that adds spaces and newlines to try to make the code more clear for myself.

As an example of the kind of code I tend to write, here's the code for the Kap output formatter:

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

Of course, if you don't know what the symbols mean, a lot of it is probably still impenetrable, but I think this code is less dense than your typical APL code.

Original author here. Kap is inspired by APL which was very popular back in the day (70's and 80's), and has remained popular within certain segments. There is still enough interest in it to support at least one conference.

There is also J, which is used in real businesses. And K and Q are array languages that is popular in finance.

Kap takes the good ideas of APL, as well as its basic syntax, and attempts to combine that with good ideas from other languages, mainly Lisp. I personally use it as the go-to language to solve problems that most people would use Excel to solve, so clearly it's working for one person.

While Kap can be used as an Excel alternative for some subset of of problems, I have no expectation that the average Excel user will switch to it. Instead, I'm trying to adapt some of the nice user interface ideas of a spreadsheet (editing and formatting) while keeping the rest as a regular language. I also want to ensure it's easy to integrate with spreadsheets (copy&paste between Kap and Excel for example, there is also initial work done to have a realtime link with a running spreadsheet).

Nothing stops you from writing the same in Kap:

    ∇ quadraticRoots (a;b;c) {
      root1 ← ((-b)+√(b⋆2)-(4×a×c)) ÷ (2×a)
      root2 ← ((-b)-√(b⋆2)-(4×a×c)) ÷ (2×a)
      root1 root2
    }

Are any of these cars available outside the US? From what I've been able to tell, US regulations are much weakest in this regard which is possibly why there are so many words cars there.

The old Mini had that. I remember seeing it in the 80's.

Author here. The purpose of the post was not to be a tutorial for the language. Just like any other powerful tool, you have to learn it, and this article was not the right place to put a language tutorial.

I thank you for your feedback and I've updated the post to explain that the intent is to writeba separate blog post explaining how this code works.

Given a function F that accepts an argument x and returns y, its inverse is another function which, when passed y will return x.

For dyadic functions, the incerse argument is always the right side one.

So negation is its own inverse.

So the inverse of 2+ is indeed subtraction of 2.

It does make a difference on some operating systems. Specifically DOS (and by extension, Windows, at least sometimes. As usual with Microsoft it gets complicated).

When enabling text mode transfers in these systems, newlines gets translated from LF to CRLF on the DOS side.

Many array languages do have this issue. To be precise, the issue is that the simple straightforward approach tends to compute a lot more than necessary.

It's of course possible to do it in a different way to deal with that issues but those solutions can be a bit longer and less pretty.

The APL dialect I'm working on (Kap) solves this problem in many cases by delaying the computation until the result is needed, which means that you can write the code using the straightforward approach but still avoid computing results that will be thrown away.

There is no need to have a specific keyboard. The actual solution depends on what APL you're using, but the principle is the same. The various symbols are available on the regular keys, and you use some way to indicate that you want the APL symbol rather than the regular symbol.

Dyalog has two different IDE's the support this. Ride uses backquote by default, while the windows IDE uses control.

Kap uses backquote in all its interfaces. Here's what it looks like in the web version: https://kapdemo.dhsdevelopments.com/clientweb2/

Likewise, BQN does the same thing, but uses backslash: https://mlochbaum.github.io/BQN/

When using GNU APL there is an Emacs mode available that provides an input method.

So the long story short, you should be able to get going with any array language without getting any special keyboard.