7 ms·

APL and J (2015)

83 points by kick 7y ago

xelxebar 7y ago
Always excited to see APL/J content on the top page. Happily, this coincides with a brand new release of the J interpreter, namely J901. It's so new that the homepage[0] still claims 901 is in beta. The install page[1], however, does have up to date information. If you would like to taste a bit of the difference before deciding to jump in, Aaron Hsu has a really interesting talk[2] that compares APL and "other" languages via the lens of Human-Computer Interfaces. I am just beginning my journey into J, but so far it has been extremely rewarding. Head on over to #jsoftware on Freenode. The channel is super small, but has some really friendly and helpful people on it! [0]:https://jsoftware.com/indexno.html https://jsoftware.com/indexno.html [1]:https://code.jsoftware.com/wiki/System/Installation https://code.jsoftware.com/wiki/System/Installation [2]:https://www.youtube.com/watch?v=v7Mt0GYHU9A https://www.youtube.com/watch?v=v7Mt0GYHU9A
- gmfawcett 7y ago
  I'm a J newbie, but I've been using J901 to do the Advent of Code challenge this year. I'm surprised at how pleasant it's been to work with. Some of the AoC solutions have been so straightforward that I wonder if the AoC author used an array language to design the puzzles in the first place. :) It's not all roses! The error messages can be quite inscrutable sometimes, and I can't seem to get the J901 debugging tools working (except for old-fashioned print-debugging). But overall J is a charming (if quirky) language, and well suited for a bit of low-risk exploratory programming.
  - pmoriarty 7y ago
    I remember a year or two ago I was struggling with an AoC problem, and the best I could come up with in Python was a one or two hundred line program. Then I saw an answer for it in about 20 characters of J. That was impressive, though I do still wonder how readable the language is in practical every day programming, as opposed to toy problems in a programming contest.
    - icen 7y ago
      I can't speak to j, but using q, its cousin, at work looks quite a lot more like the graph APL posted above. It's spread out over several lines, and heavily commented. Most problems are also much simpler, and don't require any heavy one-liners.
      - kick 7y ago
        For readers who are unaware of what q is, it's a language on top of Arthur Whitney's k, made to be accessible to your average human, and mostly for SQL queries. I don't think Arthur is as passionate about it as he is k, and he barely has anything posted on it. It's great in some ways but usually lags behind k for people familiar with array languages.
    - kick 7y ago
      J is incredibly readable. For example, here's an (old) implementation of 2048 in it that's fairly small: https://github.com/tikkanz/2048 https://github.com/tikkanz/2048
    - gmfawcett 7y ago
      True. I'm not sure how I'd feel about maintaining a 2,000+ line J codebase. It definitely feels like a "programming-in-the-small" kind of language. It is impressive how much logic you can fit into so few characters. Even other terse languages (e.g. Haskell) seem wordy in comparison. Of course this is especially true when the problem has a fairly natural array representation, and that might not be true for many real-world problems. I haven't tried it, but I feel that a literate-programming style might work well for J. The code itself is very dense, so I think it might work well to have a long-ish, plain-text explanatory document with bits of J interspersed throughout it.
      - chongli 7y ago
        Perhaps the approach to maintaining a large codebase of terse code (such as J) is to keep the files very small and narrow in focus. This could end up very similar to a Unix userland code tree. Of course, lots of documentation could also help. Maybe a style similar to R/Python notebooks would work.
  - darkkindness 7y ago
    Remarkable, I've also been learning J901 for AoC. I'm curious, what resources have you been using to learn?
    - gmfawcett 7y ago
      Hey, small world! :) I hope that you're enjoying it, too. Mostly I've just been using the articles and resources on the J Wiki. But I found it useful to skim through the free book, "Mastering Dyalog APL" [1] -- of course the languages aren't identical, but they're similar enough that many of the APL examples were instructive. I also have the NuVoc page on speed-dial. :) I have definitely not memorized all of those crazy verbs yet! [1] https://www.dyalog.com/uploads/documents/MasteringDyalogAPL.pdf https://www.dyalog.com/uploads/documents/MasteringDyalogAPL.... [2] https://code.jsoftware.com/wiki/NuVoc https://code.jsoftware.com/wiki/NuVoc
    - xelxebar 7y ago
      For whatever it's worth, there's also the older Voc[0] documentation which NuVoc is a rewrite and expansion on. The former is a heck of a lot terser and dryer, but I prefer it as a compact reference. The Voc reads more like a graduate math text, where each example serves to illustrate (often non-obvious) uses or interactions with other primitives. This means it requires careful reading, which I personally find helps me learn better. The NuVoc, on the other hand, has a lot more in the way of straightforward examples along with extensive expository prose and hyperlinking. J has somewhat peculiar terminology. This probably helps to avoid the pitfalls of overloading more familiar terms with J-nuanced meaning. Anyway, to make any headway with eithe Voc or NuVoc, one should at least be familiar with the Absolutely Essential Terminology[1]. For me, personally, that's about all the documentation I use. The mailing lists[2] are quite active, and some of the early founders of APL and J even interact extensively with beginers! Highly recommended. There are also a lot of Essays[3] that illustrate high quality J code via solving specific problems. The book "At Play With J"[4] is also a really fun read, even if you have to keep NuVoc by your side. Then, of course, there is the IRC channel. Those have been my primary sources of learning. Hope it helps! [0]:https://www.jsoftware.com/help/dictionary/vocabul.htm https://www.jsoftware.com/help/dictionary/vocabul.htm [1]:https://code.jsoftware.com/wiki/Vocabulary/AET https://code.jsoftware.com/wiki/Vocabulary/AET [2]:https://code.jsoftware.com/wiki/System/Forums https://code.jsoftware.com/wiki/System/Forums [3]:https://code.jsoftware.com/wiki/Essays https://code.jsoftware.com/wiki/Essays [4]:https://code.jsoftware.com/wiki/At_Play_With_J https://code.jsoftware.com/wiki/At_Play_With_J
