Live data from Hacker News

Origins of J

github.com

61–70 of 76 posts

Re: Origins of J

#61
post #54

Earlier quoted context omitted.

true. only k is faster, easier to learn, and does the trick :) that said, i hold the view that mastering programming in an ultra-high level language such as APL or k does not absolve a computer programmer from learning lingua franca of our trade, which is due to k&r, will stay around for a very long time, and is called C. people who don’t know c are ok, only they are not involved in computer programming. their field…

Regarding k vs j, I will just say that ngn and I both agree that both the k and j array models are far more coherent than bqn. And that k is slow for multidimensional arrays ('mangle your data so it's fast in lists' is a poor response). And leave it at that :) C is a historical accident. Its existence makes sense in context. Its continued usage only makes sense in context of artificial social factors. There is no rea…

> C is a historical accident

strong words. in the context of civil aviation, for example, there is a fine line between incident and accident. in our context, an accident is COBOL/ABAP, which is, thank god almighty, not as ubiquitous as c, but sadly ubiquitous enough. JavaScript is a separate issue i won’t express an opinion on here :)

> k is slow for multidimensional arrays

this is true if we can agree on “k is slow for very multidimensional arrays of very small lengths”. yes, i wouldn’t recommend k as first choice for neural network inference, although it can be done and looks like a typical k program, that is pretty neat (proof below).

k on 32bit systems (notably, riscv and wasm32) have been a contention point between atw and his associates a few years ago, but a deal has been struck, and we now run k everywhere. the first bare metal risc-v build is about four years old now. and yes, it took some doing in the low level department.

before i forget:

https://kparc.io/k/#0%3A%22ml.k%22

https://kparc.io/k/#%5Cl%20ml.k

(end of proof)

Re: Origins of J

#62
post #47

Earlier quoted context omitted.

Since we are on the topic, I've thought about APLs a decent amount so here are some other resources/notes. I'm not an expert on this topic - I don't work with or research the language or anything. These probably are not good getting-started resources. There is a VM model for APL languages[1] which can make optimizations comparable to those made by CLP(FD). If you read about CLP(FD) implementations[2], you'll see oper…

> VM model for APL languages It's cute—but from my skimming a while ago fairly primitive. We can do much better with less effort using more general mechanisms. (Not a knock—it's a product of it's time—a lot of old compiler tech was not very good and even so remains unsurpassed.) > statically typed I in principle espouse a much more nuanced view than this, but in short: just don't.

> statically typed APL

that’d be a curious case indeed, why not, only it won’t be APL even remotely :)

Re: Origins of J

#63
post #39
post #32

Earlier quoted context omitted.

Please do. Although I'll probably never write C in that style, most of us here will probably learn a few things that will eventually prove useful. (And it probably will also serve as a historical document of a "skill"(?) that is apparently soon to be lost to obscurity...)

> please do now that i think of it, i already did just that once, only forgot. getting old sucks, and also forgetting things is a great skill i learned from atw. as he likes to say, “kelas, ignorance is bliss”. Here you go - all you ever need to know about how to read and write atwc: https://github.com/kparc/bcc/blob/master/d/sidenotes.md#styl...

> inequality x!=y is not used at all, because it is two chars. instead, we test with x-y, which holds true when operands differ

I think this is the line in the document that represents his coding style the most. Sacrificing legibility for plebs to save one character per comparison.

Re: Origins of J

#64

Earlier quoted context omitted.

