Adding an "Other" enum value to an API often seems like a flexible solution for unknown future cases, but it creates significant problems. It weakens type safety, forcing consumers to handle an undefined case and potentially misinterpret data. It also makes versioning difficult, as any new enum value must be mapped to "Other" in older versions, obscuring valuable information and hindering analysis. Instead of using "Other," consider alternatives like an extensible enum, a separate field for arbitrary data, or designing a more comprehensive initial enum. Thorough up-front design reduces the need for "Other" and leads to a more robust and maintainable API.
This paper argues for treating programming environments as malleable habitats rather than fixed tools. It proposes a shift from configuring IDEs towards inhabiting them, allowing developers to explore, adapt, and extend their environments in real-time and in situ, directly within the context of their ongoing work. This approach emphasizes fluidity and experimentation, empowering developers to rapidly prototype and integrate new tools and workflows, ultimately fostering personalized and more effective programming experiences. The paper introduces Liveness as a core concept, representing an environment's capacity for immediate feedback and modification, and outlines key principles and architectural considerations for designing such living programming environments.
HN users generally found the concept of "living" in a programming environment interesting, but questioned the practicality and novelty. Some pointed out that Emacs users effectively already do this, leveraging its extensibility for tasks beyond coding. Others drew parallels to Smalltalk environments. Several commenters expressed skepticism about the proposed benefits outweighing the effort required to build and maintain such a personalized system. The discussion also touched on the potential for increased complexity and the risk of vendor lock-in when relying heavily on a customized environment. Some users highlighted the paper's academic nature, suggesting that the focus was more on exploring concepts rather than providing a practical solution. A few requested examples or demos to better grasp the proposed system's actual functionality.
Go 1.21 introduces a new mechanism for building more modular and extensible WebAssembly applications. Previously, interacting with JavaScript from Go WASM required compiling all the code into a single, large WASM module. Now, developers can compile Go functions as individual WASM modules and dynamically import and export them using JavaScript's standard module loading system. This allows for creating smaller initial downloads, lazy-loading functionalities, and sharing Go-defined APIs with JavaScript, facilitating the development of more complex and dynamic web applications. This also enables developers to build extensions for existing WASM applications written in other languages, fostering a more interconnected and collaborative WASM ecosystem.
HN commenters generally expressed excitement about Go's new Wasm capabilities, particularly the ability to import and export functions, enabling more dynamic and extensible Wasm applications. Several highlighted the potential for creating plugins and modules with Go, simplifying development and deployment compared to current WebAssembly workflows. Some discussed the implications for server-side Wasm and potential performance benefits. A few users raised questions about garbage collection and memory management with this new functionality, and another thread explored comparisons to JavaScript's module system and the potential for better tooling around Wasm. Some expressed concerns about whether it's better to use Go or Rust for Wasm development, and there was an insightful dialogue comparing wasmexport with previous approaches.
Summary of Comments ( 61 )
https://news.ycombinator.com/item?id=43193160
HN commenters largely agree with Raymond Chen's advice against adding "Other" enum values to APIs. Several commenters share their own experiences of the problems this creates, including difficulty in debugging, versioning issues as new enum members are added, and the loss of valuable information. Some suggest using an associated string value alongside the enum for unexpected cases, or reserving a specific enum value like "Unknown" for situations where the actual value isn't recognized, which provides better forward compatibility. A few commenters point out edge cases where "Other" might be acceptable, particularly in closed systems or when dealing with legacy code, but emphasize the importance of careful consideration and documentation in such scenarios. The general consensus is that the downsides of "Other" typically outweigh the benefits, and alternative approaches are usually preferred.
The Hacker News post "API design note: Beware of adding an "Other" enum value" discussing Raymond Chen's blog post about the pitfalls of adding "Other" to enums generated a moderate amount of discussion with 27 comments. Many commenters concurred with Chen's points, sharing their own experiences and expanding on the potential problems.
Several compelling comments highlighted the cascading issues caused by "Other" enum values. One commenter pointed out how this practice forces consumers of the API to implement awkward workarounds, often involving string parsing or custom data structures to handle the "Other" cases. This can lead to increased code complexity and maintenance burdens, especially as the API evolves. They emphasized how this negates the benefits of using enums in the first place, which are meant to provide type safety and clarity.
Another commenter elaborated on the difficulties in versioning APIs with "Other" enums. When new enum values are introduced in later versions, existing clients using the "Other" category may become incompatible or require significant refactoring to handle the updated values. This can create backward compatibility challenges and complicate the upgrade process for developers. This commenter also pointed out how the use of
Otheroften masks genuine bugs where an appropriate enum value should have been defined but wasn't.Some commenters suggested alternative strategies to avoid using "Other". One popular suggestion was to provide an extensible enum mechanism, allowing consumers to define their own values if needed. Another commenter proposed using a dedicated "Unknown" value instead of "Other", signifying that the value is not recognized by the current version of the API but might be handled gracefully in future versions. The use of "Unknown" implies a future where the unknown values will be given proper meaning as opposed to "Other," which implies something outside the intended domain of the enum.
A few comments also focused on the importance of careful API design and communication between API providers and consumers. They highlighted the need for thorough documentation and clear guidelines on how to handle unexpected or unknown values. One commenter stressed the importance of using a versioning strategy that allows clients to adapt gracefully to changes in the API.
In summary, the comments generally agreed with Chen's premise and provided further evidence and anecdotes supporting the avoidance of "Other" in enums. They discussed the practical challenges and offered alternative solutions for API designers. The discussion reinforced the importance of thoughtful API design, versioning, and communication to prevent issues caused by the ambiguous nature of "Other" values.