[geocar]

> I guess it comes down to how ones brain is wired then.

Your brain is not wired. You can learn new things, including this.

> I've read and worked on enough super-terse code in other languages to feel confident in that.

To know you will fail before you try? What a great time-saver that must be. I simply would never believe it.

Listen, I don't think most k code is "super-terse" -- for sure, it is fun to play golf with k and think about ways to make it shorter, but you can do that in any language. That's not what's going on here.

Allow me to explain: I learned k because I saw someone do something with k I did not know how to do with C. That was it. That convinced me that there was value here, and so I learned k.

And then something magical happened: When I went back and read C, I was reading that faster. Not quite as fast as k, but substantially faster than I was reading C before.

That was so surprising and unexpected to me. I think I expected that if I took a break from C I would get rustier at C, not better. And so I talked to a few people about it, and convinced them to learn k, and you know what was really amazing? It made them better programmers too!

So I hear that you can't now, and that's okay, but I think it's worth learning. I don't know if everyone learns differently, but most everyone (myself included) struggles and struggles and struggles until one day, they just get it. And it's hard to know how far away you are from that point unless you go there, so if you're worried you're not smart enough to figure it out, you just need to trust that dumber people than you have figured it out and you just have to keep trying. I am telling you it's worth it.

There are other languages that actually try to look like noise, like brainfuck, where part of the challenge (or the treat) is figuring out how to say things we think of as simple using the most primitive of tools, but k is not one of them.

I remember the first thing that got me excited, was when I realized the implications of (intentionally!) confusing indexing from application. In k, f[x] means if f is a function, call it with x as an argument, but if f is an array, give us the value at index x. Just think of this pattern, in all the ways you see it:

    for(i=0;i<x.length;++i)f(g[x[i]]);
    x.forEach(function(a){f(g[a])})
    foreach($a as $x){f($g[$a]);}
    for i in range(0,len(x)): f(g[x[i]])

Now they're all just f g x; barely 10% of the typing and code! I just can't agree that f g x is "super-terse" that's just the normal way to write it. I also think it is easy to agree that it doesn't look like noise and couldn't possibly be anything simpler.

> I don't have trouble remembering what range() does because it says so right on the tin, unlike for example + in k (addition or, surprise, transpose).

Try to read a little more carefully what I am saying: I wasn't confused about what range() did, I was confused about whether it was the best way to do what I wanted to do.

Also, + is flip not APL's transpose operator.

[magicalhippo]

> To know you will fail before you try?

I don't of course. But I don't have infinite time or resources, so I sadly have to prioritize. Hence why I was curious if there was something more accessible.

> I just can't agree that f g x is "super-terse" that's just the normal way to write it.

I agree that allowing indexing and function calls to have a unified syntax can be very useful. I've used this several times in my own code (through anonymous functions).

But I still think "f g x" is quite terse. For example, it's suddenly implied you're looping over all the elements of x, whereas if it was just function composition it would return a function taking an index.

Does it in itself look like noise? Not to me. But with the extensive use of symbols and tendency to do one-liners it adds up.

Anyway, appreciate the discussion. Maybe I can get a chance to crack the code, so to speak. Regardless of how I think it looks, it does seem like an interesting language to know.

[t-3]

> it's suddenly implied you're looping over all the elements of x,

One of the most mindblowing parts of array languages is that there are no loops. Everything is just arrays and operations composed to produce more arrays. A few weeks ago, I was firmly in your camp, and thought APLs were indecipherable, but they're really not. It's just a totally different philosophy of programming.

[magicalhippo]

Yeah I'm sure there's a good reason for it. But I think most would still call it quite terse.

Anyway, good to know it might not be as impenetrable as it appears. Just glanced at the "Notation as a Tool of Thought" article and it looks illuminating as well, so will be reading that in detail.

[geocar]

> implied you're looping over all the elements of x, whereas if it was just function composition it would return a function taking an index.

I think it's a mistake to make this assumption.

In C, if you saw:

    f(g(x));

you wouldn't expect to be able to make any assumptions about how many loops are going on in there. Python programmers are often overloading their functions too, so you can't even say anything about x+y in Python. I actually think it's the norm that you have to dig all the way down to understand what's going on, and it's the same thing happening here: Yes either f or g might be a loop. Or both. That's just life.