pavlov 7y ago
"J might overly encourage programmers to use arrays when another data structure would be a better fit." I feel this is actually a distinct advantage of the APL/J model: it eliminates boring data structure bikeshedding. If I were Supreme Dictator of Tech, I'd mandate APL as the language for all whiteboard interviews. Everyone would have learn it, but at least it would be far more interesting to study than the "Leetcode / Cracking the Code Interview" type material that's currently being prescribed.
- dalke 7y ago
  I deal with sparse graph data structures a lot, as molecular graphs, with a maximum degree of about 5. While graphs can be represented as an adjacency matrix, many of the algorithms become suboptimal in that representation, eg, finding the list of 1-away neighbors becomes an O(n) operation rather than O(1), in the number of nodes. Now, I'm not saying that these graphs or algorithms can't be represented in APL. But, as an example, consider the problem of how to find strongly connected components in a graph, which is something that is not an unreasonable interview topic for an intermediate developer in my field. An implementation for Dyalog APL is at https://dfns.dyalog.com/c_scc.htm https://dfns.dyalog.com/c_scc.htm with commentary at https://dfns.dyalog.com/n_scc.htm https://dfns.dyalog.com/n_scc.htm . It requires about 30 lines of code, starting: scc←{⎕ML←1 ⍝ Strongly connected components. ⍝ (Tarjan) loop←{ ⍝ for each vertex in graph G vert←{⍺ conn⍣(0=X ⍺⊃⍵)⊢⍵} ⍝ connection of unvisited vertex ⍺ ⊃vert/(⌽⍳⍴G),⊂⍵ ⍝ for each vertex in G } ⍝ :: T ← ∇ T conn←{v←⍺ ⍝ connection of vertex v T0←v trace ⍵ ⍝ optional tracing T1←x1 v push v Lx v Xx T0 ⍝ successor state for x S L and X T2←↑{w←⍺ ⍝ edge v → w min_L←{(⍺ w⊃⍵)⌊@(⊂L v)⊢⍵} ⍝ L[v] ⌊← ⍺[w] 0=X w⊃⍵:L min_L w conn ⍵ ⍝ w not connected: depth-first trav X min_L⍣(w∊S⊃⍵)⊢⍵ ⍝ low-link if w on stack }/(⌽v⊃G),⊂T1 ⍝ for each edge from vertex v root←(L v⊃T2)=X v⊃T2 ⍝ is a root vertex? v comp⍣root⊢T2 ⍝ new component if root } ⍝ :: T ← v ∇ T ... The pseuocode on the Tarjan's strongly connected components algorithm Wikipedia page (not counting "end if", "end for", etc. lines) is shorter. One Python implementation is at https://codereview.stackexchange.com/questions/46832/strongly-connected-components-algorithm https://codereview.stackexchange.com/questions/46832/strongl... where you can see it's slightly shorter than the APL version and - I argue - easier to understand. Now, the APL commentary page points out: > Nick Nikolov provides this alternative one-liner, which uses the transitive closure of the adjacency matrix (see →Graphs←). scc←{(∪⍳⊢)↓∧∘⍉⍨∨.∧⍨⍣≡i∘.∊⍵,¨i←⍳≢⍵} ⍝ · · · · · i←⍳≢⍵ vertex indices ⍝ · · · · ⍵,¨i · consider each vertex a SCC by itself ⍝ · · · i∘.∊ · · neighbour lists to adjacency matrix ⍝ · · ∨.∧⍨⍣≡ · · · transitive closure: g[x;y] ←→ path x → y ⍝ · ∧∘⍉⍨ · · · · · ... and from y to x ⍝ (∪⍳⊢)↓ · · · · · · renumbering of component numbers > The version is very good for small graphs but its space and time requirements grow rapidly as the size increases. Which, I believe (not knowing more than a trivial amount of APL) is a consequence of using an array data structure rather than something which is a better fit.
