
Elements of Programming Style - Brian Kernighan
About this video
Brian Kernighan's 2009 talk at Princeton on the Elements of Programming Style, discussing readable code, avoiding cleverness and flawed examples in programming tutorials.
Why it appears in the archive
HN cites it as the author's own talk on writing clear code, useful as a companion to his book.
AI-generated summary and labels from the source dataset; verify important details against the video. Source & credits.
From the Hacker News discussion
I always wondered about the C tutorials Brian Kernigan mentions in his talk ( [VIDEO] ) , many of the examples seem intentionally designed to be incorrect by some trickster spirit. Now I know the even darker truth.
Read original comment ↗Brian Kernighan (the K in K&R and AWK) also wrote a similar book with P. J. Plauger called "The Elements of Programming Style" [1]. There's even a talk by him about it online (2009) [2]. Kernighan also co-authored a (imo) really great book with Rob Pike (once an assistant of Penn & Teller [3]) called "The Practice of Programming" [4]. Unfortunately, this one is a bit over the 200 page limit. [1] [LINK] [2] [VIDEO] [3] [LINK] [4] [LINK]
Read original comment ↗Filtering a container by a predicate is 50 year old technology and a very common thing. It's unbelievable that a "modern" language has no shorter or clearer idiom than that convoluted boilerplate filled Ministry of Silly Walks blob. Python had filter() and then got list comprehensions from Haskell list comprehensions. PowerShell has Where-Object taking from C# LINQ .Where() which takes from SQL's WHERE. Prolog has include/3 which goes back to sublist(Test, Longer, Shorter) and LISP-Machine LISP had sublist in the 1970s[1]. APL has single character / compressing an array from a bitmask result of a Boolean test in the original APL/360 in 1968 and it was described in the book in 1962[2]. Brian Kernighan gave a talk on the readability of code and not getting too clever[3] "Elements of Programming Style" where he talks about languages having one way to write one thing so that you can spot mistakes easily. I am aware he's one of the Go designers and I will mention that again in a moment. In Python the non-list-comprehension version might be: result = [] for x in foo: if "banned" in x: result.append(x) Which is still clearer than the Go, simply by having less going on. I usually argue that "readable" merely means "familiar" and Python is familiar to me and Go isn't. Your Go code makes me wonder: - "var" in C# does type inference. You declare []string but don't declare types for _ x or the tuple _,x what's up with the partial type inference? What is "var" adding to the code over clas
Read original comment ↗