The blog post "Frankenstein's __init__" explores the complexities and potential pitfalls of Python's __init__ method, particularly when dealing with inheritance. It argues against placing complex logic or side effects within __init__, as this can lead to unpredictable behavior and violate the principle of least astonishment, especially in scenarios involving inheritance and multiple inheritance. The author advocates for using factory functions or a separate post_init method for such logic, leading to more transparent, testable, and maintainable code. This approach decouples object creation from initialization logic, allowing for greater flexibility and avoiding unexpected interactions between parent and child class initializers.
The blog post "You Need Subtyping" argues that subtyping, despite sometimes being viewed as complex or unnecessary, is a crucial tool for writing flexible and maintainable code. It emphasizes that subtyping allows for writing generic algorithms that operate on a range of related types without needing modification for each specific type. The author illustrates this through examples using shapes and animal sounds, demonstrating how subtyping enables reusable functions that handle different subtypes without explicit type checks. The post further champions subtype polymorphism as a superior alternative to approaches like typeclasses or enums for handling diverse data types, highlighting its ability to gracefully accommodate future type extensions without altering existing code. Ultimately, the author advocates for embracing subtyping as a fundamental concept for building robust and adaptable software systems.
HN users generally disagreed with the premise that subtyping is needed. Several commenters argued that subtyping adds complexity, especially in larger projects, and that its benefits are often overstated. Alternatives like composition and pattern matching were suggested as potentially superior approaches. Some argued that the author conflated subtyping with polymorphism, while others pointed out that the benefits mentioned in the article, like code reuse and extensibility, could be achieved without subtyping. A few commenters discussed the specific example used in the blog post, highlighting its contrived nature and suggesting better alternatives. The overall sentiment was that subtyping is a tool, sometimes useful, but not a necessity.
This blog post explores how game theory can explain ancient debt inheritance practices. It argues that varying customs, like the complete forgiveness of debts upon death or the inheritance of debt by heirs, can be understood as strategic responses to different social and economic environments. Where strong social ties and community enforcement existed, debt forgiveness could be sustainable. Conversely, in societies with weaker community bonds, inheriting debt incentivized responsible lending and borrowing by holding both parties accountable, even beyond death. This system, akin to a repeated game in game theory, fostered trust and facilitated economic activity by increasing the likelihood of repayment.
Hacker News users discussed the practicality and cultural context of the debt settlement methods described in the linked article. Some questioned the realism of the scenarios presented, arguing that the proposed game theory model oversimplifies complex social dynamics and power imbalances of ancient societies. Others highlighted the importance of reputation and social capital in these pre-legal systems, suggesting that maintaining community trust was a more powerful motivator than the threat of ostracization presented in the game theory example. Several commenters pointed out similar historical examples of debt inheritance and social mechanisms for resolving them, drawing comparisons to practices in various cultures. There was also discussion about the effectiveness of ostracization as a punishment and how it compares to modern legal systems.
Inherited wealth is increasingly rivaling earned income in importance, especially in advanced economies. As populations age and accumulated wealth grows, inheritances are becoming larger and more frequent, flowing disproportionately to the already wealthy. This exacerbates inequality, entrenches existing class structures, and potentially undermines the meritocratic ideal of social mobility based on hard work. The article argues that governments need to address this trend through policies like inheritance taxes, not just to raise revenue, but to promote fairness and opportunity across generations.
HN commenters largely agree with the premise that inherited wealth is increasingly important for financial success. Several highlight the difficulty of accumulating wealth through work alone, especially given rising housing costs and stagnant wages. Some discuss the societal implications, expressing concern over decreased social mobility and the potential for inherited wealth to exacerbate inequality. Others offer personal anecdotes illustrating the impact of inheritance, both positive and negative. The role of luck and privilege is a recurring theme, with some arguing that meritocracy is a myth and that inherited advantages play a larger role than often acknowledged. A few commenters point out potential flaws in the Economist's analysis, questioning the data or suggesting alternative interpretations.
The blog post "Inheritance and Subtyping" argues that inheritance and subtyping are distinct concepts often conflated, leading to inflexible and brittle code. Inheritance, a mechanism for code reuse, creates a tight coupling between classes, whereas subtyping, focused on behavioral compatibility, allows substitutability. The author advocates for composition over inheritance, suggesting interfaces and delegation as preferred alternatives for achieving polymorphism and code reuse. This approach promotes looser coupling, increased flexibility, and easier maintainability, ultimately leading to more robust and adaptable software design.
Hacker News users generally agree with the author's premise that inheritance is often misused, especially when subtyping isn't the goal. Several commenters point out that composition and interfaces are generally preferable, offering greater flexibility and avoiding the tight coupling inherent in inheritance. One commenter highlights the "fragile base class problem," where changes in a parent class can unexpectedly break child classes. Others discuss the nuances of Liskov Substitution Principle and how it relates to proper inheritance usage. One user specifically calls out Java's overuse of inheritance, citing the infamous AbstractSingletonProxyFactoryBean. A few dissenting opinions mention that inheritance can be a useful tool when used judiciously, especially in domains like game development where hierarchical relationships are naturally occurring.
Summary of Comments ( 24 )
https://news.ycombinator.com/item?id=43735724
HN users largely discuss the impracticality and contrived nature of the example in the article, which explores creating an object through a Frankensteinian assembly of
__init__components. Several commenters find the exploration interesting but ultimately useless, highlighting how it obfuscates code and introduces unnecessary complexity. The prevailing sentiment is that while conceptually intriguing, such a method is counterproductive to writing clear, maintainable code and would likely never be used in a real-world scenario. Some find the exploration of metaprogramming and the inner workings of Python mildly interesting, but the overall consensus leans towards viewing the article's content as a clever but impractical exercise.The Hacker News post titled "Frankenstein's
__init__" sparked a discussion with several insightful comments revolving around the complexities and potential pitfalls of inheritance in object-oriented programming, specifically in Python. The conversation largely agrees with the author's premise about the awkwardness of large, complex__init__methods often necessitated by inheritance.Several commenters highlight the tension between adhering to Liskov's Substitution Principle and the practical challenges of designing class hierarchies. One commenter points out the difficulties encountered when subclasses require different initialization parameters than their parent class, leading to unwieldy
**kwargsusage and obscure error handling. This resonates with the article's concerns about the "Frankenstein" nature of such constructors. They further argue that forcing conformance to a rigid structure through inheritance can be detrimental to code clarity and maintainability, suggesting composition as a more flexible alternative.Another commenter emphasizes the importance of careful consideration when designing class hierarchies and choosing between inheritance and composition. They propose that simpler designs are often preferable and that the need for complex inheritance structures might indicate a flaw in the overall design. They also caution against overusing inheritance solely for code reuse, reiterating the benefits of composition in such scenarios.
The idea of "role interfaces" is brought up as a potential solution to the inheritance dilemma. This approach involves defining smaller, more focused interfaces that classes can implement, allowing for greater flexibility and composability. This is presented as a way to avoid the rigid constraints of traditional inheritance while still maintaining a degree of structure and ensuring substitutability.
One commenter, focusing on the specific example in the original article, questions whether abstract base classes would be a suitable solution to address the initialization challenges. This sparks a brief discussion about the nuances of abstract methods and their role in enforcing certain behaviors within a class hierarchy.
Finally, a recurring theme in the comments is the preference for simplicity and avoiding over-engineering. Several commenters express the view that complex inheritance hierarchies often add unnecessary complexity and advocate for keeping designs as simple as possible. This aligns with the overall sentiment that Frankensteinian
__init__methods are a symptom of a deeper design issue.