3 ms·

J and K are different languages. They are similar in that both use standard ascii keys and are in the APL family of languages. The author of K "Arthur Whitney"

J and K are different languages. They are similar in that both use standard ascii keys and are in the APL family of languages. The author of K "Arthur Whitney" wrote part of a prototype with Roger Hui for the J interpreter or so I think. The primary author of J is none other than Ken Iverson (the Turing award winner and designer of the original APL) who wanted a free version of APL for the masses where people wouldn't complain about the weird non ASCII APL symbols. It also primarily uses a tacit function train style of programming like data flow languages where you don't even necessarily need variables (pretty cool). This tacit coding style has since been added to Dyalog APL where you can see folks like Aaron Hsu build some pretty cool applications using it. I'd imagine K is more performant though than J and the source is famously small (just a few C files). J has a lot more stuff baked in like Qt support. They both have a database library Jd (for J) and Kdb+ (for K). Kdb+ is a fancy SSD based database which uses K and a SQL like DSL called Q. Its performance is pretty darn good and used in Finance. I don't know enough about Jd.

etatoby 8y ago
> [K's] source is famously small (just a few C files) Yes, but they look like this: https://github.com/tangentstorm/j-incunabulum/blob/master/ji.c https://github.com/tangentstorm/j-incunabulum/blob/master/ji... Call me crazy, but I'm wary of code written like this.
- 4thaccount 8y ago
  This comes up a lot in these discussions and I believe Arthur better understands 6 pages of code written like that than someone else can comprehend 30 pages of the equivalent idiomatic code. He writes APL/K for a living, so making the C fit closer makes more sense in my eyes as it matches his thought process better. I sympathize with hating scrolling in how it hurts your ability to see everything at once.
- rbonvall 8y ago
  I get the same gut reaction as you, but I tried reformatting the code a little bit and it's not _that_ terrible. From the very little APL I've learnt, I know that operators always have either one parameter (named ω) or two (named α and ω), and their inputs and outputs are always arrays. If you need to write a lot of such functions, it makes sense to define some macros to help you: #define V1(f) A f(w)A w; // create one-arg function #define V2(f) A f(a,w)A a,w; // create two-arg function #define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}} iota is the APL equivalent of Python's range function: V1(iota) { // Define one-arg function iota. I n = *w->p; // Get the value of the ω argument. A z = ga(0, 1, &n); // Allocate output array. DO(n, z->p[i] = i); // Assign increasing integers. R z; // Return the result. } The plus function adds two arrays: V2(plus) { // Define two-arg function plus. I r = w->r, // Get the rank of ω. *d = w->d, // Get a pointer to ω's data. n = tr(r,d); // Get tne size of ω's data. A z = ga(0, r, d); // Allocate output array. DO(n, z->p[i] = a->p[i] + w->p[i]); // Add corresponding values of α and ω R z; // Return the result. } Personally I cannot tolerate the lack of whitespace, but the APL guys are known to like to see their entire programs in one screenful. I can understand that some people like to write code like this.

etatoby 8y ago

> [K's] source is famously small (just a few C files) Yes, but they look like this: https://github.com/tangentstorm/j-incunabulum/blob/master/ji.c https://github.com/tangentstorm/j-incunabulum/blob/master/ji... Call me crazy, but I'm wary of code written like this.

4thaccount 8y ago
This comes up a lot in these discussions and I believe Arthur better understands 6 pages of code written like that than someone else can comprehend 30 pages of the equivalent idiomatic code. He writes APL/K for a living, so making the C fit closer makes more sense in my eyes as it matches his thought process better. I sympathize with hating scrolling in how it hurts your ability to see everything at once.
rbonvall 8y ago
I get the same gut reaction as you, but I tried reformatting the code a little bit and it's not _that_ terrible. From the very little APL I've learnt, I know that operators always have either one parameter (named ω) or two (named α and ω), and their inputs and outputs are always arrays. If you need to write a lot of such functions, it makes sense to define some macros to help you: #define V1(f) A f(w)A w; // create one-arg function #define V2(f) A f(a,w)A a,w; // create two-arg function #define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}} iota is the APL equivalent of Python's range function: V1(iota) { // Define one-arg function iota. I n = *w->p; // Get the value of the ω argument. A z = ga(0, 1, &n); // Allocate output array. DO(n, z->p[i] = i); // Assign increasing integers. R z; // Return the result. } The plus function adds two arrays: V2(plus) { // Define two-arg function plus. I r = w->r, // Get the rank of ω. *d = w->d, // Get a pointer to ω's data. n = tr(r,d); // Get tne size of ω's data. A z = ga(0, r, d); // Allocate output array. DO(n, z->p[i] = a->p[i] + w->p[i]); // Add corresponding values of α and ω R z; // Return the result. } Personally I cannot tolerate the lack of whitespace, but the APL guys are known to like to see their entire programs in one screenful. I can understand that some people like to write code like this.