jsource

The current version is at https://github.com/jsoftware/jsource

Is this supposed to be a specific coding style or paradigm? I’ve never seen code written like this in real-world projects — maybe except for things like the "business card ray tracer". When I checked out Arthur Whitney’s Wikipedia page I noticed he also made the J programming language (which is open source) and the code there has that same super-dense style https://github.com/jsoftware/jsource/blob/master/jsrc/j.c

The one other example I know that morphs the language to that extent and to the detriment of readability by C programmers is the J interpreter[1,2]. But, once again, nobody (that I’ve read) claims it’s good or clear C. (Good C for those who speak J, maybe; I wouldn’t know.) For a way to morph C syntax that does make things better, see libmill[3]. [1] https://code.jsoftware.com/wiki/Essays/Incunabulum [2] https://github.com/jsoftware/jsource/tree/master/jsrc [3] https://250bpm.com/blog:56/

Try the J source code, like https://github.com/jsoftware/jsource/blob/master/jsrc/v.c F1(jttable){A z,zz;I r,wr; F1PREFIP;ARGCHK1(w); // We accept the pristine calculations from ravel wr=AR(w); r=(RANKT)jt->ranks; r=wr<r?wr:r; // r=rank to use // obsolete RZ(IRSIP1(w,0L,r-1<0?0:r-1,jtravel,z)); // perform ravel on items RZ(IRSIP1(w,0L,r-((UI)r>0),jtravel,z)); // perform ravel on items R r?z:IRSIP1(z,0L,0L,jtravel,zz); // If we are raveling atoms, do it one more time on atoms } // ,."r y Quoting https://corecursive.com/065-competitive-coding-with-conor-ho... : > Yeah. I started a project a couple months ago. I’m slowly porting that code base, the J source code to C++ 20. And yeah, I think there should be a name for these types of code bases, because it’s not C, it’s like a macro variant of C, where it’s a CDSL,

No, it was rhetorical, because it's obviously (to an APL-family programmer), not bad! Your cultural prejudice is showing. There are good reasons APL is written the way it is, and this example is simply bringing those benefits to C by writing it in the dense APL style. There are other APL derivatives, like J[1] that are written in C the same way. These projects are well-maintained. They aren't collapsing under a load of technical debt. The style works. To them, it's clean code. [1]: https://github.com/jsoftware/jsource

The article starts with some reasonable premises, but the conclusion does not follow. I think most APL programmers would disagree with this take. Dense code has real advantages, and naming everything has real costs that are hard to see. There's nothing magic about a "line" that suddenly allows for chunking. You have to build a parse tree in your head in any case. I'm reminded of Doug McIlroy's challenge to Knuth.[1] It's worth a read. Would you rather have 6 lines of dense shell, or 10 pages of Fabergé egg? I'll take the shell, thanks. Look at the source code for J (an APL derivative)[2]. It's written in C, but that C was written in APL style by APL programmers. Lines leverage macros and 1–2 character names, making them extremely dense. Some files have a comment on nearly every line. For an average C programmer, this code looks absolutel

Recently, I wanted to write a simple piece of code in J, but immediately found a bug. I went ahead to fetch the source to see if I can fix it. But, hell no. I couldn't believe my eyes. Is this how someone programs, really? I just can't believe it didn't go through some kind of obfuscator. Here are some samples, but almost anything in the repository is beyond me: https://github.com/jsoftware/jsource/blob/master/jsrc/xo.c https://github.com/jsoftware/jsource/blob/master/jsrc/k.c https://github.com/jsoftware/jsource/blob/master/jsrc/j.h What's your opinion?

Is it? https://github.com/jsoftware/jsource/blob/master/license.txt

J is fully opensource: https://github.com/jsoftware/jsource Most of jd's source is publicly available: https://github.com/jsoftware/data_jd

APL/J/K C-sources (perhaps by Roger Hui): https://github.com/jsoftware/jsource/blob/master/jsrc/a.c and other *.c files Niklaus Wirth, Verilog: http://people.inf.ethz.ch/wirth/FPGA-relatedWork/RS232R.v all of ioccc)

Thirty year old codebase with few developers, built on multiple platforms. It's about what you'd expect. But I believe there have been some improvements made in the past five years or so (the source was released under GPLv3 about ten years ago). BEST, llc has built it with Tup (see https://github.com/iocane/unbox), so changing the build system is at least possible. Edit: there's also a long-open PR to move to CMake at https://github.com/jsoftware/jsource/pull/20.

I think this is the main J repo [0]. (Though I’m not sure if it’s any more readable.) Possibly interesting that Tavmem is the maintainer of Kona (open source K3/4). I guess he’s comfortable with all APL/J/K languages. [0] https://github.com/jsoftware/jsource

J is not closed source and hasn't been for a while. https://github.com/jsoftware/jsource

Is K [0] in some sort of competition with J [1] about who can write worst, most unreadable and unmaintainable C code possible? [0]: https://bitbucket.org/ngn/k/src/master/m.c [1]: https://github.com/jsoftware/jsource/blob/master/jsrc/v2.c

I'd add to this family the J system, ver. 7 - https://github.com/jsoftware/jsource . A good example of creating a DSL and then efficiently using that. "Never had a memory leak from day 1 (Roger Hui)" (written in C).