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'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 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?
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.
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.
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.
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
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.
There is a reason most modern programming languages have not followed suit on this syntax... It's pretty thick.
> 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.
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!)