6 ms·

J can look like APL or English

153 points by paliilap 7y ago

curiousgal 7y ago
There is something so charming about the attached video [0]. It's very reminiscent of the original APL demonstration [1] from 1975. I love it! 0.https://youtube.com/watch?v=jTeENcpUZdM https://youtube.com/watch?v=jTeENcpUZdM 1.https://youtube.com/watch?v=_DTpQ4Kk2wA https://youtube.com/watch?v=_DTpQ4Kk2wA
- paliilap 7y ago
  That 1975 APL demonstration is lovely. Much has been preserved in Dyalog and GNU APL - it's very interesting to see how timeless the core APL functions are. I'm very fond of a number of videos by the late John Scholes narrating APL solutions step by step, including the well-known demonstration of Conway's Game of Life in APL (0). His videos on depth-first search (1) and solving sudoku (2) are also brilliant. (0) https://www.youtube.com/watch?v=a9xAKttWgP4 https://www.youtube.com/watch?v=a9xAKttWgP4 (1) https://www.youtube.com/watch?v=DsZdfnlh_d0 https://www.youtube.com/watch?v=DsZdfnlh_d0 (2) https://www.youtube.com/watch?v=DmT80OseAGs https://www.youtube.com/watch?v=DmT80OseAGs
quazar 7y ago
I thought that "making J look like English" would refer to creating a DSL in it, not substituting J symbols for English keywords. But still, pretty cool.
- yowlingcat 7y ago
  Yeah, this is really cool. While the grammar remains the same, seeing something like: ``` kmc =: right (step power infinity) initialise initialise =: (left deal tally at right) from right step =: (left groupby allocate rank 1 2) then (mean every) allocate =: euclidean then (equal minimum) then indices then head euclidean =: (minus then square then sum) vectors ``` That's quite readable and compact. I'm fascinated by J now.
yiyus 7y ago
I want to like J, but I find that most of my programs get too cluttered with @: all over the place. I see the k-means example shown here has a similar problem (7 usages of @: in only 4 lines of J). I find implicit programming a more elegant paradigm, but lambdas with pre-declared argument names (like x,y,z in k or α and ω in Dyalog APL) more comfortable to work with (and, at least for the time being, more productive). I think part of the reason is that J's syntax for function composition is too heavy. In an improved visualization of J like the one shown here, I would find very interesting to try something like, for example, composition by simple juxtaposition and trains with under(or over)lining, maybe even playing with colors to indicate if verbs form a train or other composition. I understand that is a quite different problem from just substituting @: with o̲. Nevertheless, very nice work. It is interesting to see the English and APL versions next to each other. The video is also very good.
- stepvhen 7y ago
  > maybe even playing with colors to indicate if verbs form a train or other composition. I understand that is a quite different problem from just substituting @: with o̲. With regards to how different of a problem that would be, J's syntax is context-sensitive. If you were to accurately identify trains and forks, you could not use regex, and would probably end up implementing a subset of the J parser.
  - 6thaccount2 7y ago
    Charles Moore did that with Color Forth and even though only he was using it, I remember several comments on how that is unfair to the color blind or visually impaired which is an interesting point.
    - yiyus 7y ago
      ColorForth has a color-blind mode, but I do not remember the details. The main idea is to change visual representation instead of using delimiters. Different fonts or text sizes sizes or cursive/inverse/underline are also valid ways of displaying different "colors".
