The language is interesting, but the management ideas in this are very strange. Example: tin flippers. Items are being checked manually and miscounted. The numbers are inherently inaccurate. And he makes the point that this applies in many other situations - some where the inputs are mechanical, so "Use a machine" isn't a solution. ("Use a better machine" might be. But how would you know without being able to monitor…
Real time processes are indeed critical in some contexts. And, arguably, we should be putting more effort into some of those contexts. For the APL family, that's often a call for code which works with external interfaces. In many potential APL environments a handful of well designed custom primitives would get you where you need to go. But no programming language is adequate for all roles, and that includes APL. (It…
A Personal History of APL (1982)
31–40 of 50 posts
Re: A Personal History of APL (1982)
#32Can APL can be used to implement Machine Learning algorithms? It seems like a good fit.
Yes, but no one's made a reverse-mode autodiff system for it yet, so all of the linked examples have hand-written derivatives.
Re: A Personal History of APL (1982)
#33I tried J (Iverson's successor to APL) in earnest but struggled to understand what I was supposed to do when I needed data structures other than arrays. E.g. tries, trees, hash tables and so on. The majority of the out-of-the-box vocabulary is centered on arrays, so it seemed that either you convert your problem to some kind of an array representation, or go somewhere else.
lisp baffled me for a while because, in my mind, a list is different from a tree, but in lisp a list element might be itseld a list, and so a lisp list might be a tree. similar situation with J arrays.
i'm not sure how APL does it. i /think/ it uses a flat array model, but i'm not sure what that means exactly, or if it's even applicable to modern APL, let alone what it might imply about bending APL arrays into other data structures.
Re: A Personal History of APL (1982)
#34I guess the ideas, not the notation, turned out to be the important part after all.
"I have only made this letter longer because I have not had the time to make it shorter." - It's Advent of Code[1] (AoC) season again; take a moment to look at the answers people put in the big Reddit answers threads e.g.[2]. The comments are all a beautiful/awful zoo of languages - wildly varying in programmer experience level, familiarity with the language, choice of approach and algorithm, runtime, focus on a tidy solution or a quick answer. I wish we could see how much time people put into their solutions - I suspect this famous quote applies and it takes longer whether you polish a plain language or write directly in a terse language. I think the hurried or inexperienced answers tend to be long and garbled, the experienced and polished answers tend to be clean and clear. The racing leaderboard entries that I've seen - people seeing the problem and getting an answer ASAP - tend to be Python, and tend to be short and clear. They're almost never (APL, J, K, Q, R, uiua, Haskell). Does that say anything of value about the ability to quickly and clearly express ideas in a language?
I feel like there's enough of these answers now after years of AoC for someone to analyse and compare the languages. My gut feeling is that non-golfed Python still comes out the most easily writable and easily readable, the nicest balance between density and verbosity.
[1] https://adventofcode.com/ - daily puzzles through December, solved with code using whatever language you like, however you like, the site only checks your answer not your working.
[2] https://old.reddit.com/r/adventofcode/comments/1883ibu/2023_...
Re: A Personal History of APL (1982)
#35I find it sad that APL nowadays means Dyalog. They appear to do amazing work. Unfortunately, the license isn't open. Why would I invest time learning it only to be locked in? I wonder how much licensing plays in APL not being more popular and used in the present day. There are open variants, like GNU APL2 and J. However, GNU APL2 has none of the advancements made in the past 40 years and J is J, not APL. The notation…
There's also April APL: https://github.com/phantomics/april Also the array language family seems to be stronger than ever with foss: ngn/k, BQN, uiua, and of course J but as you mentioned they're all different languages.
It looks like it can load pure APL files.
All the examples I see use the Lisp repl and APL is called within strings. Does it provide an APL repl, too?
Re: A Personal History of APL (1982)
#36Someone in the HN comments called out that J is the proof that Iverson's "Notation as a Tool of Thought" is a failed idea. Even Iverson himself, the inventor of "Iverson Notation" (proto-APL) as a better math notation, the inventor of APL, who used it to design the IBM 360's processor and then turned it into a programming language, abandoned it for ugly ASCII scribble (J) because that was more convenient. I guess the…
Re: A Personal History of APL (1982)
#37I find it sad that APL nowadays means Dyalog. They appear to do amazing work. Unfortunately, the license isn't open. Why would I invest time learning it only to be locked in? I wonder how much licensing plays in APL not being more popular and used in the present day. There are open variants, like GNU APL2 and J. However, GNU APL2 has none of the advancements made in the past 40 years and J is J, not APL. The notation…
There's also April APL: https://github.com/phantomics/april Also the array language family seems to be stronger than ever with foss: ngn/k, BQN, uiua, and of course J but as you mentioned they're all different languages.
Re: A Personal History of APL (1982)
#38It's at least reassuring to learn from the 1952-1954 section that the phenomenon of doing things without having any clue about them easily predates the microprocessor. (btw I second the recommendation of the 1962 A Programming Language ) Edit: > The third page had an illustration that, in a few short lines, described George Dantzig's simplex algorithm simply and precisely. > That was the overwhelming, crucial experie…
> most people vastly prefer easy and DWIM over simple and precise Most people also vastly prefer not having to work on difficult problems. Iverson was clearly trying to provide a notation that would help the (admittedly smaller) group of people who find solving difficult problems interesting and valuable.
Re: A Personal History of APL (1982)
#39Earlier quoted context omitted.
> most people vastly prefer easy and DWIM over simple and precise Most people also vastly prefer not having to work on difficult problems. Iverson was clearly trying to provide a notation that would help the (admittedly smaller) group of people who find solving difficult problems interesting and valuable.
If you're the M Kromberg, any chance you could ask J Scholes to whip up a dfns version of Iverson's 1960 Simplex algo for us?