[eggy]

The reason k, q or other array languages like J (which I use) help, not teach, people to solve novel problems is that they give you abstractions to quickly play with in order to tackle novel problems. My take on this whole thing is that these array languages (APL, k, J, q) are a perfect fit for things that are essentially arrays - big data, images, etc... And to those who shy away from the seemingly 'noisy' syntax, I point them to mathematics. Until you understand the sigma symbols and others, it is noise too. Why are all the new languages getting hot on 'vectorization' - Julia and company - because GPUs and data are all array-based. To have the array as your lingua franca puts you in a good position for all sorts of attacks on modern computing needs. And for those who cannot live with the syntax, and say how can you create a dsl - you can. Here is a J example of computing averages:

  +/%#

You can set this up as:

  avg=: +/%#

or

  tally =: #
  divide =: %
  sumall =: +/

How's that for a dsl? Which allows this now:

  avg=: sumall divide tally
  avg 2 4 6
  4

EDIT: I forgot to add that these operations, as others in J or APL, work on scalars, vectors and arrays without any special typing or handling. See this presentation for at least the first 5 minutes to see J in action with explanation: http://www.infoq.com/presentations/j-language The conciseness allows you to start seeing the small patterns in the small expressions just like mathematics, hence bringing clarity and speed of abstraction to your concept manipulations.

[KayEss]

I think part of the difficulty here is that it's almost like Haskell's point free style, but not quite. It isn't really clear where the arguments to avg go. It seems that it's meant to be a bit like this:

    avg list -> (sumall list) / (tally list)

I guess you just need to know how the argument you give to avg when you use it distributes over the functions that comprise the expression. The list argument to tally isn't a problem, but why does sumall get it's own copy of it? Or is the execution model something else entirely?

[avmich]

In J there are two special ways to combine functions which are written using special syntax. Namely,

1) when you want to calculate f(y, g(y)) , you write (f g) y - this is "hook" of one argument (monadic, in J terms)

2) when you want to calculate f(x, g(y)) , you write x (f g) y - this is "hook" of two arguments (dyadic)

3) when you want to calculate f(g(y), h(y)) , you write (g f h) y - this is monadic "fork"

4) when you need f(g(x, y), h(x, y)) , you use x (g f h) y - dyadic fork

5) when you have a train - say, (a b c d e) x - longer than 3 elements, then you consider rightmost 3 functions (functions are called verbs in J) as a single fork - say, f - and then consider (a b f) x . So (a b c d e) x is

b(a(x), d(c(x), e(x)))

If the train length is even, the last operation becomes hook - so x (a b c d) y is

a(x, c(b(x, y), d(x, y)))

You can express any computation as a sufficiently complex train.

[tubular]

A mite of pedantry: the J train (a b c d) is a hook with a fork on the right, and so dyadically acts like

a(x, c(b(y), d(y)))

Roger himself has dismissed [0] hooks as an unfortunate result of J4's myriad train rules, made in the name of tacitable everything, which I lament because for some reason, tacit programming is just so much more satisfying than normally solving the problem.

[0]: http://www.jsoftware.com/jwiki/Essays/Hook%20Conjunction%3F

[avmich]

Yes, my mistake regarding 4-element dyadic train.

[Gravityloss]

That takes some time to digest, but I guess is absolutely crucial to be able to do anything with this language.

Would you say that this is 90% of the reason it looks so uncomprehensible?

[avmich]

No, it's not absolutely critical. You can do a lot of your own programming without using hooks and forks. Your programs will be somewhat simpler - and whenever you need to use a variable in several places, you'll have to explicitly name it - but still.

Incomprehensibility happens in part because all ASCII characters are used - so you have a lot of differently-looking symbols; because [ and { aren't paired with ] and }, and " isn't paired either; because you often have . and : as the second character of built-in entities, so you've got a lot of dots... APL used the symbols invented explicitly for those purposes, but the price - non-ASCII alphabet - was considered too high. So - no, I wouldn't say forks and hooks are the source of 90% of uncomprehensibility.