Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Array Languages: R vs. APL (2023)

jcarroll.com.au

Post reply on HN
Print view View original

51–60 of 68 posts

Re: Array Languages: R vs. APL (2023)

#51

Post by aydyn »

mik1998 wrote: post #18
nonfamous wrote: post #10

Earlier quoted context omitted.

R itself could be considered a test of this hypothesis, too. It’s been said that elegant, powerful Lisp would be more widely adopted if it wasn’t for all those gosh-darned parenthesis. Well, at its core R is a Lisp (specifically, Scheme) but with a more traditional syntax (infixed operators, function calls, etc). And it’s fair to say the adoption of R has, indeed, been more widespread than that of Lisp.

I'm not sure I would come to this conclusion. R has some adoption, but it's also really not used as a generic programming language, which most Lisp dialects are.

That has more to do with (poor) performance, not syntax. At it's core, R's source code written in C is still very badly optimized and not performant at all.

Re: Array Languages: R vs. APL (2023)

#52

Post by nmz »

anthk wrote: post #12

J it's interesting too, without the non-ASCII mess: https://www.jsoftware.com/indexno.html https://code.jsoftware.com/wiki/System/Installation https://code.jsoftware.com/wiki/Guides/Getting_Started <- help

You can ignore this, given that I haven't used either APL/J seriously, but if I were to truly dive in, I'd lean towards APL exactly because of its non-ascii/symbolic leanings. the only similitude I know of is operator overloading, and whenever that is used, I have to relearn what each operator does in a certain context. it is only if you use it regularly like regex which while changing the meaning of the operators, since its an entire DSL, is too different for me to think + means sum. If another entirely different symbol was introduced, then I'm not assigning any functionality to it, which is why I think it should be easier.

Re: Array Languages: R vs. APL (2023)

#53

Post by seanhunter »

nonfamous wrote: post #10
weinzierl wrote: post #4

> "So, would APL be “readable” if I was more familiar with it? Let’s find out!" An alternative test for this hypothesis might have been using the language J, which is an array language based on APL and by the designer of APL but only using ASCII characters.

R itself could be considered a test of this hypothesis, too. It’s been said that elegant, powerful Lisp would be more widely adopted if it wasn’t for all those gosh-darned parenthesis. Well, at its core R is a Lisp (specifically, Scheme) but with a more traditional syntax (infixed operators, function calls, etc). And it’s fair to say the adoption of R has, indeed, been more widespread than that of Lisp.

As someone who loved learning lisp and regrets that the long course of my programming career has never led me to use it in a professional capacity, I just don't buy it when people say that parentheses are the reason people didn't adopt lisp more widely. I would say the main reasons are:

1) The language is so frikkin massive. Common lisp is a huge language with hundreds and hundreds of built-in functions etc and the standard came very late in its evolution so there is a bunch of back compat cruft and junk that everyone has to live with. The object system is a whole epic journey in itself. You could probably kill or at least seriously injure someone with the impact if they were lying down and you dropped a copy of Guy Steele's excellent book[1] on them from a standing height.

2) The ecosystem is so fragmented. First you have Common Lisp, which isn't very common at all. Then you have all the vendor lisps. Then you have whether they have or don't have clos to contend with. Elisp is a lisp but is not common lisp and differs in some important ways that I don't quite remember. Then there's scheme, and guile scheme (which isn't quite the same) then clojure, etc etc.

3) That meant that the tooling was basically all simultaneously amazing and awful. As an example my uncle wrote a tcp/ip stack in lisp for the symbolics lisp machine[2] for a project when he worked at xerox. He told me in the late 80s about features in the symbolics debugger that just totally blew my mind and are only now available in IDEs for other languages, like being able to step backwards, alter variables, then step forward again, jump to any stack frame and just resume execution from there etc etc. On the other hand he had to write the TCP/IP stack himself because they didn't have one. I think that perfectly encapsulates the lisp experience for me around 2000 when I last used it - some things worked amazingly and were way better than anything else (eg I remember at the time the things you could do with serialization being just extraordinary compared to other languages) but a bunch of basic stuff was painful, janky or just completely missing.

4) Some of the concepts are very powerful but result in programs that are incredibly hard to understand. Macros, continuation passing, multiple dispatch.. etc etc. This puts a lot of people off because they just hit the learning cliff face-first and give up.

This is part of why python saw such wide adoption in my opinion. Not because it was in any sense the best language, but it was a very easy, practical choice for doing a bunch of things.

[1] https://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html . Paul Graham (yes that Paul Graham) wrote a good lisp book also, although for me Steele is the one.

[2] https://en.wikipedia.org/wiki/Symbolics

Re: Array Languages: R vs. APL (2023)

#54

Post by anthk »

pavon wrote: post #30
weinzierl wrote: post #4

> "So, would APL be “readable” if I was more familiar with it? Let’s find out!" An alternative test for this hypothesis might have been using the language J, which is an array language based on APL and by the designer of APL but only using ASCII characters.

J primitives are easier to type, but they aren't any more readable or familiar to newcomers than APL symbols.

Well at least you can define new tokens with ease.

Re: Array Languages: R vs. APL (2023)

#55

Post by disgruntledphd2 »

dan-robertson wrote: post #43
levocardia wrote: post #40

Earlier quoted context omitted.

A lot of R's popularity and usefulness has to do with the libraries that are available in it. I would put up with almost any amount of BS from base R to use ggplot and the tidyverse, and ditto for a number of modern stats algorithms. In many cases, Python implementations of the same techniques are either woefully outdated or completely nonexistent.

