“This example shows clearly that there are ways of reasoning other than those which have dominated information processing for 40 years but they are, alas, still extremely rare. This difference and originality, introduced by APL, are major features. They typify the open and welcoming intellectual spirit of the people who practise it.” — FWIW, this example (+/ Salaries × Rates[Categories]) can be rewritten nearly word for word in R (Sum(Salaries*Rates[Categories])), so at least some of the ideas still have some currency.
This actually looks like Excel / 1-2-3, which is an array-based programming language that people look down on because it enables non-experts to build programs and therefore the programs are bad.
No I do not look down on Excel because it enables non-programmers to program. I look down on it, because Excel programs become an unmaintainable mess. They are hard to reason about, because they do not seperate code and representation. You can never have a nice overview of your Excel programs.
The example you gave was overly simplistic for a comparison. It's like doing one test for a benchmark comparison. Go look at Aaron Hsu's Co-Dfns parallel APL compiler and his discussions on HN and YouTube. I don't think you could easily do an R translation that isn't 10x longer.
Gotcha. I apologise btw if I sounded like a jerk (hard to tell tone on a forum). I was just trying to relay what little I've determined by playing with these languages.
I would say that pandas and R can pretty much express everything that APL/J/Q can. They are a lot slower though (than Q atleast, I haven’t used J or APL)
I don’t remember enough APL, so my examples are K:
Maximum subarray sum: |/(0|+)\
Flatten: ,//
Rank: <<
In these examples, every single character is its own operation, and they compose to give another useful operation.
Any Turing complete language can express what any other Turing complete language can (by definition). And pandas/r do provide APL’s vector and matrix operations. But not the composability, which IMHO is just as important to what this family brings to the table.
, is a function, not dissimilar to pd.concat and indeed, x,y is very similar to pd.concat([x,y])
/ is an operator. It's similar to functools.reduce.
,/ is a function, not dissimilar to pd.concat, ,/x is pd.concat(x) which is a little weird. It's tricky, but not impossible to implement functools.reduce(lambda x,y: pd.concat([y,x]), x) but I might've gotten the order of the arguments wrong.
,// is also a function. I think you can do pd.concat(x).values.flatten(), but this obviously doesn't compose. I don't see how you can implement it with another functools.reduce but maybe functools.reduce operates on dataframes after all, so maybe it's just functools.reduce(lambda x,y: pd.concat([y,x.values.flatten()]), functools.reduce(lambda x,y: pd.concat([y,x]), x)) but I have no idea: pd.concat(x).values.flatten() is shorter so I can't imagine anyone would prefer trying to make this monstrosity work.
Being "much nicer" is everything. If the syntax, and the rules for the syntactic elements means nothing, and you are fine with merely the ability to write the transformations, then you haven't thought about this clearly: VB6 is the same as Pandas since it too supports the same operations (or they can be implemented, as they can be in any turing-complete, and many non-turing-complete languages), but I find this line of thinking quite insulting: Pandas is much better for data programming than VB6, and whether you know it (or like it) or not, APL and their ilk are much better than Pandas for data programming.
The second / is converge, rather than reduce - I don’t think python (or pandas) has it in a common library - and even if it did, usage would be ultra clunky. Your description is excellent, just wanted to make it more precise.
This is like saying a Turing complete language can simulate everything another Turing complete language can. A decent sized idiomatic APL program will be very different from the same Python program only using Numpy, even if the outputs are the same.
Yes and No. Pandas does the data frame stuff and various calcs, but you need Numpy to do things like invert a matrix unless Pandas supports that as well. APL combines a lot of that in a single coherant package.
Their another downside, I guess, is that they are wildly inelegant. R is inelegant in its core, despite all the nice functionality, and Pandas, IMO, presents a rather ugly addition to the regular Python syntax despite all its nice functionality. So people still yearn for things pure and beautiful.
