5 ms·

I love small languages (lisps, forths, apls) and think that there is much to learn from them, but you need an open mind. You need to start from zero and totally

by yiyus 7y ago

I love small languages (lisps, forths, apls) and think that there is much to learn from them, but you need an open mind. You need to start from zero and totally forget your ALGOL-mindset while you are learning the new paradigm. It's like learning Chinese. Everyone learns it in China, and everyone there will tell you that it's perfectly readable and you don't need to be extraordinarily intelligent to speak it. But if you expect to figure it out based on your knowledge of English, it will be terribly frustrating. This does not mean that German or Dutch (which share roots with English) are better languages, or even easier to learn. Do not expect your Chinese teacher to give you a different answer from "these weird symbols are just what we do; deal with it". This article is quite good. Clearly the author understand your reservations and he is saying: give it a try and it will click. The learning material might be better, but it's there (start with Iverson and work from that). It's much easier than learning Chinese!

ivanbakel 7y ago
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....
smallnamespace 7y ago
> Everyone learns it in China, and everyone there will tell you that it's perfectly readable and you don't need to be extraordinarily intelligent to speak it. I'm not sure Chinese is necessarily a good example for the point you're trying to make. Native Chinese speakers _probably_ spend more effort acquiring full competency in Chinese than native English speakers need to learn English. For one thing, reading and writing is harder to learn, even for natives (source: am Chinese and haven't acquired full literacy, despite years of half-hearted effort). English is generally easier to learn, not only for German and Dutch speakers, but for most people in the world who speak languages that are unrelated to both of them. One hypothesis[1] is that English has been learned by foreigners multiple times in the past and slowly lost it's more difficult native features (noun declension, many forms of inflection). Chinese has tones, which are rare amongst world languages and, as many learners will tell you, difficult to achieve proficiency with as as an adult. On a practical level, the British and Americans have had hegemonic influence over the world for about 2-3 centuries, so many idioms and concepts in the language will be familiar to a learner; less so Chinese, which is far more coupled to the culture of China and its history. Like, every schoolchild in China learns a bit of Tang poetry as part of their education, and 成語 idioms are part of daily speech across all social classes. https://en.wikipedia.org/wiki/Middle_English_creole_hypothesis https://en.wikipedia.org/wiki/Middle_English_creole_hypothes...
- gnulinux 7y ago
  > hypothesis[1] is that English has been learned by foreigners multiple times in the past and slowly lost it's more difficult native features (noun declension, many forms of inflection). The claim that noun declension and inflection is harder to learn isn't well founded. If your native language has these, it'll be more natural for you. All languages have semantic declension and inflection, in the sense that context signals the kind of each word even if it's not syntactically inflected. For example in English the position of the word can signal whether a word is an object or subject "John hit Sally" vs "Sally hit John", the order of John and Sally signals who hit whom. In an agglutinate language you could signal this by putting a prefix like "John hit Sallyum" or "Sallyum hit John" would be parsed the same. My native language is Turkish, I've been learning English since I was 5 years old, but this "order matters" thing eternally confused me. It doesn't make sense to me when people say suffixes are more confusing than this order thing.
kazinator 7y ago
Lisps (the real ones, at least that rightfully use the name) do not belong into this lunatic fringe category; they support Algol-style programming. Aside from the prefix syntax, a lot of the concepts are familiar. Microsoft's sample application "Your First Windows Program", written in C, using Win32 calls, can be translated into TXR Lisp literally, almost expression for expression: https://docs.microsoft.com/en-us/windows/win32/learnwin32/your-first-windows-program https://docs.microsoft.com/en-us/windows/win32/learnwin32/yo... The "meat" part, without the FFI declarations that precede it: (defun WindowProc (hwnd uMsg wParam lParam) (caseql* uMsg (WM_DESTROY (PostQuitMessage 0) 0) (WM_PAINT (let* ((ps (new PAINTSTRUCT)) (hdc (BeginPaint hwnd ps))) (FillRect hdc ps.rcPaint (cptr-int (succ COLOR_WINDOW) 'HBRUSH)) (EndPaint hwnd ps) 0)) (t (DefWindowProc hwnd uMsg wParam lParam)))) (let* ((hInstance (GetModuleHandle nil)) (wc (new WNDCLASS lpfnWndProc [wndproc-fn WindowProc] hInstance hInstance lpszClassName "Sample Window Class"))) (RegisterClass wc) (let ((hwnd (CreateWindowEx 0 wc.lpszClassName "Learn to Program Windows" WS_OVERLAPPEDWINDOW CW_USEDEFAULT CW_USEDEFAULT CW_USEDEFAULT CW_USEDEFAULT NULL NULL hInstance NULL))) (unless (equal hwnd NULL) (ShowWindow hwnd SW_SHOWDEFAULT) (let ((msg (new MSG))) (while (GetMessage msg NULL 0 0) (TranslateMessage msg) (DispatchMessage msg)))))) Full code here: https://www.nongnu.org/txr/rosetta-solutions-main.html#Window%20creation https://www.nongnu.org/txr/rosetta-solutions-main.html#Windo... If you look at this and the C side by side, you can easily see where the parts match up.

