This 1972 paper by Parnas compares two system decomposition strategies: one based on flowcharts and step-wise refinement, and another based on information hiding. Parnas argues that decomposing a system into modules based on hiding design decisions behind interfaces leads to more stable and flexible systems. He demonstrates this by comparing two proposed modularizations of a KWIC (Key Word in Context) indexing system. The information hiding approach results in modules that are less interconnected and therefore less affected by changes in implementation details or requirements. This approach prioritizes minimizing inter-module communication and dependencies, making the resulting system easier to modify and maintain in the long run.
The blog post explores encoding arbitrary data within seemingly innocuous emojis. By exploiting the variation selectors and zero-width joiners in Unicode, the author demonstrates how to embed invisible data into an emoji sequence. This hidden data can be later extracted by specifically looking for these normally unseen characters. While seemingly a novelty, the author highlights potential security implications, suggesting possibilities like bypassing filters or exfiltrating data subtly. This hidden channel could be used in scenarios where visible communication is restricted or monitored.
Several Hacker News commenters express skepticism about the practicality of the emoji data smuggling technique described in the article. They point out the significant overhead and inefficiency introduced by the encoding scheme, making it impractical for any substantial data transfer. Some suggest that simpler methods like steganography within image files would be far more efficient. Others question the real-world applications, arguing that such a convoluted method would likely be easily detected by any monitoring system looking for unusual patterns. A few commenters note the cleverness of the technique from a theoretical perspective, while acknowledging its limited usefulness in practice. One commenter raises a concern about the potential abuse of such techniques for bypassing content filters or censorship.
Successful abstractions manage complexity by isolating it. They provide a simplified interface that hides intricate details, allowing users to interact with a system without needing to understand its inner workings. A good abstraction chooses which details to expose and which to conceal, offering just enough information for effective use. This simplification reduces cognitive load and allows for easier composition and reuse of components. The key is finding the right balance: too much abstraction leads to leaky abstractions where the underlying complexity seeps through, while too little provides insufficient simplification.
HN commenters largely agreed with the author's premise that good abstractions hide complexity. Several pointed out that "leaky abstractions" are a common problem, where the underlying complexity bleeds through and negates the abstraction's benefits. One commenter highlighted the difficulty of finding the right balance, where an abstraction is neither too complex nor too simplistic, using the example of an overly abstracted car where the driver has no control over engine specifics. The value of predictable behavior within an abstraction was also emphasized, along with the importance of choosing the right level of abstraction for the task at hand, suggesting different levels for different users (e.g., library user vs. library developer). Some discussion focused on the definition of "complexity" itself, with suggestions that "complications" or "implementation details" might be more accurate terms. The lack of mention of Postel's Law (be conservative in what you send, liberal in what you accept) was noted by one commenter as a surprising omission.
Summary of Comments ( 4 )
https://news.ycombinator.com/item?id=43244860
HN commenters discuss Parnas's modularity paper, largely agreeing with its core principles. Several highlight the enduring relevance of information hiding and minimizing inter-module dependencies to reduce complexity and facilitate change. Some commenters share anecdotes about encountering poorly designed systems violating these principles, reinforcing the paper's importance. The concept of "secrets" as the basis of modularity resonated, with discussions about how it applies to various levels of software design, from low-level functions to larger architectural components. A few commenters also touch upon the balance between pure theory and practical application, acknowledging the complexities of real-world software development.
The Hacker News post titled "On the criteria to be used in decomposing systems into modules (1972)" has a modest number of comments, sparking a focused discussion around the paper's core concepts and their relevance today.
Several commenters reflect on the enduring wisdom of Parnas's arguments. One user highlights the continuing struggle with modularity despite decades of progress in software engineering, suggesting that "we're still struggling to teach these lessons nearly 50 years later." Another emphasizes the importance of information hiding as crucial for managing complexity, not just in large systems but also in smaller projects.
The discussion touches upon the practical application of Parnas's principles. One commenter shares personal experience applying these ideas to a specific project, noting the resulting improvement in system maintainability. This anecdote provides a real-world illustration of the paper's theoretical concepts. Another commenter emphasizes the importance of "well defined interfaces" not just for modularity, but as a means to enable parallel development, ultimately speeding up project delivery.
A few comments delve into specific aspects of the paper. One user points out the importance of module cohesion and coupling as fundamental principles derived from Parnas's work. They highlight the interplay of these principles in achieving a well-structured system. Another commenter draws attention to the subtle but significant distinction between "hiding secrets" and hiding implementation details.
The discussion also explores alternative viewpoints and historical context. One commenter mentions the rise of microservices and how it relates (or perhaps contrasts) with the module decomposition principles outlined in the paper, questioning whether microservices truly adhere to these ideals or represent a different approach altogether.
While the discussion is not overly extensive, it provides valuable insights into the continuing relevance of Parnas's work and its impact on software engineering practices. The comments demonstrate a shared appreciation for the paper's core message while also acknowledging the ongoing challenges in applying these principles effectively in modern software development.