I recently bought "APL an interactive approach" and read it. It seems that most of the good stuff from APL is already present in modern languages, and better when it's lazy. The OO stuff in APL looks kind of crufty. Still it's a wonderful fascinating language. In the age of mature open-source it feels very old fashioned with the expensiveness of a decent implementation. Btw, this is a fantastic tv segment from days of yore "The Origins of APL - 1974": [this video]
There's a great link in the original comments to a video from 1974, where Iverson, Falkoff, and others discuss the origins of APL. It was a pleasure to watch. A peculiar contrast in language and attitude to today's rockstars and ninjas :) [this video]
1974 discussion by Iverson, Falkoff and others on APL's origins
There are lots of software developers out there, that shouldn't be developing software in first place. They could be excellent farmers, musicians, athletes, but for whatever reason they decided to be software developers. And it doesn't matter how many scrums or code reviews you throw at them, they just won't get it. They will be producing miserable results making everyone around them miserable. On the other hand, there still are a few decent, old school devs, who don't need hand-holding, constant poking and distraction of standup meetings and writing meaningless test cases that check if 2+2 is still 4. They just (1) understand the problem and (2) write code that solves it. As simple as that. Good old engineering, like these guys: [this video] . Or original SAS system - its reference manual was better quality then any statistics textbook. Unfortunately those days are gone now and we live in the kingdom of Scrums and Frameworks.
Example of old-school engineering by capable developers
Skilled devs compress, not generate (expand). [this video] The "discoverer" of APL tried to express as many problems as he could with his notation. First he found that notation expands and after some more expansion he found that it began shrinking. The same goes to Forth, which provides means for a Sequitur-compressed [1] representation of a program. [1] [link] Myself, I always strive to delete some code or replace some code with shorter version. First, to better understand it, second, to return back and read less.
APL's discoverer found notation first expands then shrinks as problems are expressed
[this video] APL inventor says that he was developing not a programming language, but notation to express as much problems as one can. He found that expressing more and more problems with the notation first made notation grow, then notation size started to shrink. To develop conceptual knowledge (when one's "notation" starts to shrink) one has to have some good memory (re-expressing more and more problems).
APL inventor describes building notation to express many problems
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
5 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes
Read more