JaumeGreen 7y ago
I'd love to learn APL, all the symbols give it some mystic aura that make you feel as if you were reading a magic scroll, rather than mundane source code. OTOH J is great because it's easier to dive into, no strange keyboards needed. Also it might be one of the best language to use in a phone. With their own keyboard and a nice app, it's the first time I found that while working on advent of code problems during commute the interface was not the problem. But that language has a big big problem, it is not search friendly. Not on internet, not even on a page with solutions on different languages.
- dancek 7y ago
  I'd love to have a language that combines the notation of APL with the ergonomics of J (ie. hooks and forks enabling functional-ish programming, a de facto open source implementation and a working Android "IDE").
  - shrubble 7y ago
    There's the fully open source GNU APL which compiles on Arm Linux in addition to Linux, OpenBSD, MacOS. I don't know what is needed to get from Arm Linux to Android.
    - mlochbaum 7y ago
      dzaima/APL (https://github.com/dzaima/apl https://github.com/dzaima/apl) has an Android version. I would recommend that over GNU APL which makes a number of questionable language choices. Many modern APLs—Dyalog APL, NARS2000, ngn/apl, and dzaima/APL—include support for forks. They're usually called function trains in APL.
      - shrubble 7y ago
        Seeing as I am not an APL guru, I would appreciate your comments on the language choices that you don't agree with.
        7y ago

APL and J (2015)

83 points by kick 7y ago

Always excited to see APL/J content on the top page. Happily, this coincides with a brand new release of the J interpreter, namely J901. It's so new that the homepage[0] still claims 901 is in beta. The install page[1], however, does have up to date information. If you would like to taste a bit of the difference before deciding to jump in, Aaron Hsu has a really interesting talk[2] that compares APL and "other" languages via the lens of Human-Computer Interfaces. I am just beginning my journey into J, but so far it has been extremely rewarding. Head on over to #jsoftware on Freenode. The channel is super small, but has some really friendly and helpful people on it! [0]:https://jsoftware.com/indexno.html https://jsoftware.com/indexno.html [1]:https://code.jsoftware.com/wiki/System/Installation https://code.jsoftware.com/wiki/System/Installation [2]:https://www.youtube.com/watch?v=v7Mt0GYHU9A https://www.youtube.com/watch?v=v7Mt0GYHU9A

gmfawcett 7y ago
I'm a J newbie, but I've been using J901 to do the Advent of Code challenge this year. I'm surprised at how pleasant it's been to work with. Some of the AoC solutions have been so straightforward that I wonder if the AoC author used an array language to design the puzzles in the first place. :) It's not all roses! The error messages can be quite inscrutable sometimes, and I can't seem to get the J901 debugging tools working (except for old-fashioned print-debugging). But overall J is a charming (if quirky) language, and well suited for a bit of low-risk exploratory programming.
- pmoriarty 7y ago
  I remember a year or two ago I was struggling with an AoC problem, and the best I could come up with in Python was a one or two hundred line program. Then I saw an answer for it in about 20 characters of J. That was impressive, though I do still wonder how readable the language is in practical every day programming, as opposed to toy problems in a programming contest.
  - icen 7y ago
    I can't speak to j, but using q, its cousin, at work looks quite a lot more like the graph APL posted above. It's spread out over several lines, and heavily commented. Most problems are also much simpler, and don't require any heavy one-liners.
    - kick 7y ago
      For readers who are unaware of what q is, it's a language on top of Arthur Whitney's k, made to be accessible to your average human, and mostly for SQL queries. I don't think Arthur is as passionate about it as he is k, and he barely has anything posted on it. It's great in some ways but usually lags behind k for people familiar with array languages.
  - kick 7y ago
    J is incredibly readable. For example, here's an (old) implementation of 2048 in it that's fairly small: https://github.com/tikkanz/2048 https://github.com/tikkanz/2048
  - gmfawcett 7y ago
    True. I'm not sure how I'd feel about maintaining a 2,000+ line J codebase. It definitely feels like a "programming-in-the-small" kind of language. It is impressive how much logic you can fit into so few characters. Even other terse languages (e.g. Haskell) seem wordy in comparison. Of course this is especially true when the problem has a fairly natural array representation, and that might not be true for many real-world problems. I haven't tried it, but I feel that a literate-programming style might work well for J. The code itself is very dense, so I think it might work well to have a long-ish, plain-text explanatory document with bits of J interspersed throughout it.
    - chongli 7y ago
      Perhaps the approach to maintaining a large codebase of terse code (such as J) is to keep the files very small and narrow in focus. This could end up very similar to a Unix userland code tree. Of course, lots of documentation could also help. Maybe a style similar to R/Python notebooks would work.
