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

21–30 of 68 posts

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

#21

Post by broomcorn »

bnprks wrote: post #5

One of the wildest R features I know of comes as a result of lazy argument evaluation combined with the ability to programmatically modify the set of variable bindings. This means that functions can define local variables that are usable by their arguments (i.e. `f(x+1)` can use a value of `x` that is provided from within `f` when evaluating `x+1`). This is used extensively in practice in the dplyr, ggplot, and other…

That sounds like asking for trouble. Someone coming from any other programming language could easily forget that expression evaluation is stateful. Better to be explicit and create an object representing a expression. Tell me, at least, that the variable is immutable in that context?

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

#22

Post by empyrrhicist »

bnprks wrote: post #5

One of the wildest R features I know of comes as a result of lazy argument evaluation combined with the ability to programmatically modify the set of variable bindings. This means that functions can define local variables that are usable by their arguments (i.e. `f(x+1)` can use a value of `x` that is provided from within `f` when evaluating `x+1`). This is used extensively in practice in the dplyr, ggplot, and other…

I saw a funny presentation where Doug Bates said something like: "This kind of evaluation opens the door to do many strange and unspeakable things in R... for some reason Hadley Wickham is very excited about this."

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

#23

Post by jonocarroll »

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

What's interesting there is that numpy is inspired (more than a little) by APL and aims to bring that 'array' thinking to python. I agree that thinking in this 'array' way helps to better construct a solution in any language, so I'm leaning towards 'designing' with APL glyphs, even if that's not the language I'm implementing the thing in.

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

#24

Post by nerdponx »

broomcorn wrote: post #21
bnprks wrote: post #5

One of the wildest R features I know of comes as a result of lazy argument evaluation combined with the ability to programmatically modify the set of variable bindings. This means that functions can define local variables that are usable by their arguments (i.e. `f(x+1)` can use a value of `x` that is provided from within `f` when evaluating `x+1`). This is used extensively in practice in the dplyr, ggplot, and other…

That sounds like asking for trouble. Someone coming from any other programming language could easily forget that expression evaluation is stateful. Better to be explicit and create an object representing a expression. Tell me, at least, that the variable is immutable in that context?

The whole magic is that expressions are in fact just objects in the language. And no, there aren't any immutable bindings here.

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

#25

Post by delusional »

bnprks wrote: post #5

One of the wildest R features I know of comes as a result of lazy argument evaluation combined with the ability to programmatically modify the set of variable bindings. This means that functions can define local variables that are usable by their arguments (i.e. `f(x+1)` can use a value of `x` that is provided from within `f` when evaluating `x+1`). This is used extensively in practice in the dplyr, ggplot, and other…

> I think software engineers often get turned off by the weird idiosyncrasies of R

That was at least true when I was looking at it. I didn't get it, but the data guys came away loving it. I came away from that whole experience really appreciating how far you can get with an "unclean" design if you persist, and how my gut feeling of good (with all the heuristics for quality that entails) is really very domain specific.

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

#26

Post by jonocarroll »

(author here, still getting over the first time I've seen one of my own posts on this site)

The many recommendations for J here are a great nudge for me to give it a proper go. I've taken quite a liking to the traditional APL glyphs ( see a photo of the stickers on my laptop keys in this post https://jcarroll.com.au/2023/12/10/advent-of-array-elegance/ ) so I'm not looking for a way to avoid them.

Another detraction I've seen around is about the ambivalence of APL glyphs (taking either 1 or 2 arguments and doing something different in each case). I don't particularly mind it because I think it becomes more natural to "understand" how a function is being used the more familiar you become with it, but without the limitation on the number of glyphs, I can see the benefit of separating those.

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

#27

Post by nerdponx »

jonocarroll wrote: post #23
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))

What's interesting there is that numpy is inspired (more than a little) by APL and aims to bring that 'array' thinking to python. I agree that thinking in this 'array' way helps to better construct a solution in any language, so I'm leaning towards 'designing' with APL glyphs, even if that's not the language I'm implementing the thing in.

If it takes any inspiration from APL, it would be mostly indirect, via Matlab.

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

#28

Post by bruturis »

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

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

#29

Post by csimon80 »

bnprks wrote: post #5

One of the wildest R features I know of comes as a result of lazy argument evaluation combined with the ability to programmatically modify the set of variable bindings. This means that functions can define local variables that are usable by their arguments (i.e. `f(x+1)` can use a value of `x` that is provided from within `f` when evaluating `x+1`). This is used extensively in practice in the dplyr, ggplot, and other…

A lot of the time you're not actually using what is passed to the function, but instead the name of the argument passed to the function (f(x), instead of f('x')). Which, helps the user with their query (dplyr) or configuration (ggplot2).

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

#30

Post by pavon »

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.
Post reply on HN