The Origins of APL - 1974

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

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

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.

▶ 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).

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.