I am new to array languages, but have really enjoyed the experience of using them so far. I have consistently had much better experiences following the tutorials and doing sample problems in most of the array languages I have tried compared to other languages.
I love being able to see an example and type it my editor in without having to switch back and forth a bunch of times because I forgot some syntax by the time I switched windows. Your data is a ball of dough and you can knead it into whatever shape you want with the primitives.
Even if I don't know what the symbols are, its still easier to remember because its less stuff you have to type in. Its a little bit of work up front to learn some of the verbs (why not use Anki and some mnemonics), but you really do have so much more room to think about the problem in your head. The compression is like a cool breeze on a hot summer day.
For those used to traditional language syntax, anything in the APL family is like Chinese to someone who only knows Latin-family natural languages. It's always amusing to see all the reaction comments when APL/J/K is posted here.
I kinda liked J but my gripe with it is that I have to learn it almost from scratch every time I try to use it.
The tacit syntax is too idiosyncratic (I always forget the different types of verb trains) and I'm not entirely convinced it actually helped me as a "tool of thought" (but it might just be me not sticking with it long enough to be able to decode The Matrix).
I wish multidimensional arrays were a first-class citizen in my main languages though.
I felt compelled to make a comment about that last week[1]; I stopped thinking of it like "APL is a tool for thought [and nothing else is]" and started thinking of it like the Sapir-Whorf idea; all programming languages and mathematical notations are tools for thought and we don't normally talk about them like that. Their designs promote/encourage/ease some ways of thinking about problems and reveal some patterns in the data and the algorithms, and on the flip side by making design choices they necessarily demote/discourage/frustrate other ways of thinking and obscure some patterns.
It's not just that Go has Goroutines in it as a technical feature, it's that having a first class way to express that feature encourages Go developers to think about solving problems in terms of Goroutines. A bit like "if the only tool you have is a hammer, every problem starts to looks like a nail". But we still go down the direction of making a kitchen-sink language which has a bodge of half-implemented mismatched features from different areas wedged awkwardly into its syntax, and then saying "this company only does Java" or "only uses C++" instead of making smaller simpler tools that fit particular problems and working on ways to learn about them and integrate them.
> "I wish multidimensional arrays were a first-class citizen in my main languages though."
It has not helped you but you wish you had access to it because it's changed the way you think? Same; it has changed the way I think about bulk-transforming arrays of data, and using intermediate array structures, and thinking it's good to have an interpreter layer which transforms a whole array using SIMD/vector extensions instead of a loop which does individual non-SIMD tests on items so it can exit part way through the array to "save time".
> I'm not entirely convinced it actually helped me as a "tool of thought"
This is so real. I had the same issue and was only able to break through by collabing with professional APLers. It's very non-ideal for the curious autodidacts.
I'd love to share, hone, and flesh out what the Tool of Thought looks like in practice with interested others. For anyone here to whom that sounds fun, feel free to reach out. Contact info is in my profile.
You don't really often need an array language, just like you don't really often need regexes.
When when you have a problem that perfectly fits the bill, they are very good at it.
The problem is they are terrible at everything else. I/O, data validation, manipulation strings, parsing, complex logic trees...
So I feel like just like regexes, there should be an array language parser embedded in most languages, that you opt in locally for just this little nudge.
In Python, it would be nice to be able to "import j" like you "import re" in the sdlib.
The entire J code base, including utility scripts, a console, a stdlib and a regex engine, is 3mb.
I don't know if you're aware that there's a formal analogy between matrix operations and regex operations:
Matrix vs Regex
--------------
A+B with A|B
A*B with AB
(1 - A)^{-1} with M*
To make the analogy between array programming and regex even more precise: I think you might even be able to make a regex engine that uses one boolean matrix for each character. For example, if you use the ASCII character set, you'd use 127 of these boolean matrices. The matrices should encode transitions between NFA states. The set of entry states should be indicated by an additional boolean vector; and the accepting states should be indicated by one more boolean vector. The regex operations would take 1 or 2 NFAs as input, and output a new NFA.
I suspect the same regarding the analogy with regex, but I still haven't finished learning an array language. Do you know what you'd use an array language for?
One cool thing about J (or any APL language) is that LLMs absolutely cannot write J code, so the whole thing feels like a breath of fresh air from the usual LLM slop
I think this is the official J implementation as it stood in 1990 when this paper was originally published, it kept being developed but not this document which describes it. Perhaps someone else knows these details?
There is a relatively recent episode of the ArrayCast array language podcast with Henry Rich who is the primary maintainer and developer of J, talking about new features: https://www.arraycast.com/episodes/episode104-j96
Click on the show notes and there are links to previous episodes with him, talking about the J engine implementation, updates in J 9.03, threading and faster bignum calculations in J 9.04, updates in J 9.5, his views on tacit programming, etc.
That is an alarming statement, especially as the first line on the site.
> Words are expressed in the standard ASCII alphabet. Primitive words are spelled with one or two letters; two letter words end with a period or a colon. The entire spelling scheme is shown in the system summary. The verb ;: facilitates exploration of the rhematic rules. Thus:
> The source code for word formation is in the files w*.c. The process is controlled by the function wordil (word index and length) and the table state. Rows of state correspond to 10 states; columns to 9 character classes. Each table entry is a (new state, function) pair. Starting at state S, a sentence is scanned from left to right one character at a time; the table entry corresponding to the current state and character class is applied.
"The reader is assumed to be familiar with J and C."
And anyone reading this at the time would have been familiar with APL as well.
It's not intended to be beginner friendly. Like J, and like the original J dictionary, the values here are brevity, compactness, and essence. There is plenty of other more beginner friendly material on J out there.
"Ken Iverson - The dictionary of J contains an introductory comment that J is a dialect of APL, so in a sense the whole debate is Ken's fault! He is flattered to think that he has actually created a new language."
That example is what got me to start learning J which I have always found to be unreadable, much prefer my array languages to have their non-ascii symbols. A few nights playing with J and learning was enough to not be completely lost and able to make some progress, but it is still a challenge. When it says it "describes and implementation of J" it is not kidding, it describes the implementation and goes no further. Both the article and the code stick to this sort of terse and very concise language.
This kind of comment mystifies me. What’s the value of it, what are you trying to say? Are you proud of your ignorance, or trying to ridicule, or what? What is alarming about coming across something you’re not familiar with? J and APL have Wikipedia articles that serve as a basic enough introduction. Why not educate yourself first?
I have to admit I got to https://www.jsoftware.com/ioj/iojATW.htm and seriously considered if the site is just pulling my leg. I think they're being sincere but I can't be 100% sure.
As someone with enough math background to be comfortable with one letter variable lanes and terse notation, this is still needlessly annoying to me because of the removal of almost all non-essential whitespace and grouping related definitions together on the same line instead of putting them on separate lines, and then using blank lines to separate "paragraphs".
I get it and I've heard it before, it's supposed to make it easier to fit more on one screen which is supposed to reduce cognitive burden. You are free to like what you like of course, but it just makes everything look like a jumble.
And even in a math context, I get frustrated if there's no simple glossary or surrounding prose to describe what's going on. Very few people write math this way, as a dense jumble of symbols. Even in the context of written mathematics, this is a very unusual style. I feel like J fans talk about it as if it's a totally normal thing to do if only you knew a little more math.
> Even in the context of written mathematics, this is a very unusual style. I feel like J fans talk about it as if it's a totally normal thing to do if only you knew a little more math.
Yes, it's very unusual. I think the argument is more that there is a tradeoff, that "inflation" (whitespace, long names, multiple classes/files/etc) has a cognitive cost too even it it's more approachable, and that this other alien-seeming style can work very well for some people. There's a lot to love in the APLs even you ultimately don't buy the fanboy arguments, if only for the lessons of just how different the world can be.
I am new to array languages, but have really enjoyed the experience of using them so far. I have consistently had much better experiences following the tutorials and doing sample problems in most of the array languages I have tried compared to other languages.
I love being able to see an example and type it my editor in without having to switch back and forth a bunch of times because I forgot some syntax by the time I switched windows. Your data is a ball of dough and you can knead it into whatever shape you want with the primitives.
Even if I don't know what the symbols are, its still easier to remember because its less stuff you have to type in. Its a little bit of work up front to learn some of the verbs (why not use Anki and some mnemonics), but you really do have so much more room to think about the problem in your head. The compression is like a cool breeze on a hot summer day.
For those used to traditional language syntax, anything in the APL family is like Chinese to someone who only knows Latin-family natural languages. It's always amusing to see all the reaction comments when APL/J/K is posted here.
I kinda liked J but my gripe with it is that I have to learn it almost from scratch every time I try to use it.
The tacit syntax is too idiosyncratic (I always forget the different types of verb trains) and I'm not entirely convinced it actually helped me as a "tool of thought" (but it might just be me not sticking with it long enough to be able to decode The Matrix).
I wish multidimensional arrays were a first-class citizen in my main languages though.
> "tool of thought"
I felt compelled to make a comment about that last week[1]; I stopped thinking of it like "APL is a tool for thought [and nothing else is]" and started thinking of it like the Sapir-Whorf idea; all programming languages and mathematical notations are tools for thought and we don't normally talk about them like that. Their designs promote/encourage/ease some ways of thinking about problems and reveal some patterns in the data and the algorithms, and on the flip side by making design choices they necessarily demote/discourage/frustrate other ways of thinking and obscure some patterns.
It's not just that Go has Goroutines in it as a technical feature, it's that having a first class way to express that feature encourages Go developers to think about solving problems in terms of Goroutines. A bit like "if the only tool you have is a hammer, every problem starts to looks like a nail". But we still go down the direction of making a kitchen-sink language which has a bodge of half-implemented mismatched features from different areas wedged awkwardly into its syntax, and then saying "this company only does Java" or "only uses C++" instead of making smaller simpler tools that fit particular problems and working on ways to learn about them and integrate them.
> "I wish multidimensional arrays were a first-class citizen in my main languages though."
It has not helped you but you wish you had access to it because it's changed the way you think? Same; it has changed the way I think about bulk-transforming arrays of data, and using intermediate array structures, and thinking it's good to have an interpreter layer which transforms a whole array using SIMD/vector extensions instead of a loop which does individual non-SIMD tests on items so it can exit part way through the array to "save time".
[1] https://news.ycombinator.com/item?id=46183808
You're probably aware of it, but if not: Uiua is much easier to understand in this regard.
> I'm not entirely convinced it actually helped me as a "tool of thought"
This is so real. I had the same issue and was only able to break through by collabing with professional APLers. It's very non-ideal for the curious autodidacts.
I'd love to share, hone, and flesh out what the Tool of Thought looks like in practice with interested others. For anyone here to whom that sounds fun, feel free to reach out. Contact info is in my profile.
Oh yea, J sources, the nightmare fuel :D
I usually show it to folks when it comes to code aesthetics. They end up in disbelief.
You don't really often need an array language, just like you don't really often need regexes.
When when you have a problem that perfectly fits the bill, they are very good at it.
The problem is they are terrible at everything else. I/O, data validation, manipulation strings, parsing, complex logic trees...
So I feel like just like regexes, there should be an array language parser embedded in most languages, that you opt in locally for just this little nudge.
In Python, it would be nice to be able to "import j" like you "import re" in the sdlib.
The entire J code base, including utility scripts, a console, a stdlib and a regex engine, is 3mb.
I don't know if you're aware that there's a formal analogy between matrix operations and regex operations:
To make the analogy between array programming and regex even more precise: I think you might even be able to make a regex engine that uses one boolean matrix for each character. For example, if you use the ASCII character set, you'd use 127 of these boolean matrices. The matrices should encode transitions between NFA states. The set of entry states should be indicated by an additional boolean vector; and the accepting states should be indicated by one more boolean vector. The regex operations would take 1 or 2 NFAs as input, and output a new NFA.I suspect the same regarding the analogy with regex, but I still haven't finished learning an array language. Do you know what you'd use an array language for?
Personally, to defer importing numpy until I can't anymore.
Sometimes you just need a little matrix shenanigans, and it's a shame to have to bring in a bazooka to get decent ergonomics and performances.
One cool thing about J (or any APL language) is that LLMs absolutely cannot write J code, so the whole thing feels like a breath of fresh air from the usual LLM slop
There is a reason most modern programming languages have not followed suit on this syntax... It's pretty thick.
last updated: 2000-06-23
I think this is the official J implementation as it stood in 1990 when this paper was originally published, it kept being developed but not this document which describes it. Perhaps someone else knows these details?
The current version is at https://github.com/jsoftware/jsource
There is a relatively recent episode of the ArrayCast array language podcast with Henry Rich who is the primary maintainer and developer of J, talking about new features: https://www.arraycast.com/episodes/episode104-j96
Click on the show notes and there are links to previous episodes with him, talking about the J engine implementation, updates in J 9.03, threading and faster bignum calculations in J 9.04, updates in J 9.5, his views on tacit programming, etc.
2.5 decades of rock solidness :)
The more I see these languages that have neither power nor readability, the more I appreciate C.
I think almost everyone is with you on readability, but I think it would be hard to make the case that it lacks power.
Indeed. Read some of the Project Euler discussions (after solving a problem). The J answers tend to be very short and very fast.
> J is a dialect of APL
That is an alarming statement, especially as the first line on the site.
> Words are expressed in the standard ASCII alphabet. Primitive words are spelled with one or two letters; two letter words end with a period or a colon. The entire spelling scheme is shown in the system summary. The verb ;: facilitates exploration of the rhematic rules. Thus:
> The source code for word formation is in the files w*.c. The process is controlled by the function wordil (word index and length) and the table state. Rows of state correspond to 10 states; columns to 9 character classes. Each table entry is a (new state, function) pair. Starting at state S, a sentence is scanned from left to right one character at a time; the table entry corresponding to the current state and character class is applied.I'm already lost, and this is the first example.
"The reader is assumed to be familiar with J and C."
And anyone reading this at the time would have been familiar with APL as well.
It's not intended to be beginner friendly. Like J, and like the original J dictionary, the values here are brevity, compactness, and essence. There is plenty of other more beginner friendly material on J out there.
It was the subject of quite some debate, see "Panel: Is J a Dialect of APL?" at http://www.jsoftware.com/papers/Vector_8_2_BarmanCamacho.pdf . Ken and Roger backed off this stance after witnessing the controversy.
"Ken Iverson - The dictionary of J contains an introductory comment that J is a dialect of APL, so in a sense the whole debate is Ken's fault! He is flattered to think that he has actually created a new language."
That example is what got me to start learning J which I have always found to be unreadable, much prefer my array languages to have their non-ascii symbols. A few nights playing with J and learning was enough to not be completely lost and able to make some progress, but it is still a challenge. When it says it "describes and implementation of J" it is not kidding, it describes the implementation and goes no further. Both the article and the code stick to this sort of terse and very concise language.
This kind of comment mystifies me. What’s the value of it, what are you trying to say? Are you proud of your ignorance, or trying to ridicule, or what? What is alarming about coming across something you’re not familiar with? J and APL have Wikipedia articles that serve as a basic enough introduction. Why not educate yourself first?
Me too, but
> This document describes an implementation of J in C. The reader is assumed to be familiar with J and C.
I have to admit I got to https://www.jsoftware.com/ioj/iojATW.htm and seriously considered if the site is just pulling my leg. I think they're being sincere but I can't be 100% sure.
Not a joke, and a famous piece of J lore!
There have a been at least a couple attempts I've seen posted here of blog posts breaking down the code in a beginner friendly way. One I dug up is: https://blog.wilsonb.com/posts/2025-06-06-readable-code-is-u...
Related: https://needleful.net/blog/2024/01/arthur_whitney.html
As someone with enough math background to be comfortable with one letter variable lanes and terse notation, this is still needlessly annoying to me because of the removal of almost all non-essential whitespace and grouping related definitions together on the same line instead of putting them on separate lines, and then using blank lines to separate "paragraphs".
I get it and I've heard it before, it's supposed to make it easier to fit more on one screen which is supposed to reduce cognitive burden. You are free to like what you like of course, but it just makes everything look like a jumble.
And even in a math context, I get frustrated if there's no simple glossary or surrounding prose to describe what's going on. Very few people write math this way, as a dense jumble of symbols. Even in the context of written mathematics, this is a very unusual style. I feel like J fans talk about it as if it's a totally normal thing to do if only you knew a little more math.
> Even in the context of written mathematics, this is a very unusual style. I feel like J fans talk about it as if it's a totally normal thing to do if only you knew a little more math.
Yes, it's very unusual. I think the argument is more that there is a tradeoff, that "inflation" (whitespace, long names, multiple classes/files/etc) has a cognitive cost too even it it's more approachable, and that this other alien-seeming style can work very well for some people. There's a lot to love in the APLs even you ultimately don't buy the fanboy arguments, if only for the lessons of just how different the world can be.
I think this seems insane from programmer land, but quaint from pure math land.
(I say this as someone who got filtered by pure math!)