jsource VS ZLib

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/

Oh damn Whitney C representation.

I develop J btw

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 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

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

You can view the code, but is not open source: https://github.com/jsoftware/jsource/blob/master/license.txt

This is the same dense style used in J.

All-in-all this example doesn't seem too bad. It's clear what happens and is easy to follow. If you wan't to see something remarkably terribly, check out Whitney style. It's used in APL/J/K family interpreters. Keep in mind, financial institutions run that code.

A fix has been checked into the upstream git repo: https://github.com/madler/zlib/pull/843 but a release has not yet been made including it.

So the real issue here is that the lack of tree validation before the tree construction, I believe. I'm surprised that this check was not yet implemented (I actually checked libwebp to make sure that I was missing one). Given this blind spot, an automated test based on the domain knowledge is likely useless to catch this bug.

[1] https://github.com/madler/zlib/blob/master/examples/enough.c

In the source code of the Node.js opensource project, lib folder contains JavaScript code, mostly wrappers over C++ and function definitions. On the contrary, src folder contains C++ implementations of the functions, which pulls dependencies from the V8 project, the libuv project, the zlib project, the llhttp project, and many more - which are all placed at the deps folder.

Seeing the text in red got me thinking for a moment, "wow, didn't realize pirates had such love for an open-source compression library"

cd "${srcdir}/zlib-$pkgver/contrib/minizip" make install DESTDIR="${pkgdir}" install -D -m644 "${srcdir}/zlib-$pkgver/LICENSE" "${pkgdir}/usr/share/licenses/minizip/LICENSE" # https://github.com/madler/zlib/pull/229 rm "${pkgdir}/usr/include/minizip/crypt.h"