[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!