Oral History of John Backus

Exactly, this is why I shared this video. Hearing concepts explained by those who pioneered them really brings them home, because it highlights the context in which they were created, with a description of what was the trouble with computing back then and how it was solved, and the excitement of the achievement. For instance, he situates his breaktrought in a timeline where the main milestones are, first, getting computers to work at all, and, then, high level languages, to make them much easier to program (Fortran, ▶ this video ). Then, time sharing made them much easier to use. The birth of the terminal, no less, which is still around and which we all take for granted (I know it's deeper than this, multiprocessing, but this is the most visible manifestation) ... Judging from this video, it also seems that he was a very good communicator.

in “Fernando Corbató, a Father of Your Computer (and Your Password), Has Died” · View on HN

Videos to FL and FP: John Backus: Function Level Programming and the FL Language 1987 ( [link] ), John Backus Group Meeting - IBM Research - 5 July 1989 ( [link] ), Backus on functional programming ( [link] ) from Original: Oral History of John Backus ( ▶ this video )

in “History of John Backus's functional programming project [draft]” · View on HN

> If "constraining architecture" means any separation of concerns or interface. It doesn't. It means you work with constraints, for example dataflow constraints. For example: [link] > I also thought the implementation was a little muddled Yes! That was the point of that section of the paper, that doing the straightforward thing leads to a muddle: "At this point, it becomes clear that our original strategy of updating the UI from the individual setter methods is probably not tenable in the long run." A little later: "As we have seen, even a conceptually very simple application such as a temperature converter quickly attracts significant complexity with non-obvious trade-offs once the requirements of an interactive version of that application are taken into account." The fact that you need to create these centralised updater methods is non-obvious, and leads to a bunch of related non-local changes. Also a muddle. "This complexity is not the result of a complicated domain model, but rather of the architectural embellishments required to move data from location to location in order to keep the different parts of the application (model, user interface, persistence) synchronized. In the next section, we will look at a mechanism for simplifying this kind of overhead." > ReactJS (uses HOM like Objective-Smalltalk) ReactJS uses Higher Order Messaging? Where? > Chatty: "We highlight a strong coupling between languages and architecture,..." Which was my point, yes, thank you! We are lim

in “Why Architecture Oriented Programming Matters (2019)” · View on HN