That's a very convenient analogy for your argument, but it doesn't make sense for programming languages in general.
It's not really meaningful to compare the readability of sentences in English versus Chinese. On the other hand, it's both meaningful and important to compare readability of program snippets - and readability is more than just the first-time learning burden.
Overly-concise code being difficult to maintain is a well-accepted fact. The response shouldn't be to demand fluency - that's just sticking your head in the sand.
Analogies are just analogies. The point of my comment was that you need to approach this with an open mind, forgetting what you already know from other languages.
> Overly-concise code being difficult to maintain is a well-accepted fact.
Your well-accepted facts do not apply to this totally different paradigm. You seem to think those well-accepted facts are universal. They are not.
I have spent the last two years learning about array languages and think it is a fascinating topic, so I tried to give some advice (based on my own experience) to those who want to make the same journey. My point is not that you need fluency (you need some fluency to understand anything complicated), it is that the fluency you have in other languages may be counterproductive. Your comment is an excellent example of this.
Try to read a tutorial. Rewrite it using "meaningful names". All we have done that at some point, and all we started finding the sort names more comfortable to work with after a while. Don't take my word, give it a try.
> The point of my comment was that you need to approach this with an open mind, forgetting what you already know from other languages.
Why do I need to do that?
I'm interested in solving problems for people, especially using computers. To do that, I need to build teams and build software. I need to think about costs and benefits, about longevity and sustainability. A great deal of that thinking is driven by the world as it is, by the historical accidents that have gotten us to where we are.
If this is a recreational activity, not meant to be practical, then great. I know people who teach themselves Esperanto and Klingon, and they seem to have a good time. Extreme Ironing looks fun, too. But if it's going to have some bearing on my profession, then I'm unlikely to forget what I already know, because in practice the people I will work with already know quite a bit, and brains being what they are, they won't be forgetting it.
> Why do I need to [approach this with an open mind]?
Because those are the standard terms of intellectual discussion. People going into such a conversation without an open mind are called idiots, and they're not worth taking too seriously.
> I need to think about costs and benefits, about longevity and sustainability
Isn't it weird that people don't value that?
I mean, look at how many python programmers are out there! I have programs written just five years old that don't work in a new python interpreter and that's terrible for "longevity and sustainability". Good thing there are so many cheap Python programmers so we can keep the costs down: We're going to be rewriting this thing until we're old and gray!
I personally find this line of thinking quite unproductive though.
> I know people who teach themselves Esperanto and Klingon, and they seem to have a good time.
Hey that's great. I know a few Go programmers too. Loads of fun those chaps.
If only Esperanto or Klingon or Go were useful in some way....
You omitted a key piece of what I said. If you'd like to answer the question I actually asked, feel free. Bonus points if you demonstrate the values you claim to champion here, like open-mindedness and eagerness for sincere discussion.
You asked why you should keep an open mind when encountering and talking about a strange language. He pointed out that it's necessary for a good discussion on it. He's not wrong.
You've dismissed every point he made while not knowing a single thing about the topic at hand. That's not grounds for a proper discussion.
What I'm responding to in the thread is a question of pragmatism. In particular, I'm taking issue with the notion that one can only approach this "forgetting what you already know from other languages".
That's very much distinct from the notion of an open mind. And it's especially distinct when we're talking about tools that must fit into a professional context that involves decades of history, millions of people, and a complicated set of economic factors.
For example, Imagine that you were working in a machine shop and I came to you excited about a new screw-head. If you dismissed it out of hand, I might ask you to keep an open mind while I explained why I thought it was better. But if my explanation ignored that the Phillips head was the dominant choice, with billions of drivers and hundreds of billions or perhaps trillions of screws in existence, that would be another thing entirely.
The same logic applies to conlangs like Esperanto and Klingon. Is it possible it would be better if we switched the whole world to Klingon? Sure. Might I learn interesting concepts if I studied Klingon? It's possible. Should Klingon be considered for a moment as an important thing for most people to learn? No, not at all. It's utterly impractical.
So yes, keeping an open mind is valuable. But that's not something I've ever heard seriously disputed, so editing me down to saying that is constructing a straw man. Which also isn't grounds for a proper discussion.
I read the sum of wpietri's question as saying "so sell K then". As a reader I then looked on to what might be a better selling of K than all the comments I've read so far.
> Overly-concise code being difficult to maintain is a well-accepted fact.
Many seasoned APL/J/K programmers state that conciseness is an asset. I would trust their judgment on that. There are ways in which that and the quoted statement could both be true at the same time.
Aaron Hsu writes about this a lot. In an APL snippet, you often don't need layers of blackbox abstractions. You can see the whole thing at a macro layer. I'm sure it takes time though.
Mathematics is also written tersely but not this tersely, and nor is terse math easy to read for mathematicians.
Terse logic is also very different from terse names; how much of K brevity is just from name compression vs logical succinctness? Haskell people could also use single character names everywhere. When will they adopt the conveniences of fitting everything in as few pages as possible?
And what’s the point of fitting as much content as you can into one eyeball when working memory can’t consume a whole page of a non-succinct language like Python?
In many cases I'd agree, but the author I'm referring to has a neat example. His APL GPU compiler doesn't have modules and multiple layers of abstractions. He has few named variables. Just a few pages of entirely data flow/parallel APL where you can see everything at the macro level. He did a show HN and several YouTube lectures on this. The abstractions hurt the ability to understand the code and made it take longer to make changes.
> It's not really meaningful to compare the readability of sentences in English versus Chinese.
it is if one speaks both languages and is qualified to comment. part of 'overconciseness' is domain/cultural experience - what is overconcise in one context is not in another.
It's not really meaningful to compare the readability of sentences in English versus Chinese. On the other hand, it's both meaningful and important to compare readability of program snippets - and readability is more than just the first-time learning burden.
Overly-concise code being difficult to maintain is a well-accepted fact. The response shouldn't be to demand fluency - that's just sticking your head in the sand.