4 ms·

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 r

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.

Firadeoclus 7y ago
> 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.
- 7thaccount 7y ago
  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.
  - magicalhippo 7y ago
    Layers of abstractions are useful though, they allow you to concentrate on what matters for the code in question.
    - 7thaccount 7y ago
      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.
  - threatofrain 7y ago
    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?
    - 7thaccount 7y ago
      It's more than that though. APL symbols can operate on multi-dimensional data by default.
cat199 7y ago
> 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.
yiyus 7y ago
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.
- wpietri 7y ago
  > 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.
  - geocar 7y ago
    > 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....

Firadeoclus 7y ago

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

7thaccount 7y ago
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.
- magicalhippo 7y ago
  Layers of abstractions are useful though, they allow you to concentrate on what matters for the code in question.
  - 7thaccount 7y ago
    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.
- threatofrain 7y ago
  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?
  - 7thaccount 7y ago
    It's more than that though. APL symbols can operate on multi-dimensional data by default.

cat199 7y ago

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

yiyus 7y ago

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.

wpietri 7y ago
> 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.
- geocar 7y ago
  > 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....