[Drakar1903]

This is what - I presume - is their implementation of sending an e-mail

E:[u:();e:{a::?[a;x;y];J(x)+#y};cz:{$[#u;e/_`u;]};kx:{u,:,(j,j+#x;k_a);e[k]x};kb:{$[=/k;J j-1 0;];kx""};cx:{kx cc`};cv:{kx@9'`}] A:[w::_W%F;j::k;k:0 0;J:{k::2#0|x&#a};lx:{J j+x};y::V+F0,j;z::1'(V;w[1]$a)],E

U:{(`Z,'!Z).'+x};V:0;i:0;I::`Z,(!Z)(#Z)!i;y:{I .`y};zf:{$[`kt=x;i+:1;^`W`F?x;I . x;. x]};u::F[0]!#Z;W:{U`V,,u,'0;U`W,,(-':1_u,x),'x 1};z:{U`z;1'(V;U[`a]{$[#x;"";y]}'$!Z;3)} Z:`to`cc`subj`!A$/:4#()

This looks like an exercise in obtuseness.

[brazzy]

A bit more convincing: http://www.kparc.com/edit.k

Properly formatted and with comments, it almost looks readable.

The insistence to use one- or two-letter identifiers that you then have to look up the meaning of in a comment makes it look pretty childish, though. "Look ma, it's still super terse even when doing something real!" Yes kid, it is when you refuse to do the one obvious thing that could actually make it readable.

[dang]

Single-letter identifiers are a natural thing to object to when coming from other language paradigms, i.e. nearly every programming background out there, but this is a category error. What seems ridiculous in one context can be sensible in another. The objection turns out to be parochial.

It reminds me of how people think that parentheses are a significant aspect of Lisp, when in practice they're not. The parens look grotesque at first, but once past the novice stage they fade completely into the background and impose no cognitive overhead. Because of their regularity, the parens free you to program without thinking about syntax, allowing you to think more about the problem at hand—a highly liberating experience—yet to someone who hasn't worked with the language long enough to get that experience into muscle memory, they look absurd.

Short identifiers are preferred in APL-style languages because longer ones obscure the code. As you get familiar with the idioms of the language, you can pick them out in visual chunks to grok what a program is doing. You're not reading the program operator-by-operator, but phrase-by-phrase.

That wouldn't work if the programs used longer identifiers, because then the programs would consist mostly of identifiers, making it harder to scan the phrases, making it harder to grok the code. That's why people don't do it. You can simulate that in more familiar languages:

  for (ridiculously_long_name = 0; ridiculously_long_name < 100; ridiculously_long_name++)

No one writes like that because beyond a certain length, the identifiers distort the code. That's what's going on in APL languages too; it's just that the "certain length" turns out to be 1 or 2.

In other words, the reason why APL-style programs adopt this style is not because the programmers are childish, but because the ergonomics of the language make it optimal. This is hard to understand, but only because mainstream languages have completely different ergonomics.

[buzzkillington]

Writing APL (or J/K) with the ascii character set is like coding C in Morse code.

I wrote plenty of J code for my masters in particle physics and the only way I could use it without going insane was to write a noweb filter for literate programming when using latex symbols for the functions. The woven document was close to mathematics, the actual source code was editable source code.

[gjulianm]

One or two characters for identifiers is optimal? What kind of programs are being written with APL/K? At some point you'll have more concepts in your program that available letters unless you're dealing with tiny programs.

[dang]

The more experienced programmers in this thread can answer this better, but I believe top-level functions tend to get longer names.

[saagarjha]

Are APL programs normally clumped together, as they are commonly presented to show off their terseness, or do they normally have comments and line breaks to indicate structure?

[bartread]

I tend to agree: falls into the category of "just because you can, doesn't mean you should."

Actually, that's perhaps a bit harsh.

I have some pretty obscure hobbies, and there's certainly nothing wrong with doing this sort of thing if you want to. Still, having done so it's a bit rich to then look askance at the rest of us like we're all idiots for not choosing to go down a similar route with our own systems.

[TheOtherHobbes]

I suspect everyone would love K if they had an extra 30 IQ points to work with.

The reason we have Python, Javascript, and Java is because most people (including me) just aren't bright enough to work fluently in these terse APL-alike idioms.

They fail because it's hard for most people to keep that many terse symbols and symbolic relationships in memory at the same time, without English labelling and all the other usual memory aids.

(In fact basic functional programming is a bit of a stretch for the average commercial developer.)

An interesting hypothetical is what a language would look like if it needed an extra 60 IQ points...

[rtikulit]

In the 70's, in high school, I taught myself APL (mostly TOPS-10 APL SF and a bit of IBM APL SV) well enough to grasp the fundamental functional approach and write real programs (and the obligatory game of life in 1 line :-)) At the time I was also using PL/I and the difference was mind expanding.

I'm quite sure I don't have an 30 extra IQ points. Mostly I was just mildly obsessed (and these days I find persistence is a workable substitute).

It is incredibly valuable to have experience across the range of programming paradigms.

[bartread]

IQ points aren't really anything to do with it: I suspect most programmers, and certainly those who are average or better, could learn to be proficient with K if they invested the time.

The real issue is knowing your userbase.

Example: we have this in-house DSL that's been around for years and uses a symbolic representation not a million miles from K that we use for automating reports. The problem is it's a pain to onboard people who, whilst they're bright enough, aren't programmers and in any case have many other responsibilities to attend to. Giving them something more readable rather than arcane makes life easier for everyone.

And fundamentally we want to make it easy for everyone, not just the top quartile or the top 10%, to quickly crank out high quality automated reports across different market sectors, geos, etc., as well as to modify and maintain these reports into the future.