An Implementation of J (1992)
Key topics
The 1992 implementation of J, a programming language, has sparked a lively debate about its relationship to APL, with some commenters finding it "alarming" that the site describes J as a dialect of APL. However, others point out that the document assumes familiarity with J and C, and that the connection to APL was well understood at the time. The discussion reveals a fascinating divide between "programmer land" and "pure math land," with some appreciating J's quirkiness and others finding it unreadable. A notable thread of comments highlights the complexity of J's history and the ongoing efforts to make its code more accessible.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
2h
Peak period
26
0-12h
Avg / period
5.5
Based on 44 loaded comments
Key moments
- 01Story posted
Dec 13, 2025 at 7:34 PM EST
20 days ago
Step 01 - 02First comment
Dec 13, 2025 at 10:04 PM EST
2h after posting
Step 02 - 03Peak activity
26 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 19, 2025 at 3:34 PM EST
14 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
> This document describes an implementation of J in C. The reader is assumed to be familiar with J and C.
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
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 say this as someone who got filtered by pure math!)
"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."
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.
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.
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.
This is so real. I had the same issue and was only able to break through by collabing with professional APLers. 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.
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
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.
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.
> A+B with A|B > > AB with AB > > (1 - A)^{-1} with M
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 need 127 of these boolean matrices. The matrices should encode transitions between NFA states. Entry and acceptance states should be indicated by one boolean vector each. The regex operations would take 1 or 2 NFAs as input, and output a new NFA.
I think Iverson had a good idea growing language from math notation. Math operations often use one or few letters - log, sin, square, sign of sum or integral. Math is pretty generic, and I believe APL is generic as well.
April is this for Common Lisp: https://github.com/phantomics/april
Less to type in when writing code and less to look at when reading code
Terse languages are the best
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.
I usually show it to folks when it comes to code aesthetics. They end up in disbelief.