An Implementation of J – Incunabulum (2008) | Hacker News Reader

An Implementation of J – Incunabulum (2008)

jsoftware.com

50 pointsdavegauer16 comments

The code won't compile on modern C compilers due to some antiquated syntax. https://github.com/tangentstorm/j-incunabulum has a translation that should work on modern compilers.

The original code is worth investigating if you're into CS archeology. J is as interesting of a language as Lisp and I was amazed by the tiny implementation. However, the original code is buggy and will crash on slightly malformed input.

For the ones that don't know, incunabulum is a book printed before 1501 [0].

I find the story behind incunabula really fascinating. Also, for what it's worth, incunabulum / incunabula sounds quite odd in Italian (it resembles some dirty words), and the few times it got mentioned here and there, most people don't know what it means and assume the worst.

[0]: https://en.wikipedia.org/wiki/Incunable

The Legend of The Hui[0] also digs into this code a bit in a silly way.

[0]:http://www.jsoftware.com/pipermail/chat/2020-March/008507.ht...

I did some APL coding like 40 years ago.... I did like it at the time, but this family of languages provokes WRITE ONLY coding style.... While you actively working on some code, it's ok... but when you come back to a code written couple of month ago or written by someone else you're pulling you hair out trying to understand it

I do statistical computing, and I very much disagree. My single-page J is much easier to read 6 mo later than my 500 loc R script.

anyone tried to compile it?

I'm getting this when trying to run it:

  $ cc main.c
  ... lots of warnings ...

  $ ./a.out 
  1
  
  1 
  2*2
  Segmentation fault (core dumped)

It doesn’t have *. What it has is listed in the declaration starting with “C vt[]”. Those are the names of verbs and the following lines give the function pointers for their monadic and dyadic uses.

It worked fine for me when I was careful to stay within what it actually supported, bearing in mind it’s a fast and rough implementation not something for production use.

It will run but it requires 32-bit pointers and 32-bit integers. And error handling is limited.

Why do these array programmers write C like this? It's an abomination.

They prefer to write in their language. And to do that, produce primitives, written in C, first, and then use those primitives according to their language, not C. So from C programmer standpoint it's awful C, from J programmer standpoint it's a good middle ground between wanting to write J and the underlying language possibilities.

I would love to see a J program written in a literate programming style (with the same terseness of code). Though I'm sure that idea seems like anathema to most of those people!

Edit: thanks very much to commenters below for showing how wrong I was to assume the above :)

There are many, many array programmers who choose to write in a literate style. Popular code examples written for toy challenges often tend to be smart one liners whose algorithms cannot be easily put in multiple lines, so they may look unreadable for people unfamiliar with the languages. A terse compact code style often works well with the language's design.

If you'd like some examples of traditionally literate array programming, you can see:

- tangentstorm's J streams: https://www.twitch.tv/tangentstorm

- tangentstorm's J repositories: https://github.com/tangentstorm?tab=repositories&q=&type=&la...

- Dyalog's APL repositories: https://github.com/orgs/Dyalog/repositories?q=&type=&languag...

Not at all anathema. Many array programmers are very big on code documentation. J has joxygen to generate html docs from comments and JOD which is a code dictionary system.

https://analyzethedatanotthedrivel.org/the-jod-page/

https://code.jsoftware.com/wiki/Vocabulary/Libraries

Some array programmers inspired by Arthur Whitney write code like this. I wouldn't call it an abomination per se, it's a specific style meant for a specific person. They find that way of writing C to be nice. It's somewhat popular among people who implement K-like array languages.

A usual result of using array languages is a want to have that same terseness in other languages. Array languages usually deviate from the style and aesthetic of general programming languages. It may be jarring to look at, but as with anything, a little experience with using them can go a long way with understanding why many people work with something so "unreadable".

It would make half-decent entry to The International Obfuscated C Code Contest though...

https://www.ioccc.org/

I think it's beautiful. You might prefer to read 20 pages of code. And, me too. But this is a puzzle, and it intrigues me, so I read a good quarter of this. If it was 20 pages long, I probably wouldn't have gotten that far

Reply on news.ycombinator.com