On being startled by a programming language
bbot.org
bbot.org
Some of us are trying to organize our efforts here: https://github.com/openj/core
We don't intend on mucking with the code much at this point, just patching together a better build system, etc.
I'm pretty sure there are about two people that can read and write that fluently: Roger Hui and Arthur Whitney.
"I did pure mathematics in school, but later I was a teaching assistant for a graduate course in computer algorithms. I could see that the professor was getting killed by the notation. He was trying to express the idea of different kinds of matrix inner products, saying if you have a directed graph and you're looking at connections, then you write this triple nested loop in Fortran or Algol. It took him an hour to express it. What he really wanted to show was that for a connected graph it was an or-dot-and. If it's a graph of pipe capacities, then maybe it's a plus-dot-min. If he'd had APL or K as a notation, he could have covered that in a few seconds or maybe a minute, but because of the notation he couldn't do it." - "A Conversation with Arthur Whitney" (http://queue.acm.org/detail.cfm?id=1531242)
A better way of doing this is Fortress, which tries to use mathematical notation when possible but doesn't try to compress it as small as possible.
(That one-page J interpreter is sometimes called the "J Incunabulum".)
See e.g. http://news.ycombinator.com/item?id=1458016 http://news.ycombinator.com/item?id=266982 http://news.ycombinator.com/item?id=697501 http://news.ycombinator.com/item?id=2176980
#define DECLG V*sv=VAV(self);A gs=sv->g; \
AF g1=gs?VAV(gs)->f1:0,g2=gs?VAV(gs)->f2:0
Judging the quality of this code says nothing about the language and environment that this code provides. 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.
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.
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.
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.
Any incentive I had to try this language is now gone and I want to erase the memory of its construction from my mind.
Code like this needs to be read more slowly than usual, because unlike much C code, the information level isn't low enough that you can read it lines at a time. Math papers have all these weird sigma symbols and stuff, too; you can't read just them as fast as you would read "for (i=0; i<N; i++) {" for the millionth time.
Likewise, rather than writing "for (i=0; i<N; i++) {" yet again, K just calls that ' and moves on. In the source, there's a macro called DO, which is used extensively. DO(N, Blk) -> for(i=0, int _n=N; i<_n; i++) { Blk } . The APLs are about having a notation that doesn't constantly get in the way of thinking about your actual problem.
It's funny that you bring up mathematical notation because mathematical notation is completely optimized for write-only. Mathematics is so obsessed with one letter variable names that they had to gather letters from other alphabets to continue their opaque tradition.
Mathematical "code" isn't usually meant to be read without the surrounding variable and notation declarations, for example "Let x be ..." or "where • is the ... operation". If those are provided, short variable names and terse notation allow for the intent to be presented clearly, without it being obscured by line-length restrictions and a limited number of generic constructs (eg. for-loops instead of the summation operator).
That said, I'm finding this C implementation of J to be pretty cryptic. Of course, that's no reason to dismiss the J programming language itself.
% jconsole
|file name error
| 0!:0 y
load 'packages/misc/fndisplay.ijs'
|value error: load
| load'packages/misc/fndisplay.ijs'
(I tried with absolute paths too)Any idea what I might be missing? And do you know the license of the libraries?
I think humans LOVE syntax; and syntax is often loveable, crystallizing a new viewpoint into a linguist pattern that allows this viewpoint to be diffused by our amazing hardwired capabilities for language. J does that.
That being said, sometimes being seduced, while REALLY FUN for a little while, turns out to REALLY MESSED UP in the long run. I think J and APL are like that too -- just break up with him, really....
For another metaphorical take: I think Python and C are like English -- boring, with a lot of fun syntax stripped out, but very, very useful. C++ is like Mandarin -- completely complicated, but so much literature and history is written in it that you have to take it seriously. Shell is like the pidgin languages. And J/APL ... they are like Quileute (the language spoken by Jacob-the-Werewolf's tribe): completely difficult, arcane, counter intuitive, and only spoken by like six other weirdos (ie don't bother).
All these languages are seductive, though.
J programmers love to exchange emails like "I found a way to calculate pi to the 80th decimal with only 4 characters" ... as if that is remotely useful. We have J code in use in our office -- its fun, if you like speaking Klingon, but it is a complete waste of time and sweat for any pragmatic applications. If you want to do complex weird matrix stuff in a few lines, learn linear algebra and tensor operations for chrissake, which actually have some utility in the real world. And don't be fooled by APL/J types telling you their language is mathematical -- it isn't, in the sense that you can't actually derive new results with it; it is just difficult (good math makes thing easier).
Sorry for the rant. I wish the damn language would disappear, and we could remember it wistfully like SNOBOL, Ada, SAS, and other bad experiments in seductive syntax.
Oh -- I would respectfully hazard that syntax for you (and for me!) is no more for superficial than the blue eye shadow on the girl in my 10th grade English class, if you get my drift. ;)
Most operators have implicit dimensional looping or respond different to differently ranked inputs.
Take for example integers (i.):
i.3
0 1 2
i.3 3
0 1 2
3 4 5
6 7 8
(That's kind of a dumb example, but I think it at least hints at the expressive power of rank.) >>> def index(x, y):
'Dyadic function indexes y by x'
return [y[i] for i in x]
>>> p = list(range(22))
>>> shuffle(p)
>>> p
[1, 20, 19, 15, 9, 14, 6, 8, 2, 4, 16, 18, 10, 3, 0, 13, 12, 11, 7, 17, 5, 21]
>>> index(p, p)
[20, 5, 17, 13, 4, 0, 6, 2, 19, 9, 12, 7, 16, 15, 1, 3, 10, 18, 8, 11, 14, 21]
>>> index([1]*22, p)
[20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20]
>>> index(p, [1]*22)
[1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]Even with 20-to-1 comment-to-code ratio, it was easy to get confused with code written the previous morning. By you.
From what I see, the most important development is using plain ASCII. Too bad it's still unpronounceable. Dictating APL code to another student was endless fun. We even invented our own names for some of the symbols...
Having said that, APL was exquisitely powerful and concise. Yet, I have to wonder if there is space for an exquisitely concise write-only computer language today.