- What's the scope of x? it appears to be the argument of two different anonymous functions.
- Is / both apply and reduce?
- So 'x f list' applies f to list x times. What if I use ',' instead of f? That is, what does 'x,/list-of-lists' do? does it flatten the list of lists and then concatenates x or does it flatten the list of lists x times? It seems confusing to have symbols that act both as operators and as functions.
- Why is '-2#x' "take last two elements of x" and not "negate the first two elements of x"? If I understand correctly, based on the evaluation order you're using it should be the latter, no?
And all of that from a simple Fibonacci function. I can't imagine how difficult it must be to dive into an actually complex codebase. And it's not just about the different paradigm. That's not the problem, the problem is focusing on terseness above all.
I get that once you are deep into a language or codebase you lose sight of the complexities because you get used to them. But it doesn't mean they aren't there.
An anonymous function is defined (can't find a better word) between braces like {x+1}, in python (lambda x: x+1). There is an inner one, {x,+/-2#x}, and the outer one (the entire thing).
/ (like a lot of k symbols) does a few different things depending on context. In this case, if you do n f/x, where f takes a single argument (is a unary/monadic function), it applies f to x n times.
-2#x: yeah, it seems reasonable that it might negate the first two elements, APL uses ¯2 instead of -2 for this reason. In k however -2 is parsed as one number, as - then 2#...
Sure, there may be some complexities or questions, but there are in all languages, and in this case they were fairly simple things anyway to me.
> here is an inner one, {x,+/-2#x}, and the outer one (the entire thing
So in the inner one, x is the argument of the inner function or the argument of the outer one? Is x always an argument to anonymous functions?
> / (like a lot of k symbols) does a few different things depending on context
That's a recipe for confusion.
> Sure, there may be some complexities or questions, but there are in all languages
I can go back to the initial example: just browse other implementations of Fibonacci in different languages. For most of them you can actually understand a bit what's happening, even if it's a different paradigm (e.g, I can understand the Haskell or Clojure implementations without too many issues, and in fact I can learn things about the language from that). But operators that do different things depending on context, insistence on non-standard symbols, weird scope issues... That's not "complexities or questions that are in all languages", that's a recipe for confusion and extra complexity that you need to have in mind on top of the complexity of whatever you are coding.
Default arguments to anonymous functions are x, y, and z. You can also name arguments like this.
{[foo; bar] foo+bar} is the same as {x+y}
I'm not denying it is probably more possible to gain a superficial understanding of what code written in other languages does than code written in k to someone who's never seen k before. This just doesn't seem like that important of a language feature. The 'confusion and extra complexity' you mention wouldn't really confuse anyone who'd tried k for more than a couple of hours (at most).
- What's the scope of x? it appears to be the argument of two different anonymous functions.
- Is / both apply and reduce?
- So 'x f list' applies f to list x times. What if I use ',' instead of f? That is, what does 'x,/list-of-lists' do? does it flatten the list of lists and then concatenates x or does it flatten the list of lists x times? It seems confusing to have symbols that act both as operators and as functions.
- Why is '-2#x' "take last two elements of x" and not "negate the first two elements of x"? If I understand correctly, based on the evaluation order you're using it should be the latter, no?
And all of that from a simple Fibonacci function. I can't imagine how difficult it must be to dive into an actually complex codebase. And it's not just about the different paradigm. That's not the problem, the problem is focusing on terseness above all.
I get that once you are deep into a language or codebase you lose sight of the complexities because you get used to them. But it doesn't mean they aren't there.