Procedural Programming: It Never Went Away — Kevlin Henney | Build Stuff
Procedural Programming: It Never Went Away — Kevlin Henney | Build Stuff on HackerTube: recommended by 2 Hacker News commenters across 3 separate months, 2018–2021.
Build Stuff - #1 Software Dev Conftalk · intermediate · evergreen
Open on YouTubeKevlin Henney argues that procedural programming never went away despite later paradigms such as OO and functional. He traces the history of structured programming and shows where procedural thinking still lives in modern code and why it matters for readability.
What HN commenters said
7 Hacker News comments link this video. Each one links back to its thread.
open-source-uxJan 2019Strongly recommends
I strongly recommend this talk by software consultant and author Kevlin Henney called Procedural Programming: It's Back? It Never Went Away He talks a bit out Algol 68 and how influential it was on programming language design. Many language keywords we're familiar with today originated in the 50 year old language specification for Algol 68: int, bool, skip, void, struct. Here's the snippet from the talk about Algol 68 - it's brilliant: ▶ this video
in “Algol 68” · View on HN
open-source-uxDec 2018Recommends
I really liked this talk about the history of programming and how so many ideas we consider recent or modern are in fact much older than many of us realise. Watching this talk merely amplifies the feeling that the programming profession is in a perpetual loop - discarding or forgetting ideas or concepts, then re-discovering them anew. What's also striking is how rich and varied were the programming ideas that emerged from the 60s and 70s. Kevlin Henney - Procedural Programming: It's Back? It Never Went Away ▶ this video
in “Ask HN: Best talks of 2018?” · View on HN
open-source-uxApr 2018Recommends
If you have an interest in the history of programming methodologies, this talk is fascinating: Procedural programming: it's back? It never went away ▶ this video
in “Ask HN: What is your favourite tech talk?” · View on HN
bunderbunderApr 2018Recommends
You may appreciate Kevlin Henney's talk, "Procedural Programming - It's back? It never went away."[1] It's a tour of how all the best discoveries of the past decade or two really date back to the 1960s. [1] ▶ this video ▶ this video
in “Designing very large JavaScript applications” · View on HN
SupermanchoDec 2021Cites it
▶ this video Sequence, selection, iteration (or recursion if available). Note that the child overlooked the assumption that it's sequential.
in ““Coding is basically just ifs and for loops.”” · View on HN
SupermanchoDec 2021Cites it
I will start with a couple clarifications, in good faith. I will admit that I have made lazy errors in this discussion. Specifically in regard to terminology. Afaik, there is no term for "temporally unsynchronized" other than parallelism or concurrency, and I have misused the term concurrency at times. I have also used the term transition to mean "asynchronous state transition". This may clarify my past statements, but I will attempt to do better, going forward. So I'll visit on the material you are most familiar with so that my comments might have the most specific impact or irrelevance. For your verification, I read your paper here: [link] To begin, I agree on the concept. If "constraining architecture" means any separation of concerns or interface. To demonstrate that I did read through the code snippets you provided and completely irrelevant to the points being discussed, I believe there was an error in the code you posted in Listing [email protected] - - k: degreesK { self basicC :( degreesF - 273.15. \*wat?\* ivar : ui / celsiusTextField / intValue := self c . ivar : ui / fahrenheitTextField / intValue := self f. } I also thought the implementation was a little muddled and would implement a solution similar to this^. Object subclass: #Temperatures { var c. -changedC : sender { self c: sender intValue. self updateValues: { #val : c, #type: 'Celcius' }. } -changedF : sender { self f: sender intValue. self updateValues: { #val : f, #type: 'Farenheit' }. } -changedK : sender { self k
in “Why Architecture Oriented Programming Matters (2019)” · View on HN
Show 1 more comment
mpweiherDec 2021Cites it
> 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