tl;dr:"Sudoku is an example of a constraint problem. Most “solving sudoku” tutorials use either backtracking or constraint propagation. These same techniques apply to all constraint problems, and since such problems are so widespread, it doesn’t make sense to custom build an algorithm for every single one. Rather, we want general-purpose constraint solvers we can apply to arbitrary problems."
tl;dr:"Mimicry is when software X reimplements at a higher level a core feature of software Y. The produced facsimile has some, but not all, of the same properties, enough to “look like” it’s the same thing but missing many of the nuances. This exists in every kind of software. One language can mimic another, a library can mimic a language, a database engine can mimic a product, etc."
tl;dr:"The difference is that I treat it as a useful technique, one of many, while the very strongest advocates consider it transformational... I practice “weak TDD”, which just means “writing tests before code, in short feedback cycles”. Hillel explains why he holds complicated feelings for TDD.
tl;dr:"Also I don’t think most users, or even most “power users”, use many of these features. The same is true for devs, most of whom don’t really use the features of their editors. It’s good to explore these things!"
tl;dr:"My best explanation for this is that most people learn a tool through searching, not browsing. When you search, you’re trying to find information that solves your specific need. When you browse, you’re systematically going through information for learning or later lookup."
tl;dr:"The pattern matching feature is, on the whole, pretty reasonably designed, and people will expect it to behave in reasonable ways. Whereas \_\_subclasshook\_\_ is extremely dark magic. This kind of chicanery might have a place in the dark beating heart of a complex library, certainly not for any code your coworkers will have to deal with." Hillel guides us though pattern matching and \_subclasshook\_\_.
tl;dr:"I don’t need to burn any of my limited focus on something menial anymore. It matters even more when automating something I don’t know by heart, like my Zoom URL or my EIN. Then it takes focus to find it ;and then copy it over."
tl;dr:People hate regexes for 2 reasons: (1) They’re hard to read, so it's hard to tell what a regex does. (2) They’re fragile an a slight change to the input can break it and making them more robust is tough. Hillel argues that the best use cases for regexes is in "interactive use" - when you’re trying to substitute in a single file you have open, or grep a folder. "Readability doesn’t matter because you’re writing a one-off throwaway, and fragility is fine because you’re a human-in-the-loop."
tl;dr:Hillel draws a distinction between clever code, which "conventional wisdom says is bad," and insightful code which finds a way of exploiting a problem to make code "faster, simpler, and safer," and is often necessary to make things work. Hillel highlights these with examples.
tl;dr:Includes (1) Brainfuck, the most famous Esoteric language with a compiler of 240 bytes, (2) Shakespeare, a language designed to look like a Shakespeare play, (3) Piet, a visual programming language in the truest sense: every Piet program is an executable picture.