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

31–40 of 68 posts

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

#31

Post by bnprks »

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 good news is that most variables in R are immutable with copy-on-write semantics. Therefore, most of the time everything here will be side-effect-free and any weird editing of the variable bindings is confined to within the function. (The cases that would have side effects are very uncommonly used in my experience)

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

#32

Post by jonocarroll »

nerdponx wrote: post #27
jonocarroll wrote: post #23

Earlier quoted context omitted.

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.

I've seen the connection made here https://dev.to/bakerjd99/numpy-another-iverson-ghost-9mc though the link to the source quote is broken. In all fairness, Matlab is itself inspired by APL.

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

#33

Post by bnprks »

VTimofeenko wrote: post #11
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…

Asking out of lack of experience with R: how does such invocation handle case when `x` is defined with a different value at call site? In pseudocode: f = let x = 1 in # inner vars for f go here arg -> arg + 1 # function logic goes here # example one: no external value f (x+1) # produces 3 (arg := (x+1) = 2; return arg +1) # example two: x is defined in the outer scope let x = 4 in f (x+2) # produces 5 (arg := 4; retu…

If the function chooses to overwrite the value of a variable binding, it doesn't matter how it is defined at the call site (so inner x wins in your example). In the tidyverse libraries, they often populate a lazy list variable (think python dictionary) that allows disambiguating in the case of name conflicts between the call site and programmatic bindings. But that's fully a library convention and not solved by the language.

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

#34

Post by dan-robertson »

jonocarroll wrote: post #26

(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…

Can’t the second argmax example be written with a right tack? Is it nicer then?

  (⊢⍳⌈/)+/x

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

#35

Post by dan-robertson »

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.

I’m not totally convinced that being ‘secretly a lisp’ is what was good about R. I think the easy vectorisation is good, and the consequences of the bizarre function argument evaluation are good. I don’t know of lisps that do the vectorisation stuff so naturally, and while I guess fexprs are a thing, I think they are possibly too general in the syntax they can accept – basically the simplicity of lisp syntax allows macros to have more tree-structured input in a way you wouldn’t want for a language with non-lisp syntax (where the head lives outside the list), and I think the flexibility makes the syntax more confusingly non-uniform.

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

#36

Post by [deleted] »

VTimofeenko wrote: post #11
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…

Asking out of lack of experience with R: how does such invocation handle case when `x` is defined with a different value at call site? In pseudocode: f = let x = 1 in # inner vars for f go here arg -> arg + 1 # function logic goes here # example one: no external value f (x+1) # produces 3 (arg := (x+1) = 2; return arg +1) # example two: x is defined in the outer scope let x = 4 in f (x+2) # produces 5 (arg := 4; retu…

[deleted]

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

#37

Post by jonocarroll »

dan-robertson wrote: post #34
jonocarroll wrote: post #26

(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…

Can’t the second argmax example be written with a right tack? Is it nicer then? (⊢⍳⌈/)+/x

Yep, that makes for a nicer tacit solution

  maxrow←(⊢⍳⌈/)+/
but I find

  ⊃(⍒+/)
to be an even cleaner tacit solution.

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

#38

Post by KarlKode »

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

  / *.

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

#39

Post by vharuck »

nerdponx wrote: post #24
broomcorn wrote: post #21

Earlier quoted context omitted.

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.

It's crazy how literally R takes "Everything's an object." While parentheses can be treated like syntax when writing code, it's actually a function named `(`.

Of course, playing with magic sounds fun until you remember you're trying to tell a computer to do a specific set of steps. Then magic looks more like a curse.

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

#40

Post by levocardia »

dan-robertson wrote: post #35
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 totally convinced that being ‘secretly a lisp’ is what was good about R. I think the easy vectorisation is good, and the consequences of the bizarre function argument evaluation are good. I don’t know of lisps that do the vectorisation stuff so naturally, and while I guess fexprs are a thing, I think they are possibly too general in the syntax they can accept – basically the simplicity of lisp syntax allows m…

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