[magicalhippo]

> you could learn the syntax in order to make a more informed assessment

I'm fairly sure my assessment wouldn't change even if I did learn the syntax. It would still read like noise. The only difference would be that I could understand the noise.

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

> Do also seek out geocar’s posts. They are well written and to my mind convincing.

I guess it comes down to how ones brain is wired then. For example, I have the exact opposite reaction to multiple pages of code vs terse one-liners compared to geocar[1]. 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).

[1]: https://news.ycombinator.com/item?id=27223086

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

[gitonthescene]

I think you’re right that if you’ve already decided what the outcome will be then it’s not worth your time but also think it severely undermines the value of your opinion for others.

[magicalhippo]

I have a feeling it's a bit like being color blind. It doesn't help how much people try to explain just how different red and green look if I'm red-green color blind.

Ever since I got somewhat proficient at programming, I've been able to take a quick glance at some non-terse code with descriptive identifiers and get a feeling for what it's doing. Often very accurately, which makes it easy to mentally filter the code into what I need to focus on and what's irrelevant to the task at hand.

But if people write very terse code, this goes down rapidly. I have to spend a lot of time scanning for important symbols, unpacking what's going etc. When they stuff everything on as few lines as possible and use single-letter, non-descriptive identifiers it gets significantly harder to read for me. Now I really have to study the code, and remembering what things do gets harder due to non-descriptive names.

I've worked on a fair bit of really terse code, and I find it just doesn't allow me to be as productive as I am with less terse code.

This is why I doubt that learning k will completely change that, and given that I have very limited time and capacity for fun things like learning new languages, I was curious if there was something more approachable for me.

[gitonthescene]

I think very few would argue that this style of coding doesn’t demand more of the developer, but the thinking is that the focus it demands is appropriate. Programs are written for running, ideally accurately. Without focus you can’t be 100% sure the code you glossed over wasn’t important. Hopefully though this style allows you to spend your valuable attention on the bits that matter.