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.
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.
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...
Very nice! I like the readability-- not sure if thats just indicative of your style or the language, and the map construct is also nice. I don't remember any off-the-shelf map construct, at least not in Dyalog.
Dyalog doesn't have an explicit implementation for maps, but you get the same effect with column-major table stores and the implicit hashmap backing of the search-like primitives [0]. E.g.
keys←'foo' 'bar' 'baz'
values←1729 42 0.5721
indexOf←keys∘⍳ ⍝ The dyadic ⍳ here is what builds a hashmap
where ¯1 is just the value you want missing keys to map to. If you're okay erroring in that case, it can be left off. For map "literals", a syntax like the following gets you there for now:
k v ←'foo' 1729
k v⍪←'bar' 42
k v⍪←'baz' 0.5721
In version 20, proper array literal notation [1] is landing, where you'll be able to do:
keys values←↓⍉[
'foo' 1729
'bar' 42
'baz' 0.5721]
In practice, I suspect that this ends up being more ergonomic than actual maps would be in the language. That said K is all about maps and the entire language is designed around them instead of arrays like APL. IIRC, there was also some discussion on the J forums a while back about whether or not to have explicit hashmap support [2].
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.
"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.
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:
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.
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...