scottlocklin 7y ago
People who are interested in a more readable APL should have a look at Nial: https://github.com/danlm/QNial7 https://github.com/danlm/QNial7 It is a fairly standard APL which inherently uses english-like notation instead of symbols.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
robomartin 7y ago
Well, I'll be the dark cloud here. As someone who used APL professionally for a decade, having studied and interacted with many of the early APL pioneers, including Ken Iverson, everything related to J, including this article's proposal, is an absolute abomination to me. What many people lack is a sense of history. Why does something like J even exist? Do you know? I do. It was a horrible mistake on the part of Iverson in response to the limitations of the hardware issues we had to deal with at the time (think 80's). How does a man who authored a paper exalting the advantages and power of notation as a tool for thought [0], turn around and create something like J? Simple answer: Business, for the most part, and, if I am going to be benevolent, a naive attempt to bring something to the masses (while destroying APL). Here's what you had to do at the time if you wanted to run APL on IBM PC's (or clones): - Buy a specific motherboard (if it was not an original IBM PC) - Buy a specific graphics card (which really wasn't a graphics card at all, just text) - Purchase or program a character EPROM that replaced rarely used characters with APL characters - Swap out the stock character ROM with the custom EPROM - In some cases install a toggle switch outside the computer to be able to switch between APL and standard ROM's - Purchase either an IBM Selectric or pinwheel printer - Purchase an expensive character ball for your IBM printer or an equally expensive APL character for your printer - And then you had to buy your APL interpreter from a company like STSC for hundreds of 1980's dollars This meant a number of things: - APL was outside the purview of "civilians" - Normal office environments were never going to consider something like this - There was a cost and technical complexity to wanting to use APL - Installing a modified APL character EPROM broke applications that relied on the characters in the character table that were replaced (mostly characters you could use for basic drawing on a terminal) - APL was very much limited to those who absolutely-positively had to have it - That meant academia and very niche applications (financials) - Widespread adoption was pretty much impossible It is in that context that Iverson thought-up the idea of transliterating APL symbols into combinations of ASCII characters. It was a failed attempt to make things more accessible to the masses by compromising the very foundation of APL. This was very short-sighted. Computers evolved very quickly and very soon both displaying and printing APL characters was within the reach of any 15 year old with a computer. And it was a failure. Not the least of the reasons for this being that, to the average person, J code looks like ASCII vomit. APL has distinct symbols, just like mathematics. One might not be able to understand the code but the end product not only looks very different from ASCII vomit, it is. Because notation has power. The correct path would have been to understand technology would catch-up to the requirements of APL and focus on extending and improving the language. A simple example of this would be adding an object-oriented programming layer to the language. Compilation and distribution through executable files and (civilian) installation packages, which are valuable for commercial closed-source security and deployment, would also have been a valuable add-ons. I was working with Assembler, FORTH, C, and C++ at the same time I worked with APL. I could deliver executable user-installable programs in any of those languages --and sell them!-- while my use of APL was limited to a range between academic and internal tools. It would have been brilliant to have been able to deliver finished user applications indistinguishable (by the user) from those written in C or C++. That was impossible. They should have worked on that, and more. Frankly, I have been wishing, for decades now, for someone to stand on the shoulders of APL and develop it's successor. A rich SYMBOLIC language capable of allowing rich and effortless expression of ideas at an entirely different level of thought and abstraction than for-loops and indenting lines by four spaces. Anyhow, it's a soapbox. I know. Getting off it. I need to go do some useful work. [0] http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd...
segmondy 7y ago
Readable APL is like writing (125 divided by 5 then add .3) instead of (125/5)+.3 defeats the entire notation as a tool of thought.
mikl 7y ago
What is it with picking un-googleable names for programming languages? C, D, J, R, Go? Stahp.
- avmich 7y ago
  Google has a long way to go to figure out the intent of the request instead of dumb text search. I don't think creating J in 1980-s Iverson had to be bothered with that.

153 points by paliilap 7y ago

There is something so charming about the attached video [0]. It's very reminiscent of the original APL demonstration [1] from 1975. I love it! 0.https://youtube.com/watch?v=jTeENcpUZdM https://youtube.com/watch?v=jTeENcpUZdM 1.https://youtube.com/watch?v=_DTpQ4Kk2wA https://youtube.com/watch?v=_DTpQ4Kk2wA

paliilap 7y ago
That 1975 APL demonstration is lovely. Much has been preserved in Dyalog and GNU APL - it's very interesting to see how timeless the core APL functions are. I'm very fond of a number of videos by the late John Scholes narrating APL solutions step by step, including the well-known demonstration of Conway's Game of Life in APL (0). His videos on depth-first search (1) and solving sudoku (2) are also brilliant. (0) https://www.youtube.com/watch?v=a9xAKttWgP4 https://www.youtube.com/watch?v=a9xAKttWgP4 (1) https://www.youtube.com/watch?v=DsZdfnlh_d0 https://www.youtube.com/watch?v=DsZdfnlh_d0 (2) https://www.youtube.com/watch?v=DmT80OseAGs https://www.youtube.com/watch?v=DmT80OseAGs

quazar 7y ago

I thought that "making J look like English" would refer to creating a DSL in it, not substituting J symbols for English keywords. But still, pretty cool.

yowlingcat 7y ago
Yeah, this is really cool. While the grammar remains the same, seeing something like: ``` kmc =: right (step power infinity) initialise initialise =: (left deal tally at right) from right step =: (left groupby allocate rank 1 2) then (mean every) allocate =: euclidean then (equal minimum) then indices then head euclidean =: (minus then square then sum) vectors ``` That's quite readable and compact. I'm fascinated by J now.

yiyus 7y ago

I want to like J, but I find that most of my programs get too cluttered with @: all over the place. I see the k-means example shown here has a similar problem (7 usages of @: in only 4 lines of J). I find implicit programming a more elegant paradigm, but lambdas with pre-declared argument names (like x,y,z in k or α and ω in Dyalog APL) more comfortable to work with (and, at least for the time being, more productive). I think part of the reason is that J's syntax for function composition is too heavy. In an improved visualization of J like the one shown here, I would find very interesting to try something like, for example, composition by simple juxtaposition and trains with under(or over)lining, maybe even playing with colors to indicate if verbs form a train or other composition. I understand that is a quite different problem from just substituting @: with o̲. Nevertheless, very nice work. It is interesting to see the English and APL versions next to each other. The video is also very good.

