[gruseom]

It is probably the most astonishing combination of simplicity, efficiency, and beauty that I've seen in computing.

Unfortunately, it's so out-there that nearly everyone dismisses it as unreadable and daft. In a better world, it would be taught and studied as an exemplar of design. (On the other hand, they've succeeded financially so how cool is that.)

[iskander]

My experience with Q was somewhat less inspiring than yours. It has some powerful core primitives but is generally poorly designed and terribly implemented. Single letter function names (and error codes) don't actually make a language any more expressive.

[gruseom]

I can understand why you'd say poorly designed, because the tradition it comes out of is so austere. But "terribly implemented"? That detracts from what you're saying. The thing achieves performance everybody else dreams of.

No doubt its error handling leaves a lot to be desired, but single-character names are a different matter. That's part of the APL style, and it's a mistake to reject it out of hand. The trouble is that nearly everybody does, because it's so beyond the pale.

Edit: Perhaps I should explain what I mean about the APL style.

Languages in this style are not "unreadable"; rather, they trade lexical readability for whole-program readability. Their emphasis is not on names, but on operators; specifically, operator composition. Their advantage is the astonishingly high-level power of their operator strings—sequences of composed operators, each of which passes its output to the next, like Unix pipes.

After a while, typical operator strings become recognizable as idioms, making them leap out at the reader. This allows one to comprehend quickly what would take many lines of code in most other languages. True, each of those many lines would be more lexically "readable" in the sense that you could grok its individual tokens more easily. But that's not how you comprehend what a program is doing. To do that requires grokking the intent of a bunch of lines together. In other words, program intelligibility is not primarily a matter of token readability but of whole-program comprehension. We're just so used to one way of doing it that we reject all others as "unreadable". We forget that variable and function names are not an end in themselves, but a means to an end. APL-based languages have a different means to that end.

If APL-style programs were to use long expressive names like other languages, the shape of their operator strings—the most important thing—would be obscured, and you would lose comprehensibility rather than gain it. The role that names play in such programs is different. They are placeholders. Like colored beads, they occupy certain positions in the operator strings and demarcate what the code is doing. If these names were even half as long as what you use in conventional languages, they would overwhelm the code so much that it would consist of nothing but names with a few operators scattered here and there. The program's structure would then be less accessible.

Another way of saying this is that names are so much shorter because everything is so much shorter, which is what makes the operator-oriented style so powerful.

It's true that such a language is symbolic, even cryptic, compared to most. But that is a bad reason to dismiss it, especially before one's eyes have adjusted. All programming languages are symbolic and cryptic before one has learned any. The reason why programmers take for granted that conventional languages are more "readable" is that these languages are related to each other and we all know one of them. We are like Spanish speakers saying that French is more readable than Russian. Since we all (to extend the analogy) know at least one Latin language, we take this view for granted when it's really just relative and—if one wants to push the point—false.

Now where are beagle3 and silentbicycle to back me up.

[wyc]

I think this article helps to better understand this point of view:

http://kaleidic.com/2010/readable-code/

J is a language, like Q and K, also derived from APL [1].

Instead of depending upon layers of abstraction through variable and function naming, this style has a fundamental set of vocabulary (operators) that is insanely expressive in collusion. This allows for concise formulation and expression of algorithms.

However, these languages do not excel in every domain. For example, they're incredible for manipulation of homogeneous data sets, but I haven't heard of an idiomatic way to do heavy socket programming (yet).

[1]: http://www.jsoftware.com/jwiki/Studio/TasteofJPart1

[gruseom]

Interesting piece. This line:

More powerful programming languages rely less heavily on naming

... reminds me of section 1.1. of Compiling With Continuations:

The beauty of FORTRAN—and the reason it was an improvement over assembly language—is that it relieves the programmer of the obligation to make up names for intermediate results.

I remember going "Wha?" when I read that.

[geocar]

It makes a certain amount of sense though: Just think of all the times, in all seriousness, one uses `tmp` or god forbid, `tmp2` as a variable name.

[iskander]

> The thing achieves performance everybody else dreams of.

Citation needed? In experience (implementing simpler ML algorithms across Q, Python, and Matlab), the performance of non-trivial programs (using multiple operators together) is middling at best, even for an interpreted array language-- and orders of magnitude slower than an optimized native implementation.

[gwu78]

Did you post your implementation to the mailing list?

I highly doubt Python or Matlab beats q, but I'm biased.

I'm not sure I understand the comparison to a "native implementation". You mean C? How about assembly? Why would you compare an interpreted language to those? Just use C, if you can.

If you don't tell us exactly what you were trying to do and how you approached it, then there's no reason to give any weight to your comment.

In other words, where's _your_ citation? Give us the problem you were trying to solve.

If you do not give anyone else a chance to offer a solution, then you never really know if you have tried the best approach.

[gruseom]

Ok, clearly not everybody. But I'm surprised to hear that. You're the first person I've heard say anything like it.

[gwu78]

Is implementation really about what you name the functions?

I thought naming functions was "programming style".

And implementation was about the math.

The quality of the latter being measured by profiling and performance.