
Effective Programs - 10 Years of Clojure - Rich Hickey
About this video
Rich Hickey's talk at Clojure's tenth anniversary on the kind of programs Clojure is designed for. He argues for situated programs that deal with changing requirements, and for dynamic typing and data over static types.
Why it appears in the archive
HN's go-to link in typing debates and for talk lists, and several call it their favorite programming talk even for non-Clojure users.
AI-generated summary and labels from the source dataset; verify important details against the video. Source & credits.
From the Hacker News discussion
Rich Hickey has a lot of excellent stuff to say. Not only are his ideas philosophically sound, but also real, practical and ready to use in the form of Clojure. This recent review "10 years of Clojure", encapsulates a lot of of the wisdom: [VIDEO]
Read original comment ↗> Requirements change. Every software engineering project will face this hard problem at some point. Rich Hickey calls this a 'situated' program in his talk from Clojure/Conj 2017, where the program has to deal with information and real-world irregularities for extended periods. While agile disciplines help you from one perspective, your tools (e.g. program language) might also help you solve some of the problems. In this framing, Clojure certainly tries to help where the it matters most. Highly recommended to read the transcript or watch the video, even if you are not interested in the language itself. Video: [VIDEO] Transcript: [LINK]
Read original comment ↗Rich hickey explains at this timestamp in the video, [VIDEO] "The information programming problem" Whole video is gold, is my fav programming talk of all time.
Read original comment ↗One of the big benefits of clojure being dynamic is that everything is data (e.g. a map, set, vector or list). This is what allows reuse. - The vast core library of functions that manipulate those data structures can be used for everything in your program, cos it's all data. - Most clojure libraries take and/or return data, reducing the need for clumsy adaptors, or even worse not being able to get at the data you need cos the library writer was really enthusiastic about encapsulation of everything they thought was of no use to consumers. - You don't have a person class, you have a map with a first name and last name. Now the function that turns first + last name into full name can be reused for any other map with the same keys. (A rather spurious example, but a real one would take a large codebase and an essay to describe) I can only recommend watching some of Rich Hickey's talks, particularly these ones, they're not entirely about types, but they express the above ideas much better than I can: - Simple made easy [LINK] - Effective programs [VIDEO] - Are we there yet? (this one is more about OOP, but unless you're using something like haskell, idris etc its relevant for your type system of choice) [LINK]
Read original comment ↗We Really Don't Know How to Compute: Gerry Sussman - [LINK] Zebras All the Way Down: Bryan Cantrill - [LINK] Jonathan Blow on Deep Work: Jonathan Blow - [LINK] Simple Made Easy: Rich Hickey - [LINK] Effective Programs - 10 Years of Clojure: Rich Hickey - [VIDEO] The Last Thing D Needs: Scott Meyers - [LINK]
Read original comment ↗That's quite a judgement call to make based on the utility of error messages. I can't remember the last time I was blocked based on a Clojure error message anyway. Errors are less frequent and usually pretty obvious. I think you're wrong to say core devs don't understand modern programming, but you'd probably be right to say that they didn't prioritize making it approachable and stooping to the lowest common denominator. And it's not just Clojure, but datomic, core.async, spec -- all solving real problems in modern large scale programming with elegance. Watch Rich's 'Effective Programs' talk [1] and lmk if you still feel that he's out of touch with modern large scale programming. I think he's pretty in tune. [1] [VIDEO]
Read original comment ↗Here's a video of the creator of Clojure explaining his preference for dynamic vs static languages, and how he came to the choice of making Clojure dynamic, that may help inform your decision: [VIDEO]
Read original comment ↗[VIDEO] Goes until 43:25. The whole talk is worth watching. It's basically about the higher level problems of business app development, how to address them, and how Clojure does address them.
Read original comment ↗