OT, but for months already, Googling for "ngn/k" also displays a totally non-sensical calculator result, with no apparent way to report, like:

1 Nigerian naira / Boltzmann constant = 1.75931815 × 10^20 m^-2 kg^-1 s^2 K U.S. dollars

Is there any summary of what's changed between K versions, or their lineage, for someone who's not "K-fluent" but a tiny bit familiar with array languages? What changed between K6, 7, and 9?

Since Kx is the proprietor of the main toolchain I assume such any such description would be more of an oral history rather than a technical document with a changelog, but I'm curious either way!

EDIT: There is a wiki page for this but it hasn't been filled out (yet) unfortunately. Sad trombone. https://k.miraheze.org/wiki/History

Hello, one of the maintainers of the wiki here. The major changes are generally divided into:

K2-K4

K5-K6

K7-K9

From my knowledge. Each group has the same general primitives and syntax, and major changes happen between those eras. Since K's design allows removal and addition of features, this is very hard to document. This, combined with Arthur Whitney's rocky relationship with documentation makes most sources of changes anecdotal. Most changes to primitives have been documented in the wiki's primitive pages. I'll have to summarize them in the history pages.

K4 has good docs, and K6 has a well-written manual on oK's repository. The rest are a fill-in-the-blanks game which have to be fished from archive pages and a lot of trial and error. K9, the latest one is still undergoing changes, but there are ongoing efforts to make tutorials in kparc/kcc and estradajke/k9-simples on github.

Theres also a version of K2, plus a PDF K2 reference manual and many example programs on nsl.com that are still available.

Back in 2002, I remember reading an article on kuro5hin where the author wrote: "I have heard rumors that there would be interest in opening up the language if there would be enough community response around it."

https://web.archive.org/web/20050621080857/http://www.kuro5h...

The source code for J7 is still available and it still compiles with only a few small edits:

https://web.archive.org/web/20161024144956/http://www.math.u...

People commenting on today's web like to make fun of the idea that anything about computing was "better" in the past (and they like to crticise C too), but just look at how portable this code was designed to be. Moreover, it is as old as the web itself and it still compiles today.

What is the longevity of something written in Javascript.

"Back in 2002..."

There was this on Slashdot:

"Arthur told me that he will open-source it, if there is sufficient interest. It is not very difficult to obtain the source from kx for your private use right now."

http://developers.slashdot.org/comments.pl?sid=28597&cid=307...

> What is the longevity of something written in Javascript.

I wrote some JavaScript in the late 90s which is still being used as part of a complex financial services value chain.

The idea that computing was better in the past is indeed silly, and completely ignores all the advances in understanding that have been made in the last many decades.

If your opinion is different, I can assure you that's due to ignorance.

Do Octave and R qualify as array languages? You could say that Python is not because Numpy is not part of the language.

It's hard to say how exactly to draw the line, but "array language" to an APLer usually means a language whose primary influence is APL. So these scientific languages that throw out most of the syntax are nearby but don't quite belong. From a practical standpoint the APL Wiki is centered on APL and exists to document the kind of niche material Wikipedia wouldn't cover, which is why there's nothing about these more mainstream languages currently.

I’d argue that array languages are far, far more limited than Python, to the point that the only thing you can reasonably do with them is processing array data (but they’re really good at it!)

Sounds like you're generalizing, based on... early APLs? NumPy? You could translate any BASIC code to, say, Dyalog APL easily without significant loss in fidelity. Different languages take different approaches but most modern ones (the ones that aren't just made to be calculators like Ivy) support either a generic functional or imperative style just fine.

K is inspired by Lisp, although you can't adapt that style directly because of the limited scoping rules: variables are either local or global, so a function can't see variables from containing functions. This means no closures, which K implementers consider a feature (I don't).

> This means no closures, which K implementers consider a feature (I don't).

having not touched K in about 15 years, when did this change? in k3:

    K 3.2 2004-09-23 Copyright (C) 1993-2004 Kx Systems
    LIN32 16CPU 15985MB ubuntu 0 EVAL  
    
      f:{a:x+1;{a+x}}
      g:f 1
      g
    {a+x}
      g 2
    4
      a
    value error
    a
    ^
    parse error

This comes as a surprise to me! I thought none of Whitney's Ks had closures—although I did neglect to mention that kuc and oK add them. Digging around and asking on the K Matrix/Discord I found some posts that suggest that the K3 form is very limited. My read of these is that functions can refer to variables in the immediately surrounding scope (only one level up), and their values will be copied in when the function is reached in the source code. So it would be equivalent to adding extra arguments to g and passing the variable values in that way. And it wouldn't allow the programmer to create object-like things and couldn't create reference loops requiring garbage collection.

See https://news.ycombinator.com/item?id=22572778, as well as https://chat.stackexchange.com/transcript/message/53999576#5... with more discussion on following days.

> their values will be copied in when the function is reached in the source code. So it would be equivalent to adding extra arguments to g and passing the variable values in that way. And it wouldn't allow the programmer to create object-like things and couldn't create reference loops requiring garbage collection.

That is definitely desirable! K (and kin) are fully referentially transparent and have value semantics. It would be bizarre and inconsistent to break referential transparency for closures.

No closures is one of the biggest pain points of k/q, it's incredibly limiting and frustrating. Besides that though, it's a wonderful language which allows you to solve problems very quickly with pretty good performance, assuming the problem is naturally vectorizable.

what was the point of the OP in this thread? I went to that page, but I can't make sense of what the page is all about!?!

https://kparc.com/

affero? dang.