by yiyus 7y ago

ivanbakel 7y ago

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

smallnamespace 7y ago

> Everyone learns it in China, and everyone there will tell you that it's perfectly readable and you don't need to be extraordinarily intelligent to speak it. I'm not sure Chinese is necessarily a good example for the point you're trying to make. Native Chinese speakers _probably_ spend more effort acquiring full competency in Chinese than native English speakers need to learn English. For one thing, reading and writing is harder to learn, even for natives (source: am Chinese and haven't acquired full literacy, despite years of half-hearted effort). English is generally easier to learn, not only for German and Dutch speakers, but for most people in the world who speak languages that are unrelated to both of them. One hypothesis[1] is that English has been learned by foreigners multiple times in the past and slowly lost it's more difficult native features (noun declension, many forms of inflection). Chinese has tones, which are rare amongst world languages and, as many learners will tell you, difficult to achieve proficiency with as as an adult. On a practical level, the British and Americans have had hegemonic influence over the world for about 2-3 centuries, so many idioms and concepts in the language will be familiar to a learner; less so Chinese, which is far more coupled to the culture of China and its history. Like, every schoolchild in China learns a bit of Tang poetry as part of their education, and 成語 idioms are part of daily speech across all social classes. https://en.wikipedia.org/wiki/Middle_English_creole_hypothesis https://en.wikipedia.org/wiki/Middle_English_creole_hypothes...

gnulinux 7y ago
> hypothesis[1] is that English has been learned by foreigners multiple times in the past and slowly lost it's more difficult native features (noun declension, many forms of inflection). The claim that noun declension and inflection is harder to learn isn't well founded. If your native language has these, it'll be more natural for you. All languages have semantic declension and inflection, in the sense that context signals the kind of each word even if it's not syntactically inflected. For example in English the position of the word can signal whether a word is an object or subject "John hit Sally" vs "Sally hit John", the order of John and Sally signals who hit whom. In an agglutinate language you could signal this by putting a prefix like "John hit Sallyum" or "Sallyum hit John" would be parsed the same. My native language is Turkish, I've been learning English since I was 5 years old, but this "order matters" thing eternally confused me. It doesn't make sense to me when people say suffixes are more confusing than this order thing.

kazinator 7y ago

Lisps (the real ones, at least that rightfully use the name) do not belong into this lunatic fringe category; they support Algol-style programming. Aside from the prefix syntax, a lot of the concepts are familiar. Microsoft's sample application "Your First Windows Program", written in C, using Win32 calls, can be translated into TXR Lisp literally, almost expression for expression: https://docs.microsoft.com/en-us/windows/win32/learnwin32/your-first-windows-program https://docs.microsoft.com/en-us/windows/win32/learnwin32/yo... The "meat" part, without the FFI declarations that precede it: (defun WindowProc (hwnd uMsg wParam lParam) (caseql* uMsg (WM_DESTROY (PostQuitMessage 0) 0) (WM_PAINT (let* ((ps (new PAINTSTRUCT)) (hdc (BeginPaint hwnd ps))) (FillRect hdc ps.rcPaint (cptr-int (succ COLOR_WINDOW) 'HBRUSH)) (EndPaint hwnd ps) 0)) (t (DefWindowProc hwnd uMsg wParam lParam)))) (let* ((hInstance (GetModuleHandle nil)) (wc (new WNDCLASS lpfnWndProc [wndproc-fn WindowProc] hInstance hInstance lpszClassName "Sample Window Class"))) (RegisterClass wc) (let ((hwnd (CreateWindowEx 0 wc.lpszClassName "Learn to Program Windows" WS_OVERLAPPEDWINDOW CW_USEDEFAULT CW_USEDEFAULT CW_USEDEFAULT CW_USEDEFAULT NULL NULL hInstance NULL))) (unless (equal hwnd NULL) (ShowWindow hwnd SW_SHOWDEFAULT) (let ((msg (new MSG))) (while (GetMessage msg NULL 0 0) (TranslateMessage msg) (DispatchMessage msg)))))) Full code here: https://www.nongnu.org/txr/rosetta-solutions-main.html#Window%20creation https://www.nongnu.org/txr/rosetta-solutions-main.html#Windo... If you look at this and the C side by side, you can easily see where the parts match up.