stepvhen 7y ago
> maybe even playing with colors to indicate if verbs form a train or other composition. I understand that is a quite different problem from just substituting @: with o̲. With regards to how different of a problem that would be, J's syntax is context-sensitive. If you were to accurately identify trains and forks, you could not use regex, and would probably end up implementing a subset of the J parser.
- 6thaccount2 7y ago
  Charles Moore did that with Color Forth and even though only he was using it, I remember several comments on how that is unfair to the color blind or visually impaired which is an interesting point.
  - yiyus 7y ago
    ColorForth has a color-blind mode, but I do not remember the details. The main idea is to change visual representation instead of using delimiters. Different fonts or text sizes sizes or cursive/inverse/underline are also valid ways of displaying different "colors".

scottlocklin 7y ago

People who are interested in a more readable APL should have a look at Nial: https://github.com/danlm/QNial7 https://github.com/danlm/QNial7 It is a fairly standard APL which inherently uses english-like notation instead of symbols.

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

robomartin 7y ago

Well, I'll be the dark cloud here. As someone who used APL professionally for a decade, having studied and interacted with many of the early APL pioneers, including Ken Iverson, everything related to J, including this article's proposal, is an absolute abomination to me. What many people lack is a sense of history. Why does something like J even exist? Do you know? I do. It was a horrible mistake on the part of Iverson in response to the limitations of the hardware issues we had to deal with at the time (think 80's). How does a man who authored a paper exalting the advantages and power of notation as a tool for thought [0], turn around and create something like J? Simple answer: Business, for the most part, and, if I am going to be benevolent, a naive attempt to bring something to the masses (while destroying APL). Here's what you had to do at the time if you wanted to run APL on IBM PC's (or clones): - Buy a specific motherboard (if it was not an original IBM PC) - Buy a specific graphics card (which really wasn't a graphics card at all, just text) - Purchase or program a character EPROM that replaced rarely used characters with APL characters - Swap out the stock character ROM with the custom EPROM - In some cases install a toggle switch outside the computer to be able to switch between APL and standard ROM's - Purchase either an IBM Selectric or pinwheel printer - Purchase an expensive character ball for your IBM printer or an equally expensive APL character for your printer - And then you had to buy your APL interpreter from a company like STSC for hundreds of 1980's dollars This meant a number of things: - APL was outside the purview of "civilians" - Normal office environments were never going to consider something like this - There was a cost and technical complexity to wanting to use APL - Installing a modified APL character EPROM broke applications that relied on the characters in the character table that were replaced (mostly characters you could use for basic drawing on a terminal) - APL was very much limited to those who absolutely-positively had to have it - That meant academia and very niche applications (financials) - Widespread adoption was pretty much impossible It is in that context that Iverson thought-up the idea of transliterating APL symbols into combinations of ASCII characters. It was a failed attempt to make things more accessible to the masses by compromising the very foundation of APL. This was very short-sighted. Computers evolved very quickly and very soon both displaying and printing APL characters was within the reach of any 15 year old with a computer. And it was a failure. Not the least of the reasons for this being that, to the average person, J code looks like ASCII vomit. APL has distinct symbols, just like mathematics. One might not be able to understand the code but the end product not only looks very different from ASCII vomit, it is. Because notation has power. The correct path would have been to understand technology would catch-up to the requirements of APL and focus on extending and improving the language. A simple example of this would be adding an object-oriented programming layer to the language. Compilation and distribution through executable files and (civilian) installation packages, which are valuable for commercial closed-source security and deployment, would also have been a valuable add-ons. I was working with Assembler, FORTH, C, and C++ at the same time I worked with APL. I could deliver executable user-installable programs in any of those languages --and sell them!-- while my use of APL was limited to a range between academic and internal tools. It would have been brilliant to have been able to deliver finished user applications indistinguishable (by the user) from those written in C or C++. That was impossible. They should have worked on that, and more. Frankly, I have been wishing, for decades now, for someone to stand on the shoulders of APL and develop it's successor. A rich SYMBOLIC language capable of allowing rich and effortless expression of ideas at an entirely different level of thought and abstraction than for-loops and indenting lines by four spaces. Anyhow, it's a soapbox. I know. Getting off it. I need to go do some useful work. [0] http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd...

segmondy 7y ago

Readable APL is like writing (125 divided by 5 then add .3) instead of (125/5)+.3 defeats the entire notation as a tool of thought.

mikl 7y ago

What is it with picking un-googleable names for programming languages? C, D, J, R, Go? Stahp.

avmich 7y ago
Google has a long way to go to figure out the intent of the request instead of dumb text search. I don't think creating J in 1980-s Iverson had to be bothered with that.