
Notation as a Tool of Thought (1979) - ehudla
http://www.jsoftware.com/papers/tot.htm
======
kaoD
Slightly unrelated: I often find myself in the browser console, exploring data
scraped off webpages (often from Wikipedia tables). I think REPLs are another
kind of "tool of thought". E.g.: I recently scraped my country's election
results off Wikipedia to see how voting areas affected the distribution of
seats. Very insightful.

Being tightly integrated to the browser offers the whole web as a data set.
Unfortunately JavaScript does not lend itself very well to data analysis.

What is your tool of choice for interactive data exploration?

I've been looking for something similar for my phone, a sort of calculator-on-
steroids even if not web-scraping ready. J for Android[0] fits the bill
perfectly... except the language itself seems to get in the way with its short
mnemonics, unrememberable verb train rules, function composition words and
other weirdness in the construction of tacit phrases. I've (partially) learned
and forgotten J three times already. Every single time I come back is like
starting anew.

I tried Clojure too but the Android REPL[1] is stuck on Clojure 1.4.0 and the
lack of an S-expression enabled keyboard/editor makes it a pain to code.

Any recommendations in this area?

[0] [http://www.jsoftware.com/](http://www.jsoftware.com/)

[1]
[https://play.google.com/store/apps/details?id=com.sattvik.cl...](https://play.google.com/store/apps/details?id=com.sattvik.clojure_repl&hl=en)

~~~
qwertyuiop924
My goto tool for data analysis is AWK: it's not interactive, but it's
succinct, and _very_ good at handling DSV data.

As for handling non DSV data... I dunno. Lisp is pretty nice for this, but
it's a pain to get the data into the system. TXR and its lisp dialect are
pretty good with this, so that's an option.

But if you really want to handle tabular data interactively, doing
manipulation and analysis on the fly... that's quite literally what Excel was
designed for.

~~~
kazinator
Speaking of Awk and TXR, TXR Lisp has an awk macro (introduced in mid 2016),
with which you can transliterate many kinds of Awk programs.

However, it's a lot slower than GNU Awk.

You don't get the duck typing of Awk (whereby strings that look like numbers
can be treated arithmetically, and nonexistent or blank variables are zero,
_et cetera_ ). To convert fields to numbers with reasonable succinctness, an
"awk local macro" called fconv (field convert) is provided.

There is no function-for-function compatibility with the Awk or GNU Awk
library, and regular expressions are TXR: that means no register capture, and
^ and $ done with functional combinators.

~~~
qwertyuiop924
...Does it by any chance resemble the SCSH awk macro?

~~~
kazinator
In some superficial ways it does, like the basic clause structure.

"Prior art" I was well aware of is cl-awk.

This awk macro was intended to be a detailed implementation of the Awk
paradigm (with some GNU extensions), complete with obscure features like
assigning to the nf variable to change the number of fields (extending with
empty strings if the new count is larger), and a working regex-based record
separation via the rs variable.

I see Shrivers implemented something that's on my TODO list: variants of
ranges that exclude the start, end or both. However, he didn't lift the
restriction that Awk ranges do not combine with other conditions, including
ranges.

------
yummyfajitas
If anyone is interested in a more readable version of APL, I think
python/numpy qualifies. Their first few examples can be expressed the same way
in standard numpy:

    
    
        arange(6) # Same as ⍳5
        add.reduce(arange(6)) # Same as +/⍳5
        add.accumulate(arange(6)) # Same as +\⍳5
    

I've gone partway through this document (up to chapter 3, plus skimming other
bits) and have not found any examples that don't translate into standard numpy
code.

From what I can tell, the core learning one takes from J/K/etc is the concept
of an array language and treating arrays as first class objects. And nowadays
Python/R/Julia provide this same functionality in a more verbose/more
readable/more mainstream package.

~~~
_mhr_
It'd be a fun project to write a an APL-like that compiles down to NumPy.
Would it be pointless? Another interesting project might be to make an APL-
like for probabilistic programming.

~~~
3JPLW
There's a start for this in Julia[0], where custom string literals mean that
you can actually write APL in native Julia:

    
    
        julia> apl"ι5"
        1:5
    
        julia> apl"+/ι5"
        15
    

You can even just get the function that represents the `+/` operation and
apply it to any Julia object:

    
    
        julia> apl"+/"(rand(100))
        52.17866879741195
    

0\. [https://github.com/shashi/APL.jl](https://github.com/shashi/APL.jl)

------
gardano
Musician checking in. Reading music in the original notation I have found to
be particularly enlightening.

Where the manuscript writer (or print publisher) chose to put bar lines, for
instance, can give clues as to intent in performance. I'm thinking
specifically about Venetian publishers in the 17th century -- but there are
plenty of other examples.

Notation can be incredibly important when trying to discern intent in some
disciplines.

~~~
gkya
Would you mind to elaborate a bit more? Seems to be very interesting fact.

~~~
gardano
Picture a piece for 3 players -- 2 soprano instruments and Basso Continuo (a
bass instrument + let's say, harpsichord). It's a piece with a recurring
harmonic structure; say, Passamezzo or ciacona -- think Pachelbel Canon.

The BC in this particular instance might only have barlines every 8 measures.
The soprano parts might have barlines every 8 measures too, but might also
have them where a significant change to _their_ melodies change. Like, when a
flurry of 16th notes begin to crop up.

Now, this isn't always the case -- it's definitely inconsistent, but such
things show up enough that those hints cannot be discounted at all, and seem
to be enough of a performance hint to at least be noted and appreciated by the
performer.

------
mayoff
The year in the title should be 1979, not 2009. This was Ken Iverson's Turing
Award lecture in 1979.

~~~
mcnamaratw
Yep, here's a link
[http://delivery.acm.org/10.1145/1290000/1283935/a1979-iverso...](http://delivery.acm.org/10.1145/1290000/1283935/a1979-iverson.pdf?ip=74.67.70.223&id=1283935&acc=OPEN&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E6D218144511F3437&CFID=877503238&CFTOKEN=71658640&__acm__=1482010216_fe163a736ce0fea424a133c4270ef743)

------
qwertyuiop924
Ah, yes. The paper that taught the world about the marvels of APL. Which is a
pretty cool language, and definitely on my "to learn" list.

APL's unofficial slogan, by the way, is "and you thought Perl was executable
linenoise." :-)

~~~
imglorp
I took a numerical methods in APL class way back. Nothing we did took more
than half a line, ever.

~~~
JosephHatfield
[]pw <\- 80?