As the author of an open source version ( https://www.timestored.com/jq/ ) I wish the same but I fear the time has passed. Two factors: 1. The other technologies are evolving to take parts of kdb+ that made it special quicker than kdb+ is evolving. See arrow / parquet / numpy / kafka, they each solve parts but kdb+ had them all 10 years ago in 2. The ratio of learners to advanced programmers has increased every year…

> Most beginners no longer want Most beginners never wanted that.

You are correct. I guess it's more accurate to say, most beginners are no longer forced to learn step by step from a book. Now they ask google/SO/chatGPT and use that if it works with a few tweaks. Kdb+ has very few core concepts, most of which since they are symbols are hard to google.

Re: Origins of J

#65
post #50

Earlier quoted context omitted.

I like J. Especially because it has a saner way to write it (it doesn't have to look like as if you accidentally forgot a null terminator in C strings, all the traditionally short identifiers have a long and understandable form). I feel like it's very regrettable that the superficial aspect of J (the very hard to read syntax) is standing in the way of some very nice ideas. To comment on mathematical notation. Before…

I, on the other hand, am dreaming of being able to use mathematical notation in my code. Sort of like what Fortran has helped with, only on a much larger scale.

As with a lot of things, some people may enjoy arduous and very low-yield process for all sorts of reasons. I, for example, like baking sourdough bread.

As with the bread, which comes out more or less comparable quality to what I can buy from the local grocery in exchange for much less effort, I get certain satisfaction from doing it myself. But, if I had to do this on an industrial scale (and I worked in a bakery, although very briefly), I'd want to kill myself if I had to deal with the same kind of process.

Math language is very similar in this regard. It's kind of nice, like a calligraphy piece. Sometimes it takes a master month to write just a few words in a visually appealing way, but if this was the expectation for everyday boring tasks, that'd be a completely different story.

Re: Origins of J

#66
post #50

Earlier quoted context omitted.

I, on the other hand, am dreaming of being able to use mathematical notation in my code. Sort of like what Fortran has helped with, only on a much larger scale.

As with a lot of things, some people may enjoy arduous and very low-yield process for all sorts of reasons. I, for example, like baking sourdough bread. As with the bread, which comes out more or less comparable quality to what I can buy from the local grocery in exchange for much less effort, I get certain satisfaction from doing it myself. But, if I had to do this on an industrial scale (and I worked in a bakery, a…

My impression has always been that it is mathematical notation that is indeed high-yield and low-effort. That’s why Fortran was/is successful.

Re: Origins of J

#67

Nice to see this getting some attention again. I hope some people venture out to learn about the actual J language: https://code.jsoftware.com/wiki/Guides/GettingStarted For what it's worth, I've also studied this code a bit. This repo has an annotated and (somewhat) reformatted version of the code: https://github.com/tangentstorm/j-incunabulum

J is really great. I spent some time last year playing around with it, Dyalog APL, and some other new array languages like BQN.

I was extremely impressed by the breadth of integrations into different ecosystems that the J community had created (like R and the web tech).

Using the language reminds me of using Common Lisp. There are a lot of things that seem odd now, like how you define new words (i.e. functions), how namespaces work, or how the FFI/system calls work (i.e. !: ) [1]. Kind of like how in CL things are named "mapc", "mapcar", "mapcan", etc. Both kinds of quirks come from the fact that these people were really innovating in new frontiers, and Ken Iverson and Roger Hui just kept on developing their ideas.

[1]: https://code.jsoftware.com/wiki/Vocabulary/bangco for how it works and https://code.jsoftware.com/wiki/Vocabulary/Foreigns for what you do with it.

Re: Origins of J

#68
post #39

Earlier quoted context omitted.

> please do now that i think of it, i already did just that once, only forgot. getting old sucks, and also forgetting things is a great skill i learned from atw. as he likes to say, “kelas, ignorance is bliss”. Here you go - all you ever need to know about how to read and write atwc: https://github.com/kparc/bcc/blob/master/d/sidenotes.md#styl...

> inequality x!=y is not used at all, because it is two chars. instead, we test with x-y, which holds true when operands differ I think this is the line in the document that represents his coding style the most. Sacrificing legibility for plebs to save one character per comparison.

> represents his coding style the most

i agree that atw’s inequality test is a bit cheeky, but like everything else it is a matter of habit. a convention. eventually you just begin to see what is subtraction and what is comparison.

here’s another classic example of the same effect:

x=x+1

makes perfect sense to everyone, right?

wrong. to some, the right answer is “no, they are not”.

Re: Origins of J

#69
post #66

Earlier quoted context omitted.

As with a lot of things, some people may enjoy arduous and very low-yield process for all sorts of reasons. I, for example, like baking sourdough bread. As with the bread, which comes out more or less comparable quality to what I can buy from the local grocery in exchange for much less effort, I get certain satisfaction from doing it myself. But, if I had to do this on an industrial scale (and I worked in a bakery, a…

My impression has always been that it is mathematical notation that is indeed high-yield and low-effort. That’s why Fortran was/is successful.

> math notation is indeed high-yield and low-effort

low-effort is perhaps “your mileage may wary”, as they say :) but the yield per square inch of paper does indeed make math the most powerful and expressive language known to humans. On that note, Ken Iverson was very concerned that tons of mathematical symbolic conventions and speak overlap and conflict with each other to an obscene degree. As we all know, that little book he wrote on this very subject eventually got him a Turing award when people finally realized what he did there.

That said (and please no offense APL and typography fiends who are reading this) a considerable portion of the funny APL chars was a hard compromise dictated by economics and physics of IBM Selectric typeball.

With that in mind, if you take a fresh look at the original APL charset, you will see that much of it is stone-stupid overtypes of two ASCII chars.

Why? Because IBM, that’s why. El Cheapo.

Re: Origins of J

#70
post #37
post #33

Earlier quoted context omitted.

> it is not. this style is extremely regular, very readable and writable, and escapes a whole galaxy of typical C blunders. i can expand on that if you wish. Please do! I'd like to learn. If you can expand on this in the README section as well that would be great.

> README good idea, why not for a more throw-me-in-the-water introduction, here are my notes on another famous public domain release from atw. some remarks are specific to the codebase, but essentially it is a general introduction to atwc: https://github.com/kparc/bcc/blob/master/d/sidenotes.md and here’s a less involved way to get lit: https://github.com/aaalt/altc

Awesome, I'm checking these out. Thanks!
Post reply on HN