The Origins of APL - 1974 on HackerTube: recommended by 2 Hacker News commenters across 2 separate months, 2012–2026.
interview · evergreen
A 1974 talk-show-style interview with the original developers of APL, including Iverson, Falkoff and Breed. They discuss how the language originated.
Recommended as a vintage TV segment on APL's origins, and quoted for Iverson's view of APL as notation.
“a video from 1974, where Iverson, Falkoff, and others discuss the origins of APL. It was a pleasure to watch.”
5 Hacker News comments link this video. Each one links back to its thread.
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
in “Ruins of forgotten empires: APL languages” · View on HN
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
in “Why APL Is Still Cool” · View on HN
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.
in “Scaling long-running autonomous coding” · View on HN
▶ 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).
in “Way AI assistance impacts the formation of coding skills” · View on HN
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.
in “"Careless" employees” · View on HN