The 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 an equivalent python code. Of course python users that don't know APL are rolling their eyes, yet when you make such statement about python vs Java they get it.
Array Languages: R vs. APL (2023)
41–50 of 68 posts
Re: Array Languages: R vs. APL (2023)
#42The 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…
I saw a recent paper saying that Standard Chinese and English are approximately as fast to read by their respective native readers. One Chinese character holds much more information than one Latin letter, but an English reader can process many letters simultaneously whereas the Chinese reader takes longer to ingest each character.
In other words, if you were to write the same text in Chinese and English, the Chinese version would take much less room, but native readers of each would take about as long to read them.
In CompSci terms, Chinese gets more done per instruction, but English has a much higher IPC.
I think we'd find the same between APL and Python. You could express ideas much more compactly in APL, but someone skilled in APL would take about as long to interpret a bit of code as a Pythonista would take to understand the Python equivalent.
Re: Array Languages: R vs. APL (2023)
#43Earlier quoted context omitted.
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.
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)
Re: Array Languages: R vs. APL (2023)
#44One 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."
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?
Re: Array Languages: R vs. APL (2023)
#45The 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…
I saw a recent paper saying that Standard Chinese and English are approximately as fast to read by their respective native readers. One Chinese character holds much more information than one Latin letter, but an English reader can process many letters simultaneously whereas the Chinese reader takes longer to ingest each character. In other words, if you were to write the same text in Chinese and English, the Chinese…
> but someone skilled in APL would take about as long to interpret a bit of code as a Pythonista would take to understand the Python equivalent.
If we take into account break of flow due scrolling up and down trough text, APL probably has an advantage after a few hundred Python-equivalent lines. One screen worth of APL holds many screens worth of Python.
Re: Array Languages: R vs. APL (2023)
#46One 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…
One of the stranger behaviours for me is that R allows you to combine infix operators with assignments, even thou there are no implemented instances of it in R itself. For example:
`%in% ` x Re: Array Languages: R vs. APL (2023)
#47The 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 to the untrained.
Devanagari has it too: भारत गणराज्य
Ge'ez script doesn't: የኢትዮጵያ ፌዴራላዊ ዴሞክራሲያዊ ሪፐብሊክ
English does, if you choose to write in cursive.
By this standard that I just made up, kanji are clearly pretty far toward the "organized" end of the spectrum. An untrained person looking at them is going to be able to tell you what the main principles of the script are. And while I suspect that people complaining that a script "looks like noise" are mostly just saying that they can't read it, I also think that if people were forced to rank scripts based on how confusing they look, Arabic would be rated a lot more confusing than kanji.
(For a parallel to the above examples: 大日本帝國; الْخِلَافَة الْعَبَّاسِيَّة.)
This belies reality; in fact, reading kanji is so much more difficult that your claim that some people can do it as easily as we read Roman scripts is not defensible. (Whereas it's fine for Arabic.) The problem isn't in the appearance of the elements, it is that there are too many of them. This means that (a) learning to read kanji is a multi-year process; and (b) even those who are considered "fully educated" nevertheless need help in doing things like reading museum plaques or technical documents that use words which modern people are not expected to encounter in day-to-day life. If all you have is "full" training in the writing system, these words cannot be read at all, so there is a system of phonetic annotation for just this purpose. (For Japanese kanji, ruby; for Taiwan, zhuyin; for mainland China, pinyin.)
Kanji in specific has an additional problem that Chinese characters do not have, which is that the Japanese interpreted it as being primarily a logographic script rather than a phonetic script. To predict how a kanji is supposed to be pronounced, you need to see a particular use in a particular sentence and know the Japanese language. This is not true of Chinese characters - but it's not so much of a problem for your claim that "some people find this just as easy as we find reading Roman characters"; native speakers of Japanese don't have a problem with knowing Japanese. It does mean that it's hard to predict how personal names are supposed to be pronounced.
Re: Array Languages: R vs. APL (2023)
#48One 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 had a colleague at Google who used to say: "The best thing about R is that is was created by statisticians. The worst thing about R was that it was created by statisticians."
Re: Array Languages: R vs. APL (2023)
#49>> 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 .
Re: Array Languages: R vs. APL (2023)
#50The 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…
Someone seeing an unfamiliar kanji-based term in a Japanese technical document would often have little trouble reading it phonetically.
Furigana helps if one or more of the kanji used is rare (outside of the jōyō kanji), or when the word follows some common variation (guessing which is possible, but wastes the reader's time) or when the kanji spelling is arbitrarily assigned ("ateji"; impossible to guess).
E.g. suppose the reader sees 帰納. It is very likely they can read it correctly as kinō. The problem is not knowing what it means, that it refers to (mathematical) induction, or inductive reasoning. The dictionary lookup is trivial, though.
Basically, someone fluent in Japanese can read unfamiliar words like that most of the time. They will know a ton of words in which 帰 is ki and 納 is nō. In situations like that, it's not much different from someone encountering an unfamiliar word in English or Spanish text.