- darkkindness 7y ago
  Remarkable, I've also been learning J901 for AoC. I'm curious, what resources have you been using to learn?
  - gmfawcett 7y ago
    Hey, small world! :) I hope that you're enjoying it, too. Mostly I've just been using the articles and resources on the J Wiki. But I found it useful to skim through the free book, "Mastering Dyalog APL" [1] -- of course the languages aren't identical, but they're similar enough that many of the APL examples were instructive. I also have the NuVoc page on speed-dial. :) I have definitely not memorized all of those crazy verbs yet! [1] https://www.dyalog.com/uploads/documents/MasteringDyalogAPL.pdf https://www.dyalog.com/uploads/documents/MasteringDyalogAPL.... [2] https://code.jsoftware.com/wiki/NuVoc https://code.jsoftware.com/wiki/NuVoc
  - xelxebar 7y ago
    For whatever it's worth, there's also the older Voc[0] documentation which NuVoc is a rewrite and expansion on. The former is a heck of a lot terser and dryer, but I prefer it as a compact reference. The Voc reads more like a graduate math text, where each example serves to illustrate (often non-obvious) uses or interactions with other primitives. This means it requires careful reading, which I personally find helps me learn better. The NuVoc, on the other hand, has a lot more in the way of straightforward examples along with extensive expository prose and hyperlinking. J has somewhat peculiar terminology. This probably helps to avoid the pitfalls of overloading more familiar terms with J-nuanced meaning. Anyway, to make any headway with eithe Voc or NuVoc, one should at least be familiar with the Absolutely Essential Terminology[1]. For me, personally, that's about all the documentation I use. The mailing lists[2] are quite active, and some of the early founders of APL and J even interact extensively with beginers! Highly recommended. There are also a lot of Essays[3] that illustrate high quality J code via solving specific problems. The book "At Play With J"[4] is also a really fun read, even if you have to keep NuVoc by your side. Then, of course, there is the IRC channel. Those have been my primary sources of learning. Hope it helps! [0]:https://www.jsoftware.com/help/dictionary/vocabul.htm https://www.jsoftware.com/help/dictionary/vocabul.htm [1]:https://code.jsoftware.com/wiki/Vocabulary/AET https://code.jsoftware.com/wiki/Vocabulary/AET [2]:https://code.jsoftware.com/wiki/System/Forums https://code.jsoftware.com/wiki/System/Forums [3]:https://code.jsoftware.com/wiki/Essays https://code.jsoftware.com/wiki/Essays [4]:https://code.jsoftware.com/wiki/At_Play_With_J https://code.jsoftware.com/wiki/At_Play_With_J

pavlov 7y ago

"J might overly encourage programmers to use arrays when another data structure would be a better fit." I feel this is actually a distinct advantage of the APL/J model: it eliminates boring data structure bikeshedding. If I were Supreme Dictator of Tech, I'd mandate APL as the language for all whiteboard interviews. Everyone would have learn it, but at least it would be far more interesting to study than the "Leetcode / Cracking the Code Interview" type material that's currently being prescribed.

