J one-page interpreter fragment (1992) | Hacker News Reader

J one-page interpreter fragment (1992)

code.jsoftware.com

76 pointsTomte33 comments

I tried to decipher this code some time ago and explain what it does and how - https://zserge.com/posts/j/

There's a ChatGPT attempt in https://news.ycombinator.com/item?id=34053932 .

> I tried to decipher this code

Thus proving it's horrible, and probably underhanded, code.

This gem comes up semi-regularly on HN; previous thread (with 43 comments): https://news.ycombinator.com/item?id=25902615

I know Whitney's style is a strict no-no, but it's beautiful how he regards C as a pliable material, rather than as a hard tool with standard modes of use, and uses it to define his own rudimentary DSL to build J on top of it.

My attitude is, on the one hand, reverence for such a fantastic intellectual feat, but on the other hand, annoyance that it's so opaque and difficult.

It's sort of like performance art (very well-paid performance art) rather than something mere mortals could learn and use.

> It's sort of like performance art (very well-paid performance art) rather than something mere mortals could learn and use.

If I were to be flippant, I would just say "not with that attitude!" But, mere flippancy being (rightly) not welcome here, I would also point out that all code is opaque and difficult to people who haven't learned how to read it. I think this kind of code should be taken, not as absolutely unintelligible (elsethread at https://news.ycombinator.com/item?id=34052034, zwerge posted a link to their dissection of it)—after all, part of the beauty of coding is that we all have access to a source of absolute truth (the code does what the compiler says it does)—but as either a fun diversion (my personal perspective) or as a goal. If making the code-reading part of your brain fluent in this sort of code is something to which you aspire—and there's no reason you should, but also no reason you shouldn't—then you can do it, with lots of patience!

> making the code-reading part of your brain fluent in this sort of code [...] lots of patience

I've not seen attempts to aid learning of basic skills for reading diverse coding styles. The space is large, from "eyeball abstraction" over "code is 90% repetition and boilerplate", to APLish "DO Repeat Yourself! At every callsite! With variations! ... each is like 4 characters", to terse lambda "code is documentation for humans, and only secondarily executable", to ... . There are skills involved with reading each style. And non-obvious tradeoffs to use. But even within individual styles, aid seems more "write and read a lot of code, and you'll eventually get the hang of it", and less "here, let me break down for you what I'm doing, what skills I'm using, when I read this". Perhaps there's some "live coding^H^H^He reading" on yt? Or how about an interviewer pair-reads code with a language expert?

While linters trending increasingly strict, towards canonical representation, raises hope for the old dream of AST-based coding, it does crush an axis of expressive power, for better and worse.

Hmm, I wonder if one could generate an ML training corpus to answer "explain what this bit of code here is doing and why"? Or perhaps, "create a minimum-ink compressed summary of these files"? Or even aspire to "rewrite this Java code in the style of APL"? :P (Ha - further down this page, ChatGPT https://news.ycombinator.com/item?id=34053932 )

At risk of being overly pedantic, I have to point out that you quoted my conclusion (which is based on my attitude), my attitude is, as I said, an unsettling mixture of reverence and annoyance.

I'm actually pretty eager to learn and use what you might call the Array Paradigm. Here's a comment thread from this summer: https://news.ycombinator.com/item?id=31380292 Some good info surfaced, and you can see for yourself how excited I got. :) Anyway...

> all code is opaque and difficult to people who haven't learned how to read it.

Sure, but there's a difference between, say, Logo and J in terms of available educational materials, eh?

My complaint isn't that the array languages are particularly hard (they're not), it's that they are obscure.