At the end of the day, the only thing I think that helps with that is having less code to read (in source-code bytes).

[magicalhippo]

> I think it's a mistake to make this assumption.

I think you might have misunderstood me. However since I don't know k well enough, maybe my point was based on a misunderstanding as well.

What I was trying to get at was that, as you also note, overloading makes it harder to keep track of what the code does. Sometimes this terseness is worth it, and that might be the case for k and friends once you know it.

> the only thing I think that helps with that is having less code to read

I don't have experience with k, so things might be different there. But certainly for me, it is not true in say Python or C# etc where I find less code can be significantly more difficult to read and understand. Of course that doesn't mean writing highly verbose code is automatically better, the optimum is somewhere in between.

For example, often it's just as important to know why some code does what it does, so splitting up operations, using more verbose with variable names etc can make the code significantly more self-documenting.

[geocar]

> certainly for me, it is not true in say Python or C# etc where I find less code can be significantly more difficult to read.

Is it possible this is only a reflection of your experiences and not reality? Surely when you say this, some example sprung to your mind, but where is the proof?

> it's just as important to know why some code does what it does, so splitting up operations, using more verbose with variable names etc can make the code significantly more self-documenting.

I doubt the importance. Quite seriously. When I want to know why the business asked for it, I ask them; There's probably a ticket or a email someplace.

But I have zero interest in puzzling about what the programmer was trying to do[1], and let me tell you why: I think it is very easy for our minds to be tricked into thinking we read something when we actually didn't. If you've never seen Paris in the the spring, you might not know what I mean, but perhaps you've seen some close-up magic, and maybe you've even been fooled before.

I think the only things I need to concern myself with are what the program actually does, and how that differs from what the business wants.

I have on more than one occasion gotten off a long-haul flight just to read someone's code out loud to them over their shoulder. I'm not kidding. The bug is there. I absolutely do not care one bit what the comment says above there, or what you think that library function should do; the code doesn't do what the comment says, it does what the computer says! The computer doesn't know the difference between a context or a ctx (or a c).

Of course we do, and so when we see it, we assume we know what it is, instead of checking. And when we get it wrong? Bang, another bug, and I'm having airplane gin for supper.

[1] I am being somewhat dramatic here. I'm quite interested in watching people use my libraries so I can understand the way that I help, and I'm quite interested in looking out for training or tooling opportunities, so if people keep making the same mistake, it's probably worth some investment. I mean for the purposes of making changes the business wants.

[magicalhippo]

> Is it possible this is only a reflection of your experiences and not reality?

For terseness, I think it's pretty easy to show that k is a lot more terse than say Pascal in various quantitative ways.

Readability quite subjective though. I'm not saying k is universally less readable. But my experiences tell me that for me it might be. Hence why I was looking for alternatives that might fit me better.

> I think the only things I need to concern myself with are what the program actually does, and how that differs from what the business wants.

This is exactly what I was trying to get at. For me, self-documenting code helps with this, as I find it easier to find discrepancies or where I need to focus my attention when extending code.

Anyway, got to spend a bit more time on the two tutorials posted here, which really helped, so will try to take a stab at k during summer break.

[geocar]

> Readability quite subjective though

> I'm not saying k is universally less readable. But my experiences tell me that for me it might be.

I would not worry too much about this: Readability as we can make statements about the code has an executive function[1], but as it pertains to you, how readable it is to you only affects your ability to use these tools of thought, and that will only improve by doing more of it.

If you've learned another spoken language after childhood, it is a little like that, and some people get stuck (or plateau) at some point for a long time and think they'll never get any better, but suddenly one day they do, and I'm sure you can do this too. It won't help to say more about readability, for what will be will be. What's important is to commit to an open-mind and leave open the possibility you can be convinced.

Maybe if you can find a local meetup or a group of array-nerds to talk to, you would find it helpful to join them; I've noticed many people "get" things easier when they see and hear lots of different explanations about what's going on (I certainly feel that way about my own learning!), and when you see people at different stages of their journey, you might learn more about your own. But if not I'm always happy to help; you can drop me an email, and I'll tell you what I think.

[1]: That is, for management, Readability is quite important: It impacts how easy it will be to replace your developer.

> Anyway, got to spend a bit more time on the two tutorials posted here, which really helped, so will try to take a stab at k during summer break.

Boa sorte!