dalke 7y ago
I deal with sparse graph data structures a lot, as molecular graphs, with a maximum degree of about 5. While graphs can be represented as an adjacency matrix, many of the algorithms become suboptimal in that representation, eg, finding the list of 1-away neighbors becomes an O(n) operation rather than O(1), in the number of nodes. Now, I'm not saying that these graphs or algorithms can't be represented in APL. But, as an example, consider the problem of how to find strongly connected components in a graph, which is something that is not an unreasonable interview topic for an intermediate developer in my field. An implementation for Dyalog APL is at https://dfns.dyalog.com/c_scc.htm https://dfns.dyalog.com/c_scc.htm with commentary at https://dfns.dyalog.com/n_scc.htm https://dfns.dyalog.com/n_scc.htm . It requires about 30 lines of code, starting: scc←{⎕ML←1 ⍝ Strongly connected components. ⍝ (Tarjan) loop←{ ⍝ for each vertex in graph G vert←{⍺ conn⍣(0=X ⍺⊃⍵)⊢⍵} ⍝ connection of unvisited vertex ⍺ ⊃vert/(⌽⍳⍴G),⊂⍵ ⍝ for each vertex in G } ⍝ :: T ← ∇ T conn←{v←⍺ ⍝ connection of vertex v T0←v trace ⍵ ⍝ optional tracing T1←x1 v push v Lx v Xx T0 ⍝ successor state for x S L and X T2←↑{w←⍺ ⍝ edge v → w min_L←{(⍺ w⊃⍵)⌊@(⊂L v)⊢⍵} ⍝ L[v] ⌊← ⍺[w] 0=X w⊃⍵:L min_L w conn ⍵ ⍝ w not connected: depth-first trav X min_L⍣(w∊S⊃⍵)⊢⍵ ⍝ low-link if w on stack }/(⌽v⊃G),⊂T1 ⍝ for each edge from vertex v root←(L v⊃T2)=X v⊃T2 ⍝ is a root vertex? v comp⍣root⊢T2 ⍝ new component if root } ⍝ :: T ← v ∇ T ... The pseuocode on the Tarjan's strongly connected components algorithm Wikipedia page (not counting "end if", "end for", etc. lines) is shorter. One Python implementation is at https://codereview.stackexchange.com/questions/46832/strongly-connected-components-algorithm https://codereview.stackexchange.com/questions/46832/strongl... where you can see it's slightly shorter than the APL version and - I argue - easier to understand. Now, the APL commentary page points out: > Nick Nikolov provides this alternative one-liner, which uses the transitive closure of the adjacency matrix (see →Graphs←). scc←{(∪⍳⊢)↓∧∘⍉⍨∨.∧⍨⍣≡i∘.∊⍵,¨i←⍳≢⍵} ⍝ · · · · · i←⍳≢⍵ vertex indices ⍝ · · · · ⍵,¨i · consider each vertex a SCC by itself ⍝ · · · i∘.∊ · · neighbour lists to adjacency matrix ⍝ · · ∨.∧⍨⍣≡ · · · transitive closure: g[x;y] ←→ path x → y ⍝ · ∧∘⍉⍨ · · · · · ... and from y to x ⍝ (∪⍳⊢)↓ · · · · · · renumbering of component numbers > The version is very good for small graphs but its space and time requirements grow rapidly as the size increases. Which, I believe (not knowing more than a trivial amount of APL) is a consequence of using an array data structure rather than something which is a better fit.

JaumeGreen 7y ago

I'd love to learn APL, all the symbols give it some mystic aura that make you feel as if you were reading a magic scroll, rather than mundane source code. OTOH J is great because it's easier to dive into, no strange keyboards needed. Also it might be one of the best language to use in a phone. With their own keyboard and a nice app, it's the first time I found that while working on advent of code problems during commute the interface was not the problem. But that language has a big big problem, it is not search friendly. Not on internet, not even on a page with solutions on different languages.

dancek 7y ago
I'd love to have a language that combines the notation of APL with the ergonomics of J (ie. hooks and forks enabling functional-ish programming, a de facto open source implementation and a working Android "IDE").
- shrubble 7y ago
  There's the fully open source GNU APL which compiles on Arm Linux in addition to Linux, OpenBSD, MacOS. I don't know what is needed to get from Arm Linux to Android.
  - mlochbaum 7y ago
    dzaima/APL (https://github.com/dzaima/apl https://github.com/dzaima/apl) has an Android version. I would recommend that over GNU APL which makes a number of questionable language choices. Many modern APLs—Dyalog APL, NARS2000, ngn/apl, and dzaima/APL—include support for forks. They're usually called function trains in APL.
    - shrubble 7y ago
      Seeing as I am not an APL guru, I would appreciate your comments on the language choices that you don't agree with.
      - 7y ago