When I’ve seen attempts at ggplot2 or dplyr in other languages, one issue is bad performance or bugs, but it’s also been a problem that the language features seem to allow those libraries to be much more ergonomic. eg I found Julia much less nice to use for those sorts of things despite it seeming light it ought to be well suited (making a reasonably good claim to a lot of CL heritage for example)

Plotnine is a pretty good implementation of ggplot2, apart from the necessity to quote variable names it seemed to work almost perfectly.

Re: Array Languages: R vs. APL (2023)

#56

Post by bruturis »

kqr wrote: post #49
bruturis wrote: post #16

>> find the GCD (greatest common divisor) of the smallest and largest numbers in an array Just for a short comparison, In J the analogous code is / Where / is for reduce, +. is for the GCD, the LCM is *. The basic idea of J notation is using some small change to mean the contrary, for example {. for first and {: for last, {. for take and }. for drop (one symbol can be used as a unary or binary operator with different…

> So if floor is Based on the examples, no, I cannot. It could be either of .

You are right, both are good options, the author of J chose >. for ceiling and >: for greater than or equal.

Re: Array Languages: R vs. APL (2023)

#57

Post by bruturis »

KarlKode wrote: post #38
bruturis wrote: post #16

>> find the GCD (greatest common divisor) of the smallest and largest numbers in an array Just for a short comparison, In J the analogous code is / Where / is for reduce, +. is for the GCD, the LCM is *. The basic idea of J notation is using some small change to mean the contrary, for example {. for first and {: for last, {. for take and }. for drop (one symbol can be used as a unary or binary operator with different…

I think you mistyped J code. I don't know any J but what I understood from your comment that it should be something like / *.

You are right, the correct code is ../

To understand this you need to know that >. and <. are the min and max functions, and that in J three functions separated by spaces, f g h, constitutes a new function mathematically defined by (f g h)(x) = g(f(x), h(x)). An example is (+/ % #) which applied to a list gives the mean of the list. Here +/ gives the total, # gives the number of elements and % is the quotient.

Re: Array Languages: R vs. APL (2023)

#58

Post by cl3misch »

bruturis wrote: post #28
cl3misch wrote: post #20

> what if we just generate all products from the set of numbers 2:n and exclude those as "not prime" from all the numbers up to n? It's fun to translate terse APL to somewhat terse numpy. The result still can be very compact and you can parse it easily if you're used to looking at numpy: s = arange(2, 50); p = outer(s, s).ravel(); sorted(set(s) - set(p))

Analogous code in J, /:~ s -. p [ p =: s*/s [ s=: 2+i.48 An exercise for numpy, test that GCD(x,y) * LCM(x,y) = x*y using 1000 random numbers in the range 0..99 for x e y. test =: (* = *. * +.) & ? *./ test~ 1000 # 100

Thanks, that was fun.

    def d(x): N = arange(1, x + 1); return N[x % N == 0]
    def m(x, n): return x * arange(1, n + 1)
    def gcd(x, y): return max(set(d(x)) & set(d(y)))
    def lcm(x, y): return min(set(m(x, y)) & set(m(y, x)))
    def test(x, y): return gcd(x, y) * lcm(x, y) == x * y
    all([test(x, y) for (x, y) in randint(1, 100, (1000, 2))])  # True
I am not a good golfer. Now I want to look at the codegolf stackexchange for this...

Re: Array Languages: R vs. APL (2023)

#59

Post by [deleted] »

cl3misch wrote: post #58
bruturis wrote: post #28

Earlier quoted context omitted.

Analogous code in J, /:~ s -. p [ p =: s*/s [ s=: 2+i.48 An exercise for numpy, test that GCD(x,y) * LCM(x,y) = x*y using 1000 random numbers in the range 0..99 for x e y. test =: (* = *. * +.) & ? *./ test~ 1000 # 100

Thanks, that was fun. def d(x): N = arange(1, x + 1); return N[x % N == 0] def m(x, n): return x * arange(1, n + 1) def gcd(x, y): return max(set(d(x)) & set(d(y))) def lcm(x, y): return min(set(m(x, y)) & set(m(y, x))) def test(x, y): return gcd(x, y) * lcm(x, y) == x * y all([test(x, y) for (x, y) in randint(1, 100, (1000, 2))]) # True I am not a good golfer. Now I want to look at the codegolf stackexchange for thi…

[deleted]

Re: Array Languages: R vs. APL (2023)

#60

Post by pocketsand »

I've always wondered if the "hard productive way" as understood by conventional wisdom (using VIM, using a language like APL) is actually more productive.

For this topic, I have in mind two exercises:

First, get people to nominate "experts" in a language, and assign them a straightforward task, and see who is actually faster using their native environments with code completion, language servers, etc. by systematically running these trials.

Second, get people untutored in each language of similar experience, randomly assign them to a language, give them a not short but not long period of time, then do a similar exercise as above.

The first has problems with assuring there is skill balance between the groups, but would I think tell you about how productive one can be in each language.

The second would have good causal inference properties, but probably not tell you about the downstream effects of learning something hard with great rewards (e.g., vim or emacs).

I'd bet there are marginal gains to APL (or vim) but probably nothing that matters in long-term productivity.

However, I do think people underrate how fun it can be to "get good" at things like vim or APL, and I think that has really positive knock-on effects.

Post reply on HN