From the coding conventions for Kona (http://github.com/kevinlawler/kona/wiki/Coding-Guidelines), an open-source implementation of K 3.2 that I've been contributing to lately:

    This is a very unusual style of C

"The unusual appearance is a side effect of writing C as concisely as possible. There are great benefits to writing code as concisely as possible. Someone familiar with the style can read and comprehend the code much faster than they would be able to with traditional code. It also creates a discipline that reduces bugs. Some of the benefits will not be apparent until you try it. Some of the downsides of the style are inaccessibility and a steep learning curve."

You get used to code like that, and often, doing it that way makes sense. I first encountered it learning to read this short prototype interpreter (http://nsl.com/papers/origins.htm) by Arthur Whitney, which very strongly influenced the programming style in the J codebase.

As gruesom notes, this discussion has already happened numerous times in the HN archives. Your reaction is the APL equivalent of going, "OMG! Parens!!!!1!" when introduced to Lisp code.

Fair enough, although I've read many threads on APL-derived languages over the years on HN, but I somehow missed the discussion of the C runtime implementation.

AFAICT, the implementations have usually been closed-source (with the exception of A+ (http://www.aplusdev.org/), which is GPL'd; Arthur wrote it before K), and most research on APL implementation is locked behind the ACM paywall.

I suspect part of the style comes from APLers typically being mathematicians as well as programmers, and drawing more from mathematics than typical "software engineering best practices" style.

Then, forgive me for harping on this, how could this discussion have already happened numerous times on HN? And by "this discussion" I mean the C style used to implement APL-derived languages, not the style one uses to write programs in APL-derived languages.

They've mostly involved the "J Incunabulum" prototype and A+. See e.g. http://news.ycombinator.com/item?id=2178177 .

Hi Scott. I don't exactly agree, because the terseness and lexical density of the C code are the same qualities as cause people to recoil from APL/J/K programs as well (http://www.nsl.com/k/s/s.k). The implementation and language are cut from the same cloth. This of course is not always true (i.e. your point holds much better in the general case) - but it is true in this world, where program brevity and regularity are so highly prized.

Let's note that the payoff for departing from the mainstream in this way is not small: these languages achieve abstractive (compositional) power and elegance without sacrificing efficiency. Those two things are incompatible in nearly every other programming context -- so much so that it's a truism that higher-level code is shorter but slower, lower-level code is faster but more verbose. Yet here they happily co-exist.

silentbicycle's examples and points have actually made me come around somewhat.

But there is a key difference between the terseness and density of APL-derived languages and the C implementation of the runtime: in the actual languages, the semantics of the language are well defined and enforced by the compiler. C is a free-for-all. So while there is discipline behind the C code - and I can see that it mimics the language it implements - it must be self discipline. That makes it more dangerous, and objecting to that is not the same as objecting to the APL family of languages themselves.