( "elsethread" I love it! I'm going to use that I think. Cheers! )

In the previous thread, somebody asked: is there a lisp written in j? I wrote one - https://github.com/moon-chilled/j/blob/master/lisp/lisp.ijs. It includes proper mutation and a 7-line gc to take care of the cycles (sweeping and compacting).

But is there a j-like written in a lisp? I once made a mini-implementation that translated to numpy, but that's cheating.

'April' is an APL embedded into Common Lisp

Very cool! Thanks for writing/showing.

ChatGPT takes a crack at explaining it here https://medium.com/@solarbreeze69/chatgpt-explains-arthur-wh...

It looks like ChatGPT has been reading up on this code already! I'm not sure how it would have figured out what the fields of the `A` type are for without reading another explanation.

"You shouldn't use gets(), it's dangerous and deprecated".

Heh.

No, I realize the code is from 1989 and gets() was not on the hitlist by then.

What is not so clear is if the first the author wrote after studying the posted code for a week, looked the same? I mean even in 1989 this must have been a bit controversial/extreme[1], but there is no mention of those aspects. I'm not sure what is being communicated, really.

[1] I don't think I had started writing C for real by then but if this was Basic code I would have screamed at it. :)

I’m pretty sure Roger Hui’s implementation of J was written in roughly Arthur’s style

Which is roughly "let's first create an domain-specific APL-core rudimentary language from C, and then write proper APL-family language using this DSL". Ken Iverson didn't write in C.

This is by Arthur of k and shakti (k9) fame; most his code is definitely not standard practice. His c code is still very terse etc. You get used to it.

I'd been using C for a couple years in 1989, and "never use gets()" was advice that had reached me. I don't remember how widespread that was.

The style was just as unusual at the time, though I think there was more variety in style generally, and lower standards most places (most of us didn't have open source or internet discussion to learn from).

An Implementation of J – Incunabulum (2008) - https://news.ycombinator.com/item?id=28491562 - Sept 2021 (16 comments)

J one-page interpreter fragment (1992) - https://news.ycombinator.com/item?id=25902615 - Jan 2021 (43 comments)

J one-page interpreter fragment (1992) - https://news.ycombinator.com/item?id=14463874 - June 2017 (26 comments)

The J Incunabulum (Remembering Ken Iverson, 2004) - https://news.ycombinator.com/item?id=12654054 - Oct 2016 (1 comment)

Arthur Whitney's One-page Interpreter (1992) - https://news.ycombinator.com/item?id=8533843 - Oct 2014 (50 comments)

I feel like there have surely been threads?

I find J quite interesting, in fact I'm trying (and succeeding up until day 15) to solve Advent of Code in it. This with having no real experience in this language apart from trying to learn it some years ago.

There are plenty of lessons to be learned from languages that are not "the norm". Having more ways to think about the problems helps.

Unless I’m missing something devious hidden in the dense terseness, it seems every single execution of the REPL leaks memory (that call to `wd` in the print/execute loop mallocs memory but never frees it). I guess this was so much a proof-of-concept that Arthur Whitney thought even rudimentary memory management was unimportant.

It’s also amusing that he chooses to spell out “noun” and “verb” but nothing else. Maybe his brain got tired by that point and could no longer remember the meaning of so many single-letter variables and functions.

> I guess this was so much a proof-of-concept that Arthur Whitney thought even rudimentary memory management was unimportant.

That seems reasonable to me. The way I understand the story, Whitney wrote this as a "sketch". Its purpose was not to be an industrial strength interpreter, but to communicate a few key concepts so another skilled programmer (Roger Hui) could pick it up and run with it.

I still refuse to believe that anyone writes C like this.

This is the output of an obfuscator, and the refusal of the J people to admit it makes them untrustworthy.

It looks like it, but looking at the code more closely, I do not believe this to be the case; I think it was deliberately written like this, and obfuscation might not be its primary intention.

I studied it a long time ago by incrementally rewriting bits into more my style, adding comments, as I understood the bits. It is a coherent style which I wasn't really tempted to imitate. I do admire the author for figuring out what he likes and sticking to it.

Similarly, I refuse to believe that anyone might doubt that some people actually write code like this.

Yeah, some refusals look like failures of imagination.

J is "tool for thought" because there is a relatively - comparing to other languages - short distance between a thought and its implementation in the language. When e.g. somebody writes Java, her fingers used to type "for(int i = 0; i < ...; i++) {" without much thought. In J this whole construction is just hidden inside the language.

> J is "tool for thought" because there is a relatively - comparing to other languages - short distance between a thought and its implementation in the language.

Only for some limited kinds of thoughts, to be sure.

Reply on news.ycombinator.com