The Notation: Ken Iverson Centenary

There are lies, there are damn lies, and there are benchmarks.

Also, consider how few comments there are in this thread. What does that usually mean on HN?

Arthur's new company, Shakti, has some of the benchmarks they've talked about[1][2].

[1] https://shakti.sh/

[2] https://shakti.sh/benchmark/about?eula=shakti.com/license

My guess is that K is faster in some situations because the nature of the language requires programmers to use the most direct solution to a problem, getting all the code and data in the cache. C being a verbose language makes this harder to achieve, unless you spend some time to optimize the memory layout of your data.

He wrote solutions for Shootout (predecessor to that Debian page) problems a few years ago; a lack of k in benchmarks is not due to a lack of k being volunteered: http://www.kparc.com/z/comp.k

k is really fast. Half of the things on the Shakti mailing list are just Arthur getting really excited about how significantly he's beating x or y or z in performance and giving numbers for it. `grep`ping it now I see 40 in half a year that explicitly contain the word "benchmark," though not all of these are comparing to other things (some are just comparing to different k releases), and there are more comparisons without that word.

Arthur doesn't work at Kx anymore, by the way. He's at Shakti now. Shakti has a different (but still draconian/non-(A)GPL) license. It probably doesn't have the benchmark clause, but I don't care enough to check (I prefer J to k and don't have a proprietary k on my system).

What would be interesting, and perhaps informative, if is we could share our some of our favorite k programs and then people could try to write faster implementations in C.

I like benchmarks that I can easily run on any computer myself.

For me, a major part of k's appeal is the (original) author's appreciation for small interpeter size and language terseness. Generally, I think k will always beat C, and probably any scripting language you can think of, in that department.

The issue of verbosity is so polarising amongst the vocal programmers who comment online that even if k were faster than whatever language (and free, open source, etc.), I would bet many of them still would reject the idea of using it.

I think you're missing the point. K certainly isn't faster than C. If you have a C guru, they should always be able to write faster code than K.

The difference is it should be a lot easier for someone like me (not a C guru) to write a K program that does something useful. I'll also be able to see the whole program as it will likely be a few lines long. If I wrote some C code, it would take me forever and take forever to debug. I see this as similar to any scripting language (Ex: Python).

> How true is this? I hear this claim a lot but haven't seen any real benchmarks ...

I think you're trying to read into the statement something other than Arthur meant; The last part of the quote is just as important as the first. Allow me to try and explain.

It's pretty easy for an experienced C programmer to beat K at some things, for example:

    int i,n;for(i=n=0;i<1000000;++i)n+=i;

is faster (with gcc -O2) than the "equivalent":

    +/!1000000

which is more literally:

    int N=1000000;*a=malloc(N*sizeof(int)),i;
    for(i=0;i<N;++i)a[i]=i;
    int n=a[0];for(i=1;i<N;++i)n+=a[i];
    free(a);

but even an experienced C programmer will experience some fatigue trying to convert a K program to C in this way, and the K implementation is certainly faster than a literal translation (largely because it doesn't use malloc, but yes also because of careful vectorisation and parallelising of many of the operators).

It's my experience this difference adds up faster than anything else, and that's why a 20kloc C++ implementation of a HIBP checker was beat 10x by a 5-line k/q solution:

https://news.ycombinator.com/item?id=22467866

But make no mistake, I don't use k because it's fast, but because it makes me fast: five lines of code ain't squat to get right over 20k lines, so I'd prefer the k solution even if it were "only" just as fast as someone's C++ solution.

It does help tremendously though, that it's usually much much faster.

I think the notation is not the only difference in J. I believe that tacit programming is one of the improvements proposed by J, but I might be wrong.

It's also easier to do scripting with J since you can just use files. The (Dyalog) APL workspace infrastructure is very powerful but a bit heavy to use when all you want is a simple script. Of course, large banks and Fortune 500 companies seldom use just simple scripts, so that makes sense I guess.

Control flow in APLs is mostly imperative, and with explicit code, /i.e./ code that mentions variables, you're effectively writing procedural code. I'd say that APLs are harder to get started with, but easier to use right. With things such as Numpy, you need to know lots of things about the API that might change without warning. With APL, you learn the primitives and you're off to the races. The downside is that less popularity means far fewer library efforts.

Dyalog APL has a safety blanket of procedural programming[1], it's another strange aspect of APL and the internet that it seems almost completely overlooked - unremarked upon and never discussed. e.g. this is roughly a prompt-for-username and validate-username code:

    ∇result←verifyUserName userName

     isValid←1
     message←''

     :If (userName≡'')∨(8<≢userName)
         message←⊂'Please enter a name between 1 and 8 characters long'
         isValid←0
     :ElseIf ' ' ∊ userName
         message←⊂'Please enter a name with no spaces'
         isValid←0
     :EndIf
    ∇result←isValid message



    ∇userName←getUserName
  
      nl←⎕UCS 13 10   ⍝ carriage return, newline
  
      :Repeat
          ⍞←'Enter a username: ',nl
          newName←⍞       ⍝ Read from keyboard input
      
          nameIsValid message←verifyUserName newName
      
          :If 0≡nameIsValid
              ⍞←message
          :EndIf
      
      :Until 1≡nameIsValid
    ∇userName←newName

It's unexciting compared to the dense showoffy codegolf APL which is normally posted on the internet, and what you still don't get with it is things like `string.Length` or `or` or `Console.WriteLine()` etc. That is, procedural/imperative APL looks like APL and doesn't save you from having to know APL symbols or execution model. But it could save you from having to wrangle some weird mathematical dodge around a simple :If/:Else branch or trying to use ⍣ when you really just want to write :For i :In 2 4 6 8 10

It has an OOP/Class system as well, but that doesn't save you from having to know APL either.

[1] I don't think NARS2000 does, and I'm not sure about the bigger IBM / Sharp APLs. I don't think J or K have.