
ClojureTV
10 HN recommenders · recommended in 18 months, 2017–2026
1:14:52 · 176K views · Oct 12, 2017
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.
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.
20 comments from Hacker News
> 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: this video Transcript: [LINK]
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: this video
Rich hickey explains at this timestamp in the video, this video "The information programming problem" Whole video is gold, is my fav programming talk of all time.
Consider reading/watching Rich Hickey's talk Effective Programs [0][1] and Maybe Not [2][3] In [0] in particular there're slides 22/23, here is part of the transcript but makes more sense with the slides on: > And you can call them problems, and I'm going to call them the problems of programming. And I've ordered them here [...] I've ordered them here in terms of severity. And severity manifests itself in a couple of ways. Most important, cost. What's the cost of getting this wrong? At the very top you have the domain complexity, about which you could do nothing. This is just the world. It's as complex as it is. > > But the very next level is the where we start programming, right? We look at the world and say, "I've got an idea about how this is and how it's supposed to be and how, you know, my program can be effective about addressing it". And the problem is, if you don't have a good idea about how the world is, or you can't map that well to a solution, everything downstream from that is going to fail. There's no surviving this misconception problem. And the cost of dealing with misconceptions is incredibly high. > >So this is 10x, a full order of magnitude reduction in (?) severity before we get to the set of problems I think are more in the domain of what programming languages can help with, right? And because you can read these they'll all going to come up in a second as I go through each one on some slide so I'm not going to read them all out right now. But importantly t
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 this 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]