4 ms·

Coincidentally, the author of this article writes code and does math mentally in Cantonese (because you can store more in your head at one time in Cantonese tha

by kick 7y ago

Coincidentally, the author of this article writes code and does math mentally in Cantonese (because you can store more in your head at one time in Cantonese than you can English), so your CJK comment might be closer than you'd think. However, APL is pretty simple. There are a lot of resources for J that are made for beginning programmers, and APL requires a different mindset than ALGOL derivatives. Try glancing at these: https://code.jsoftware.com/wiki/Books/Beginners https://code.jsoftware.com/wiki/Books/Beginners If you really want to get a pure conception of APL, though, try the book it's named after: A Programming Language. Or Notation as a Tool of Thought (here's a semi-well-digitized copy: https://www.jsoftware.com/papers/tot.htm https://www.jsoftware.com/papers/tot.htm). APL is generally readable, however a common mindset that if you come back to it in a day, a month, a year or a decade, it's faster to rewrite it than to try to figure out what you were thinking: if you can't understand what it's doing, you must have done it wrong the first time.

vidarh 7y ago
> APL is generally readable For me it seems that the big disconnect is between people who read code vs. people who pattern match code. I never read a piece of code start to finish to understand it - I glance at it and expect to see patterns, and then explore based on pattern recognition. I only read details piecemeal. That doesn't work if there are no clear visual patterns, and I'm extremely picky about syntax and layout of code as a result, not for the code to be readable, but on the contrary, for it to be possible for me to glance at a piece of code and have intuitions about it from seeing shapes of code layout laid out spatially. I'm not sure if there are reasonable ways of reconciling those two ways of looking at code.
- qznc 7y ago
  BC: Do you ever look at your own code and think, "What the hell was I doing here?" AW: No, I guess I don't. This is from an interview of Arthur Whitney (AW) who made K, an APL derivative. https://queue.acm.org/detail.cfm?id=1531242 https://queue.acm.org/detail.cfm?id=1531242
- sedachv 7y ago
  In my experience working with other programmers, it is very common for people to only learn to visually pattern match on code formatting and stop there. This is the code reading equivalent of functional illiteracy. Using = instead of ==, missing break statements, all kinds of semantically significant mistakes become completely invisible when you look at the shape of the code instead of reading to see what it does. In my experience, people who can only read code by visual layout do very poor code reviews. Another annoying thing, as you point out, is that this makes people hung up on code formatting style to an unreasonably extreme degree. People who only learn to look at the layout literally cannot "read" an unfamiliar layout, which tends to frustrate them, and in a lot of cases seems to hurt their ego, because their conception of themselves as competent programmers is challenged. The way to "reconcile" that is to learn to read code for its meaning.
  - vidarh 7y ago
    What you find 'annoying' I find about speeding up processing. I can 'pattern match' code far faster than I can read the text, so the alternative where I read every token is to dramatically slow down my mental processing of the code. To me, reading every token is the functional illiteracy, the way only new learners spell their way through each word of a natural language. I've never seen people make it to the point where they pattern match without being capable of reading the language properly. I slow down and read everything when I need the details, the way I slow down when I read an unfamiliar word, or when I need to ensure I get every detail of a complex paragraph. But most of the time reading at character or even word level is a waste of time. Unless you're dealing with a language like J or K etc. that doesn't lend itself to visual matching. To me that is a fundamental problem with those languages. But I get that people who program them tend to read token by token instead, and if that is what you want to do it needs to be compact.
    - sedachv 7y ago
      > I can 'pattern match' code far faster than I can read the text No you can't. You are getting the impression that you understand what the code does from its shape. This works only when the code does what you already assume it does before you start reading the code.

by kick 7y ago

vidarh 7y ago

> APL is generally readable For me it seems that the big disconnect is between people who read code vs. people who pattern match code. I never read a piece of code start to finish to understand it - I glance at it and expect to see patterns, and then explore based on pattern recognition. I only read details piecemeal. That doesn't work if there are no clear visual patterns, and I'm extremely picky about syntax and layout of code as a result, not for the code to be readable, but on the contrary, for it to be possible for me to glance at a piece of code and have intuitions about it from seeing shapes of code layout laid out spatially. I'm not sure if there are reasonable ways of reconciling those two ways of looking at code.

qznc 7y ago
BC: Do you ever look at your own code and think, "What the hell was I doing here?" AW: No, I guess I don't. This is from an interview of Arthur Whitney (AW) who made K, an APL derivative. https://queue.acm.org/detail.cfm?id=1531242 https://queue.acm.org/detail.cfm?id=1531242
sedachv 7y ago
In my experience working with other programmers, it is very common for people to only learn to visually pattern match on code formatting and stop there. This is the code reading equivalent of functional illiteracy. Using = instead of ==, missing break statements, all kinds of semantically significant mistakes become completely invisible when you look at the shape of the code instead of reading to see what it does. In my experience, people who can only read code by visual layout do very poor code reviews. Another annoying thing, as you point out, is that this makes people hung up on code formatting style to an unreasonably extreme degree. People who only learn to look at the layout literally cannot "read" an unfamiliar layout, which tends to frustrate them, and in a lot of cases seems to hurt their ego, because their conception of themselves as competent programmers is challenged. The way to "reconcile" that is to learn to read code for its meaning.
- vidarh 7y ago
  What you find 'annoying' I find about speeding up processing. I can 'pattern match' code far faster than I can read the text, so the alternative where I read every token is to dramatically slow down my mental processing of the code. To me, reading every token is the functional illiteracy, the way only new learners spell their way through each word of a natural language. I've never seen people make it to the point where they pattern match without being capable of reading the language properly. I slow down and read everything when I need the details, the way I slow down when I read an unfamiliar word, or when I need to ensure I get every detail of a complex paragraph. But most of the time reading at character or even word level is a waste of time. Unless you're dealing with a language like J or K etc. that doesn't lend itself to visual matching. To me that is a fundamental problem with those languages. But I get that people who program them tend to read token by token instead, and if that is what you want to do it needs to be compact.
  - sedachv 7y ago
    > I can 'pattern match' code far faster than I can read the text No you can't. You are getting the impression that you understand what the code does from its shape. This works only when the code does what you already assume it does before you start reading the code.