tl;dr:Hillel refers to an essay that says that inheritance is harmful and if possible you should "ban inheritance completely... “A lot of these arguments argue that in practice inheritance has problems. But they don't preclude inheritance working in another context, maybe with a better language syntax. And it doesn't explain why inheritance became so popular in the first place. I want to explore what's fundamentally challenging about inheritance and why we all use it anyway.”
tl;dr:“I see graphs everywhere and use them to analyze all sorts of systems. At the same time, I dread actually using graphs in my code. There is almost no graph support in any mainstream language. None have it as a built-in type, very few have them in the standard library, and many don’t have a robust third-party library in the ecosystem. Most of the time, I have to roll graphs from scratch. There’s a gap between how often software engineers could use graphs and how little our programming ecosystems support them. Where are all the graph types?” Hillel discusses and shares a list of programming languages with graph types.
tl;dr:“Picat is a research language intended to combine logic programming, imperative programming, and constraint solving. I originally learned it to help with vacation scheduling but soon discovered its planner module, which is one of the most fascinating programming models I’ve ever seen.”
tl;dr:Hillel describes strings as “the most powerful and terrible of all basis types... When you see a string in code, you want to know what kind of string it is. We use these strings for different purposes and we want to do different things to them. We might want to upcase or downcase identifiers for normalization purposes, but we don't split or find substrings in them. But you can do those operations anyway because all operations are available to all strings. It's like how if you store user ids as integers, you can take the average of two ids. The burden of using strings properly is on the developer.”
tl;dr:“13 bits of advice for early-career programmers. Some of it is contradictory”: (1) Behind every best practice is a horror story. If you don't understand a best practice, look for the horror story that inspired it. It might make the best practice make sense. (2) Carefully think about any advice and evaluate how it applies to your situation. There is very little about software that's been scientifically studied, and most of the research is inconclusive. (3) Every tool has some form of hidden depth, from your programming language to git to JIRA. You don’t have to become an expert in every single one, but consider spending 5-10 minutes learning a bit more about what it can do.
tl;dr:Hillel critiques the 4doc model for user documentation, highlighting that it's not universal or comprehensive. While effective for tools, it may not suit frameworks and languages. The key takeaway is that relying solely on the 4doc model can limit documentation effectiveness, and a more flexible approach that considers the specific subject being documented is encouraged.
tl;dr:Hillel argues why a well-documented "Defense of Design" is an invaluable resource for understanding a project's history, design decisions, and constraints that shaped it. It provides insights into the thought process of the creators, developers, and maintainers, thus fostering a greater level of understanding and appreciation for the software.
tl;dr:“While people like coming up with grand theories of complexity, there’s very little info out there on the nitty-gritty specific sources of complexity… I think a lot about the different sources of complexity. This article is about one particular source.”
tl;dr:“Most of the time we ask narrow questions which are helpful when confirmed and not-helpful when rejected. If you make a lot of wrong predictions, then debugging boils down to guess-and-check. If you instead ask broad questions, you learn less when they’re true but more when they’re not. Then you iteratively close in on the actual source of the bug.”
tl;dr:"I’ve tried to write a blog post on tag systems for years now... The problem is that there’s just so much to them, so many different approaches and models and concerns that trying to be comprehensive and rigorous is an exercise in madness... So screw it. These are my non-comprehensive, poorly-researched thoughts on tag systems. This is not about implementation of tag systems, just their design."