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 systematicall…
Array Languages: R vs. APL (2023)
61–68 of 68 posts
Re: Array Languages: R vs. APL (2023)
#62The thing about APL/J/K is "Notation as a tool of thought". Sure, most folks would frown and claim that Kanji or Arabic script looks like noise and must be difficult. Yet some people read it just as easy as we read roman scripts, the idea behind APL/J is to learn it enough to read it as easy as you can read python or javascript, with the added benefit that it's compact so would be faster to read and reason about than…
> Sure, most folks would frown and claim that Kanji or Arabic script looks like noise and must be difficult. Yet some people read it just as easy as we read roman scripts This is folding several claims into each other, and they're not all true. I would tend to associate "looks like noise" with writing where the units are not separated from each other. Arabic has this feature and this makes it appear more forbidding t…
I think their claim is still defensible, and I think to make a fair argument you'd have to reduce the scope of kanji down to something the size of APL's vocabulary in any counterclaim.
Re: Array Languages: R vs. APL (2023)
#63Earlier quoted context omitted.
> Sure, most folks would frown and claim that Kanji or Arabic script looks like noise and must be difficult. Yet some people read it just as easy as we read roman scripts This is folding several claims into each other, and they're not all true. I would tend to associate "looks like noise" with writing where the units are not separated from each other. Arabic has this feature and this makes it appear more forbidding t…
Someone literate in English would also need a dictionary just as much to read academic, esoteric, or old words from a museum. They might be able to guess the meaning based on word roots and context, but I assume someone literate with kanji could do the same based on radicals and context. I think their claim is still defensible, and I think to make a fair argument you'd have to reduce the scope of kanji down to someth…
This is plainly untrue; if you go to a museum and they're displaying an astrolabe, you can read the word "astrolabe" despite the fact that you've never learned it. In Japanese and Chinese, this is not true,† and the text describing the exhibit must separately inform you of how the word is pronounced.
Similarly, if you look over your Chinese medical record, it will be full of unfamiliar characters that you need to look up by shape if you want to read them. An English speaker may not know what a biopsy is, but they won't have trouble reading the word.
† It might be true; I have not looked into "astrolabe" specifically. But for various premodern devices, it is not true.
Re: Array Languages: R vs. APL (2023)
#64One 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…
Re: Array Languages: R vs. APL (2023)
#65> 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
⎕io←0 ⍝ to match J
test ← (× = ∨ × ∧) ∘ ?
∧⌿ test⍨ 1000⍴100Re: Array Languages: R vs. APL (2023)
#66(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…
Re: Array Languages: R vs. APL (2023)
#67(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…
It's not glyph-ish those APL style languages you like, but have you given Factor a good go?
Re: Array Languages: R vs. APL (2023)
#68Earlier quoted context omitted.
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."
Unspeakable horrors like changing `$[` in old Perl5 versions to mess with someone's mind? Who doesn't like array indices starting at 0, 1, ... or 42?