Skip to content
Hallway
0:00 / 0:00

#proceduralprogramming#kevlinhenney#structuredprogramming

Procedural Programming: It Never Went Away — Kevlin Henney | Build Stuff

Build Stuff - #1 Software Dev Conf

6.1K subscribers • 1 video on Hallway

YouTube
  • Recommended by 2 people: 2 on Hacker News.
  • Presented by Kevlin Henney, consultant and author
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

27K views8 years ago2 recommendations

Programming languagesSoftware designFunctional programmingObject-oriented designDesign patterns

Kevlin Henney traces the history of structured programming and argues that procedural thinking remains fundamental to modern software development.

Object-oriented, functional, reactive — every paradigm was supposed to replace procedural code. It did not. Kevlin Henney traces where procedural thinking still lives in your codebase, why it works, and what structured programming can teach us about writing code people can actually read. Speaker: Kevlin Henney — author, consultant and co-editor of "97 Things Every Programmer Should Know". Recorded at Build Stuff, Vilnius, Lithuania. ▶ BUILD STUFF 2026 — THE AGE OF AGENCY December 2–4, 2026 · Radisson Blu, Vilnius · 80+ speakers · 85 sessions Build software that can act. Decide where it should stop. Tickets & program: buildstuff.events Partner with Build Stuff: sponsors.buildstuff.events Subscribe for more talks: youtube.com/@BuildStuff #BuildStuff #BuildStuff2026 #ProceduralProgramming #ProgrammingParadigms #StructuredProgramming

Why it's here

2 people recommend this

What people say. Highly recommended for its fascinating historical perspective on programming paradigms and how modern concepts trace back to the 1960s.

Moments people linked to

open-source-uxon Hacker News • Recommends

On “Algol 68”

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: link to this video
View on Hacker News

open-source-uxon Hacker News • Recommends

On “Ask HN: What is your favourite tech talk?”

If you have an interest in the history of programming methodologies, this talk is fascinating: Procedural programming: it's back? It never went away link to this video
View on Hacker News

bunderbunderon Hacker News • Recommends

On “Designing very large JavaScript applications”

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 link to this video link to this video
View on Hacker News

open-source-uxon Hacker News • Recommends

On “Ask HN: Best talks of 2018?”

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 link to this video
View on Hacker News

u/everything-narrativein r/ProgrammingLanguages • Mentions

On “Procedural vs Object Oriented Language”

I think you should give this talk by Kevlin Henney a watch, because it sounds like you're re-discovering Algol 68. It is very hard to identify a language which is _not_ procedural. Haskell is one of the best candidates I can name, because of its lazy evaluation model, not because of its functional syntax. In the presence of closures, you can in fact have object orientation (hidden data plus exposed functionality) in the form of a struct of local functions closing over the same local variables: // Javascript-esque pseudocode function myclass(n, k) { var a = n; return { incr: function() { a += k; } decr: function() { a -= k; } read: function() {…
6View on Reddit

u/Gblizein r/C_Programming • Mentions

On “Is using goto frowned upon in C?”

I will just leave this talk that always ressonate with me. It starts with the Dijkstra's goto letter misconception and a point against early returns/goto's although I heavily use them.
3View on Reddit

Supermanchoon Hacker News • Mentions

On ““Coding is basically just ifs and for loops.””

link to this video Sequence, selection, iteration (or recursion if available). Note that the child overlooked the assumption that it's sequential.
View on Hacker News

Supermanchoon Hacker News • Mentions

On “Why Architecture Oriented Programming Matters (2019)”

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…
View on Hacker News

mpweiheron Hacker News • Mentions

On “Why Architecture Oriented Programming Matters (2019)”

> 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 requirem…
View on Hacker News