
J can look like APL or English - paliilap
https://wjmn.github.io/posts/j-can-look-like-apl.html
======
yiyus
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
> 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
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
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".

~~~
6thaccount2
Yes I remember that reply which came from him, but forgot to mention. It is an
interesting idea.

------
curiousgal
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
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)

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

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

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

------
robomartin
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.pd...](http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf)

~~~
jodrellblank
_having studied and interacted with many of the early APL pioneers, including
Ken Iverson, [..] Why does something like J even exist? Do you know? I do._

From reading, because the glyphs were too hard to deal with in a pre-Unicode
world. Too hard to type, to display and to print. J was intended to be ASCII
based, column-first and play more with natural language grammar features. But
I have wondered, was Ken Iverson happy with J? Did he _like_ it? Regret it? Is
there any record of anyone asking him or him discussing or writing about this?

 _Frankly, I have been wishing, for decades now, for someone to stand on the
shoulders of APL and develop its 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._

What properties might this have?

A brief touch of APL has left me chiding mainstream languages for not having
vector/collection oriented transforms, and for not having a core of carefully
thought out compose-able symbols for common operations. But it has also shown
me a view of people having to work around APL's limitations. The whole
environment feels a little like watching Prof Kernighan demonstrating a Unix
pipeline to spellcheck a document from a text file of known words in the
1970s, and being impressed that it happened, but comparing it to a
probabalistic context-aware spelling and grammar checker today and thinking
"you couldn't build that with a shell pipeline" \- but with my dim view, I'm
not able to see much room for a notation which is significantly better across
(m)any domains without just being "build your own DSL". Even APL
implementations don't agree on the exact behaviour of the core APL functions.
I believe NARS2000 and Dyalog handle ⊆, ⊃, ↓, ↑ differently. How much room is
there for a notation to be bigger and more capable but still agreeable to
enough people?

What does " _effortless expression of ideas at an entirely different level of
thought_ " mean in concrete terms? What level? What ideas? I'm enticed, but
unseeing.

 _Compilation and distribution through executable files_

Dyalog APL can make executable files. The main catch is that you need a
license to run them, as well as a license to develop them. There seems to be
no way to buy a Dyalog APL license then distribute free (unpriced)
executables. They have an object system, and .Net integration, and have been
filling in some of the symbol combinations over the years - as a beginner I
can't really comment on that except iota underbar is now a builtin function.

~~~
avmich
One of core things (ideas, requirements) in APL is to make mathematical
notation in one line.

Another thing (restriction) was to use available hardware. So some symbols
were created in a way which was possible to achieve with teletypes of the
days.

It's possible one should start with careful (re-)reading of "A programming
language".

And maybe we should think once again about the power of the whiteboard and how
we could express that into an executable language.

~~~
robomartin
Right! Some of the characters were over-types! The teletype would print one
standard character, advance to to the next position, then backup to the
character it just printed and over-print it with a second. The quote-quad is
an example of this. It would print a quote and then backup and print a
rectangle standard drawing character over it.

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

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

