Live data from Hacker News

A Personal History of APL (1982)

ed-thelen.org

31–40 of 50 posts

Re: A Personal History of APL (1982)

#31

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…

Everything involving a user is a real time thing. But that's now how the software industry views it, somewhere along the line the user became a peripheral rather than the other way around.

Re: A Personal History of APL (1982)

#32
post #10

Can 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.

https://www.youtube.com/watch?v=ToQoJ1Bbpus&t=1165s

Re: A Personal History of APL (1982)

#33
post #24

I 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.

i've also tried learning J and can't really say i've managed it yet, but i think the idea is that everything is an array. in J an array can contain a box, and a box might contain an array, so you have nested arrays, (different from multidimensional arrays.)

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)

#34
Someone 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 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)

#35

I 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.

Thank you. I had seen April previously although it looks like it's had a lot of updates since then. I appreciate you bringing it back to my attention :)

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)

#36

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

https://blog.vero.site/post/noulith seems to be familiar with both APL and J, and draw some inspiration from them…

Re: A Personal History of APL (1982)

#37

I 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.

I had not heard of uiua before, but I'm familiar with both APL and stack languages, so it should fun to explore it its capabilities.

Re: A Personal History of APL (1982)

#38

It'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.

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?

Re: A Personal History of APL (1982)

#39

Earlier 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?

Sadly, John Scholes passed away in 2019. https://aplwiki.com/wiki/John_Scholes
Post reply on HN